Create a Plan Skill

This skill runs a structured technical interview to turn a rough idea or an existing spec into a detailed, implementable plan. The output is organized for parallel execution: foundations first, then independent workstreams, then merge and integration.

Invocation

The user will provide one of:

• A path to a spec or plan file (for example: SPEC.md, PLAN.md, RFC.md)
• A rough description of what they want to build
• A feature request or problem statement

Output is always written to PLAN.md in the repo root.

Process

Phase 0: Preflight

1. If a file path is provided, read it first and note goals, non-goals, constraints, and gaps.
2. Confirm you will produce PLAN.md as the output in the repo root. If PLAN.md already exists, update it rather than creating a new file.

Phase 1: Discovery

Summarize what is known, then identify missing details. Focus on:

• Goals and non-goals
• Constraints (time, budget, platform, dependencies)
• Success metrics and acceptance criteria

Phase 2: Deep Interview

Use the AskUserQuestion (Claude) and/or request_user_input (Codex) tools in rounds. Ask 1-3 questions per round. Each round should go deeper and avoid repeating what is already known.

CRITICAL RULES:

1. Never ask obvious questions. If the codebase or spec already answers it, do not ask it again.
2. Ask about edge cases and failure modes.
3. Probe for hidden complexity (state transitions, migrations, concurrency).
4. Challenge assumptions when they create risk or ambiguity.
5. Identify parallelization boundaries and serial dependencies.
6. If the user is unsure, propose a default and ask for confirmation.

Question categories to cover as relevant:

• Technical architecture and data flow
• Data model and state management
• API contracts and versioning
• Caching and invalidation
• Background jobs, retries, and idempotency
• Error handling and recovery
• Observability and debugging
• Performance, scale, and SLAs
• Security, privacy, and compliance
• Integrations and external dependencies
• UX flows, accessibility, and responsiveness
• Rollout, migration, and rollback
• Testing strategy and validation

Phase 3: Dependency Analysis

Identify:

1. Serial dependencies that must complete first
2. Parallel workstreams that can run independently
3. Merge points where work reconvenes

Phase 4: Plan Generation

Write the final plan to PLAN.md. Ensure the plan includes concrete verification steps the agent can run end to end. If the user only wants a plan in chat, provide it inline and mention that it would be written to PLAN.md.

Output Format

The generated plan MUST follow this structure:

markdown
1# [Feature Name] Implementation Plan
2
3## Overview
4[2-3 sentence summary of what this implements and why]
5
6## Goals
7- [Explicit goal 1]
8- [Explicit goal 2]
9
10## Non-Goals
11- [What this explicitly does NOT do]
12
13## Assumptions and Constraints
14- [Known constraints or assumptions]
15
16## Requirements
17
18### Functional
19- [Requirement]
20
21### Non-Functional
22- [Performance, reliability, security, compliance]
23
24## Technical Design
25
26### Data Model
27[Schema changes, new entities, relationships]
28
29### API Design
30[New endpoints, request/response shapes, versioning]
31
32### Architecture
33[System diagram in text or mermaid, component interactions]
34
35### UX Flow (if applicable)
36[Key screens, loading states, error recovery]
37
38---
39
40## Implementation Plan
41
42### Serial Dependencies (Must Complete First)
43
44These tasks create foundations that other work depends on. Complete in order.
45
46#### Phase 0: [Foundation Name]
47**Prerequisite for:** All subsequent phases
48
49| Task | Description | Output |
50|------|-------------|--------|
51| 0.1 | [Task description] | [Concrete deliverable] |
52| 0.2 | [Task description] | [Concrete deliverable] |
53
54---
55
56### Parallel Workstreams
57
58These workstreams can be executed independently after Phase 0.
59
60#### Workstream A: [Name]
61**Dependencies:** Phase 0
62**Can parallelize with:** Workstreams B, C
63
64| Task | Description | Output |
65|------|-------------|--------|
66| A.1 | [Task description] | [Concrete deliverable] |
67| A.2 | [Task description] | [Concrete deliverable] |
68
69#### Workstream B: [Name]
70**Dependencies:** Phase 0
71**Can parallelize with:** Workstreams A, C
72
73| Task | Description | Output |
74|------|-------------|--------|
75| B.1 | [Task description] | [Concrete deliverable] |
76
77---
78
79### Merge Phase
80
81After parallel workstreams complete, these tasks integrate the work.
82
83#### Phase N: Integration
84**Dependencies:** Workstreams A, B, C
85
86| Task | Description | Output |
87|------|-------------|--------|
88| N.1 | [Integration task] | [Concrete deliverable] |
89
90---
91
92## Testing and Validation
93
94- [Unit, integration, end-to-end coverage]
95- [Manual test plan if needed]
96
97## Rollout and Migration
98
99- [Feature flags, staged rollout, migration steps]
100- [Rollback plan]
101
102## Verification Checklist
103
104- [Exact commands or manual steps the agent can run to verify correctness]
105- [Expected outputs or success criteria]
106
107## Risk Assessment
108
109| Risk | Likelihood | Impact | Mitigation |
110|------|------------|--------|------------|
111| [Risk description] | Low/Med/High | Low/Med/High | [Strategy] |
112
113## Open Questions
114
115- [ ] [Question that still needs resolution]
116
117## Decision Log
118
119| Decision | Rationale | Alternatives Considered |
120|----------|-----------|------------------------|
121| [Decision made] | [Why] | [What else was considered] |

Interview Flow Example

Round 1: High-Level Architecture

• "The spec mentions a sync engine. Is this push-based (webhooks), pull-based (polling), or event-driven (queue)?"
• "What is the expected data volume and throughput?"

Round 2: Edge Cases

• "If a batch fails mid-run, do we retry the whole batch or resume from a checkpoint?"
• "What happens when source data is deleted but still referenced downstream?"

Round 3: Parallelization

• "Can we process different categories independently, or are there cross-category dependencies?"
• "Is there a natural partition key that allows sharding?"

Round 4: Operational

• "What is the acceptable latency for sync or processing?"
• "How will operators debug failures and what visibility do they need?"

Key Behaviors

1. Persist until the plan is implementable and verifiable by the agent, but avoid user fatigue by batching questions.
2. Challenge vague answers when they affect design decisions.
3. Identify hidden work and operational overhead.
4. Think about the merge and integration steps early.
5. Summarize understanding and confirm before writing the final plan.

Completing the Interview

After sufficient rounds of questions:

1. Summarize your understanding back to the user
2. Confirm the parallelization strategy
3. Write the complete plan to the target file
4. Ask if any sections need refinement