Your Name
2dabf8ef03
- memory/: cross-session project memory with decisions, lessons, failures, architecture, and sessions categories. Each has format templates and lifecycle documentation. - skills/: 12 reusable specialized methodologies (tdd, systematic-debugging, architecture-design, code-review, security-review, repository-analysis, failure-analysis, refactoring, test-analysis, incident-investigation, browser-automation, research). Each has frontmatter and methodology sections. - improvements/: proposal-based improvement system requiring human approval. - scripts/memory-lifecycle.sh: deterministic memory operations (recall, store, list, search, sessions, cleanup). - scripts/test-memory-system.sh: 12 structural tests for all new systems. - orchestrator.md: added Memory Recall stage, Learning and Memory Storage stage, Improvement Proposals workflow, memory/skills rules, and 3 new actions (A23-A27) to the action catalog. Updated behavioral acceptance test and state separation model. - All 12 subagents: added Memory & Skills Awareness sections with recall and store instructions. - docs/AGENT_ARCHITECTURE.md: documented memory, skills, and improvements systems (sections 12-14). Updated action count (27), state model, and remaining weaknesses. - README.md: documented new systems, updated repository layout, added test-memory-system.sh documentation. All 39 tests pass (16 architecture + 12 memory + 11 bootstrap).
72 lines
2.1 KiB
Markdown
72 lines
2.1 KiB
Markdown
---
|
|
name: tdd
|
|
description: Test-Driven Development methodology — write tests first, implement to pass, refactor
|
|
version: "1.0"
|
|
owner: Builder + Tester
|
|
prerequisites: test framework identified, build system working
|
|
---
|
|
|
|
# Test-Driven Development
|
|
|
|
## When to use this skill
|
|
|
|
- Implementing new functionality where correctness can be verified
|
|
- Bug fixes where a regression test should exist
|
|
- Any change where the expected behavior is well-defined
|
|
|
|
## Core methodology
|
|
|
|
```text
|
|
RED → write a failing test that captures the requirement
|
|
GREEN → implement the minimum code to make the test pass
|
|
REFACTOR → improve the code while keeping all tests green
|
|
```
|
|
|
|
## Step-by-step procedure
|
|
|
|
### 1. Understand the requirement
|
|
- What behavior is expected?
|
|
- What inputs produce what outputs?
|
|
- What edge cases exist?
|
|
- What error conditions should be handled?
|
|
|
|
### 2. Write the test (RED)
|
|
- Write the smallest test that captures one aspect of the requirement
|
|
- Verify the test fails for the right reason (not a syntax error)
|
|
- Run the test to confirm it fails
|
|
|
|
### 3. Implement (GREEN)
|
|
- Write the minimum code to make the test pass
|
|
- Do not add behavior not captured by a test
|
|
- Run the test to confirm it passes
|
|
|
|
### 4. Verify (REFACTOR)
|
|
- Run the full test suite (not just the new test)
|
|
- Refactor if needed: extract methods, rename for clarity, remove duplication
|
|
- Verify tests still pass after each refactor step
|
|
|
|
### 5. Repeat
|
|
- Return to step 1 for the next aspect of the requirement
|
|
- Stop when all aspects are covered and tests pass
|
|
|
|
## Common pitfalls
|
|
|
|
- Writing tests after implementation (loses the design benefit)
|
|
- Writing too many tests at once (harder to isolate failures)
|
|
- Testing implementation details instead of behavior
|
|
- Skipping the refactor step (technical debt accumulates)
|
|
- Not running the full suite after changes
|
|
|
|
## Evidence requirements
|
|
|
|
- Test file with the new test(s)
|
|
- Test output showing RED → GREEN progression
|
|
- Full suite passing after completion
|
|
|
|
## Exit criteria
|
|
|
|
- All new tests pass
|
|
- Full existing suite passes
|
|
- Tests capture the behavior, not the implementation
|
|
- Each test is independently runnable
|