From cogitation
Guides test-driven development with red-green-refactor cycle. Stores successful test patterns in EC. Use when implementing new features, fixing bugs, writing tests, adding functionality, or any code change that should be test-first. Default approach for all implementation work.
npx claudepluginhub merewhiplash/engram-cogitator --plugin cogitationThis skill uses the workspace's default tool permissions.
Write the test first. Watch it fail. Write minimal code to pass.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Write the test first. Watch it fail. Write minimal code to pass.
Announce: "I'm using the tdd skill for this implementation."
Get project config and relevant patterns:
ec_search:
query: project config
type: config
ec_search:
query: test pattern
type: pattern
Use the configured test_command for running tests.
RED → GREEN → REFACTOR → REPEAT
Search for similar test patterns first:
ec_search:
query: [feature area] test
type: pattern
Write one minimal test for the behavior you want:
test('rejects empty email', () => {
const result = validateEmail('');
expect(result.valid).toBe(false);
expect(result.error).toBe('Email required');
});
Run tests with configured command:
{test_command} path/to/test
Confirm:
If test passes: You're testing existing behavior. Fix the test.
Write the simplest code to make the test pass:
function validateEmail(email: string) {
if (!email?.trim()) {
return { valid: false, error: 'Email required' };
}
return { valid: true };
}
Don't add features beyond what the test requires.
{test_command} path/to/test
Confirm:
After green only:
Keep tests green. Don't add behavior.
Next failing test for next behavior.
When you establish a useful test pattern:
ec_add:
type: pattern
area: [component]
content: [Description of test pattern and when to use it]
rationale: Established during TDD implementation
Good patterns to store:
| Problem | Solution |
|---|---|
| Don't know how to test | Write the assertion first, then figure out setup |
| Test too complicated | Design too complicated - simplify the interface |
| Must mock everything | Code too coupled - use dependency injection |
Search EC for prior solutions:
ec_search:
query: test difficulty [problem area]
type: learning
No production code without a failing test first.
Code before test? Delete it. Start over.
If you discover a testing gotcha:
ec_add:
type: learning
area: testing
content: [What the issue was and how to handle it]