spec-kit-plan

Create a technical implementation plan from a feature specification.

Input: Optionally specify a change name. If omitted, infer from context or ask.

Steps

1. Select the change and load artifacts

   Load specs/changes/<name>/spec.md. If it does not exist, prompt to use the spec-kit-specify skill first.

   Also load specs/features/ relevant to the area being changed.

2. Research unknowns

   If the spec contains unresolved [NEEDS CLARIFICATION] markers, pause and suggest using the spec-kit-clarify skill first unless the user explicitly wants to proceed.

3. Write specs/changes/<name>/plan.md

   Structure:

# Plan: <Feature Name>

## Architecture
<Bounded context, layers affected, dependency direction. Must comply with FRAMEWORK.md dependency rule.>

## Data Models
<Entities, value objects, aggregates. Identity vs. structural equality. Invariants.>

## Interface Contracts
<Ports, use case signatures, domain events. Technology-agnostic.>

## Implementation Phases
1. <Phase name> — <what it establishes>
2. ...

## Decisions & Rationale
| Decision | Rationale | Alternatives Considered |
|----------|-----------|------------------------|

## Constraints & Risks
<Known constraints, open technical risks.>

Rules:

• Dependency direction must be infrastructure -> application -> domain. Never invert.
• External dependencies affecting business behavior must sit behind ports.
• Repositories are per aggregate root, not per table.
• No framework names in domain or application layer design.
• Cross-context communication via domain events or application services only.

1. Constitution check

   Before finishing, verify the plan does not violate any FRAMEWORK.md non-negotiable architecture rules.

Output

After writing the plan:

• Confirm file location.
• Highlight any architecture decisions worth the user's attention.
• Next step: "Use the spec-kit-tasks skill to generate the task list."

Guardrails

• No code generation — plan only.
• If the spec has unresolved clarifications that affect architecture, surface them rather than guessing.
• Protect the domain model first; adapt infrastructure around it.