test-plan

Invoke as $cc-test-plan. The user request follows the skill mention.

Test Plan Workflow

Scope: $ARGUMENTS

Specify what to plan tests for. Examples:

• A feature name: user authentication
• A module or file path: src/orders/OrderService.kt
• A Task Card title: Add paginated product listing endpoint
• A PR or branch: feature/payment-retry

If $ARGUMENTS is empty, describe the scope in your next message before proceeding.

---

Step 0 — CCEP Bootstrap

Command: test-plan (fixed for this workflow — do not infer from user text)

1. Run: npx cc-codeconductor ccep profile test-plan --output json to get the phases and their roles.
2. For each delegated phase, run: npx cc-codeconductor ccep compile --command test-plan --phase <phase-id> "$ARGUMENTS" --view prompt --output json
3. After planner/intake JSON is available, run: npx cc-codeconductor ccep evaluate --command test-plan --input <planner.json> --output json. If stop is true, show questions or risks and wait for human input.
4. Pass each subagent only the compiled prompt for its phase — never forward raw $ARGUMENTS to planners.

---

Step 1 — Scope confirmation

Before generating the test plan, confirm the scope is well-defined.

A valid scope includes:

• The behavior or module under test
• The acceptance criteria or expected behavior (from the Task Card if available)
• Known edge cases or failure modes

If the scope is vague (e.g., "test the whole service"), ask one clarifying question and wait for the answer.

---

Step 2 — Test plan generation (Tester role, planning mode)

Adopt the tester role as defined in AGENTS.md.

Produce a test plan document — not test code. The plan will be used as input when tests are actually written.

Cover the following layers:

Unit tests

• Individual functions or methods in isolation
• One test per behavior, not per method
• Input/output contracts, null handling, type coercion

Integration tests

• Interactions between two or more components
• Database read/write cycles (if applicable)
• External service boundaries (mocked or stubbed)

Contract tests

• API endpoint contracts: request shape, response shape, status codes
• Event schema contracts (if event-driven components are in scope)

Edge cases

• Empty inputs, boundary values, max/min limits
• Concurrent access (if shared state is involved)
• Failure paths: what happens when a dependency is unavailable

Regression cases

• Known past bugs that must not recur (include reference if available)

---

Step 3 — Test Plan format

Produce the plan in this format:

## Test Plan — [Scope Name]

### Scope
[What is being tested and why]

### Unit Tests
| Test ID | Target | Scenario | Expected Result |
| ------- | ------ | -------- | --------------- |
| U-001   | ...    | ...      | ...             |

### Integration Tests
| Test ID | Components | Scenario | Expected Result |
| ------- | ---------- | -------- | --------------- |
| I-001   | ...        | ...      | ...             |

### Contract Tests
| Test ID | Endpoint/Event | Property | Expected Value |
| ------- | -------------- | -------- | -------------- |
| C-001   | ...            | ...      | ...            |

### Edge Cases
| Test ID | Input/Condition | Expected Behavior |
| ------- | --------------- | ----------------- |
| E-001   | ...             | ...               |

### Regression Cases
| Test ID | Reference | Scenario | Must Not Happen |
| ------- | --------- | -------- | --------------- |
| R-001   | ...       | ...      | ...             |

### Coverage Targets
- Minimum unit coverage: [% or "all acceptance criteria covered"]
- Integration scenarios: [count]
- Contract validations: [count]

### Out of Scope
[What this test plan explicitly does not cover and why]

---

Step 4 — Human review

Show the Test Plan before any tests are written. The Test Plan is an artifact for review and approval.

Writing test code is a separate action — run /feature or add a test task to implement from this plan.

---

Completion

Deliver the complete Test Plan document. Save it as docs/test-plans/[scope-slug].md if requested.

This command produces a plan, not test files. No production code and no test code is written during this command.

Next

Implement against this plan with $cc-tdd-cycle or $cc-feature.