Intent Plan

Transform an approved Intent into a structured, executable development plan with strict TDD discipline.

Core Principles

1. Test First, Always: Every implementation step starts with writing tests
2. Phased Execution: Break work into phases with clear deliverables
3. Verification Gates: Each phase ends with e2e validation
4. Automation Priority: Prefer CLI/script testing over manual/browser testing

Plan Structure

Phase 1: [Phase Name]
├── Step 1.1: [Feature/Component]
│   ├── Unit 1: Write Tests
│   │   ├── Happy path cases
│   │   ├── Bad path cases (detailed, comprehensive)
│   │   ├── Edge cases
│   │   ├── Security vulnerability cases
│   │   ├── Data leak cases
│   │   └── Data damage cases
│   └── Unit 2: Implementation
│       └── Make all tests pass
├── Step 1.2: [Next Feature]
│   ├── Unit 1: Write Tests
│   └── Unit 2: Implementation
└── Phase Gate: E2E Verification
    └── CLI/Script based validation

Phase 2: [Phase Name]
└── ...

Test Requirements

Unit 1: Test Writing (MUST come first)

Every step begins with comprehensive test coverage:

Test Category	Description	Examples
Happy Path	Normal expected usage	Valid inputs, correct sequences
Bad Path	Invalid inputs, error conditions	Wrong types, missing required fields, invalid states
Edge Cases	Boundary conditions	Empty inputs, max values, concurrent access
Security	Vulnerability prevention	Injection attacks, auth bypass, privilege escalation
Data Leak	Information exposure	Sensitive data in logs, error messages, responses
Data Damage	Data integrity	Partial writes, corruption, race conditions

Bad cases must be detailed and comprehensive. A good test suite has more failure tests than success tests.

Unit 2: Implementation

• Only starts after tests are written
• Goal: Make all tests pass
• No new functionality without corresponding tests

Phase Gates: E2E Verification

Each phase ends with end-to-end verification:

Preferred: CLI/Script Testing

# Example: API verification
curl -X POST http://localhost:3000/api/resource \
  -H "Content-Type: application/json" \
  -d '{"field": "value"}' | jq .

# Example: Database state check
psql -c "SELECT * FROM table WHERE condition"

# Example: File system verification
diff expected_output.json actual_output.json

For Web Projects: Automation-Friendly Design

Design APIs and interfaces that support automated testing:

DO:
- Provide health check endpoints
- Return machine-parseable responses (JSON)
- Include test mode / seed data endpoints
- Design idempotent operations

DON'T:
- Require browser interaction for verification
- Depend on visual inspection
- Need manual clicking through UI

When Browser Testing is Unavoidable

If browser/headless testing is truly necessary:

• Use Playwright/Puppeteer with script automation
• Create dedicated test endpoints
• Prefer API calls over UI interaction

Workflow

Read Intent file
    ↓
Analyze scope and complexity
    ↓
Identify logical phases
    ↓
Break each phase into steps
    ↓
For each step, define:
    - Test categories needed
    - Implementation scope
    ↓
Define phase gates (e2e criteria)
    ↓
Present plan for approval
    ↓
User confirms or adjusts
    ↓
Save plan to intent/PLAN.md

Output: PLAN.md Template

# Implementation Plan for [Project/Feature]

Generated from: `intent/[name]/INTENT.md`
Date: YYYY-MM-DD

## Overview

- Total Phases: N
- Estimated Complexity: [Low/Medium/High]
- Key Dependencies: [List]

## Phase 1: [Phase Name]

**Goal**: [What this phase delivers]

### Step 1.1: [Component/Feature Name]

**Unit 1: Tests** (Do First)

| Category | Test Cases |
|----------|------------|
| Happy Path | - Case 1: [description] |
|            | - Case 2: [description] |
| Bad Path   | - Invalid input: [specific case] |
|            | - Missing field: [specific case] |
|            | - Wrong state: [specific case] |
| Edge Cases | - Empty input |
|            | - Maximum values |
|            | - Concurrent access |
| Security   | - SQL injection attempt |
|            | - XSS attempt |
|            | - Auth bypass attempt |
| Data Leak  | - Sensitive data in error |
|            | - Logs exposure |
| Data Damage| - Partial write recovery |
|            | - Race condition handling |

**Unit 2: Implementation**

- [ ] Implement [component]
- [ ] Ensure all tests pass
- [ ] Code review criteria: [specific points]

### Step 1.2: [Next Component]

...

### Phase 1 Gate: E2E Verification

```bash
# Verification script
[CLI commands to verify phase completion]

Success Criteria:

• Criterion 1
• Criterion 2

---

Phase 2: [Phase Name]

...

---

Final Verification

# Full system verification script

Risk Mitigation

Risk	Mitigation	Contingency
[Risk 1]	[How to prevent]	[If it happens]

Notes

• [Any additional context]

## Integration with Other Skills

/intent-interview # Create Intent ↓ /intent-review # Approve Intent ↓ /intent-plan # Generate execution plan (THIS SKILL) ↓ [Execute: TDD cycles] ↓ /intent-sync # Write back confirmed details ↓ /intent-check # Verify consistency

## Tips for Good Plans

1. **Right-size phases**: Each phase should be completable in 1-3 days
2. **Clear dependencies**: Note when steps depend on previous steps
3. **Testable gates**: Phase gates must be automatable
4. **Specific test cases**: "Test error handling" is bad; "Test 404 response when resource not found" is good
5. **Security by default**: Include security tests even if not explicitly requested