| name | create-implementation-plan |
| description | Create a new implementation plan or sub-plan for cqlsh-rs features, refactoring, or infrastructure work. Use when asked to plan a feature, create a design document, write an implementation plan, break down a task into phases, or design architecture for a component. Produces structured, AI-executable plans with deterministic language. |
Create Implementation Plan
Generate implementation plans for the cqlsh-rs project that are fully executable by AI agents or humans, using deterministic language with zero ambiguity.
Context
This project follows a phased implementation plan defined in docs/plans/high-level-design.md with 14 sub-plans (01-14). New plans must align with the existing architecture and phasing.
Before writing a plan, read:
docs/plans/high-level-design.md — master plan and architecture- The relevant existing sub-plan(s) for the area being planned
Plan File Specifications
Location and Naming
Save in docs/plans/ directory using the naming convention:
docs/plans/[NN]-[component].md
Where NN is the next available number and component describes the area.
For sub-plans or detailed breakdowns:
docs/plans/[NN]-[component]-[detail].md
Plan Structure
Every plan must include these sections:
# Sub-Plan SPNN: [Title]
> Parent: [high-level-design.md](high-level-design.md) | Phase N
>
> **This is a living document.** Update it as development progresses.
## Objective
[1-2 sentences: what this plan achieves and why it matters]
---
## Requirements & Constraints
| ID | Type | Description |
|----|------|-------------|
| REQ-01 | Requirement | ... |
| CON-01 | Constraint | ... |
| GUD-01 | Guideline | ... |
## Design Decisions
| Decision | Choice | Rationale | Alternatives Rejected |
|----------|--------|-----------|----------------------|
| ... | ... | ... | ... |
## Implementation Tasks
### Phase N.M: [Phase Title]
| # | Task | Description | Validation |
|---|------|-------------|------------|
| N.M.1 | ... | ... | ... |
| N.M.2 | ... | ... | ... |
## Dependencies
| ID | Dependency | Required By |
|----|-----------|-------------|
| DEP-01 | ... | Task N.M.X |
## Testing Strategy
| ID | Test Type | Description | Validation |
|----|-----------|-------------|------------|
| TEST-01 | Unit | ... | ... |
| TEST-02 | Integration | ... | ... |
## Risks
| ID | Risk | Mitigation |
|----|------|-----------|
| RISK-01 | ... | ... |
## Open Questions
| # | Question | Status | Decision |
|---|----------|--------|----------|
| 1 | ... | Open / Resolved | ... |
Writing Standards
Language
- Use explicit, unambiguous language requiring zero interpretation
- Every task must be independently actionable
- Include specific file paths and code references where known
- Define all variables and configuration values explicitly
- Use imperative mood: "Implement X" not "X should be implemented"
Compatibility Matrix
When planning features, reference the 100% compatibility matrix in the high-level design. Every CLI flag, environment variable, and shell command in Python cqlsh must be accounted for.
Task Granularity
Each task should be:
- Completable in a single focused session
- Independently testable
- Clear about inputs and expected outputs
Validation Criteria
Every task must have a validation column that describes how to verify completion. Use concrete criteria:
- "Unit test passes" (not "test it")
- "Output matches Python cqlsh for
DESCRIBE KEYSPACE system"
- "
cargo test --test integration_driver passes"
Living Document Policy
Plans in this project are living documents:
- Update on decision: when an open question is resolved, update immediately
- Prune after research: remove speculative options that were not chosen
- Document reasoning: explain why alternatives were rejected
- Plans serve as source of truth alongside the codebase
- When tasks are completed, update
docs/progress.json to reflect the new state (see /development-process Step 5b)
