3.3KB
Plan
Version: 1.0.0
Purpose
Create the smallest implementation plan necessary to safely and verifiably complete the requested work.
The plan must be based on discovered project evidence.
Do not design from generic assumptions when the project already contains relevant patterns.
Before Planning
Confirm that discovery has identified:
OBJECTIVE
CURRENT STATE
DESIRED STATE
CONSTRAINTS
RELEVANT COMPONENTS
EXISTING PATTERNS
If critical context is still missing, use Diagnostic Intake before planning.
Form Initial Approach
State the proposed approach in concise terms.
Include:
WHAT WILL CHANGE
WHY THIS APPROACH FITS
WHAT WILL REMAIN UNCHANGED
Treat this as a working hypothesis.
Mirror Audit
Before finalizing the plan, audit the initial approach using:
.ai/skills/mirror-audit/SKILL.md
Check for:
hidden assumptions
failure modes
edge cases
security
data integrity
compatibility
rollback
maintainability
unnecessary complexity
Revise the approach when the audit reveals a real weakness.
Plan Structure
A normal implementation plan should contain:
## Objective
[...]
## Files / Components
- [...]
- [...]
## Implementation Sequence
1. [...]
2. [...]
3. [...]
## Risks
- [...]
## Verification
- [...]
## Rollback
[...] // only when relevant
Scale to Complexity
Fast Path
For trivial work:
1. make change
2. verify
Do not generate a formal architecture plan.
Standard Path
For normal feature work:
1. inspect affected component
2. modify implementation
3. update related tests
4. verify
5. review
High-Risk Path
For migrations, security, infrastructure, destructive changes, or major architecture:
include:
preconditions
backup
rollback
execution order
verification gates
recovery
red-team review
Dependencies
Identify dependencies that affect sequencing.
Example:
database schema
↓
data access layer
↓
service
↓
controller
↓
tests
Do not order work arbitrarily when dependencies require a specific sequence.
Verification Plan
Specify how each meaningful result will be verified.
Prefer:
existing test
targeted test
build
static analysis
smoke test
query
health check
direct execution
Avoid:
verify that it looks right
when stronger evidence is available.
Rollback
Define rollback when:
change is destructive
production state changes
schema changes
data transforms
deployment can partially fail
external state changes
Do not create elaborate rollback plans for trivial reversible edits.
Scope Control
Explicitly identify what the implementation will NOT change when scope drift is likely.
Example:
This change will add the import status reporting.
It will not replace the existing Access import mechanism.
Avoid
Do not:
create plans longer than the work
introduce architecture not justified by the request
include speculative future features
list every theoretical risk
repeat discovery details unnecessarily
Output
Return the finalized implementation plan.
If the plan reveals a blocker, surface it before implementation.
Otherwise proceed according to the current task's execution mode.