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

• If a file path is provided, read it first and note goals, non-goals, constraints, and gaps.

• 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:

• Never ask obvious questions. If the codebase or spec already answers it, do not ask it again.

• Ask about edge cases and failure modes.

• Probe for hidden complexity (state transitions, migrations, concurrency).

• Challenge assumptions when they create risk or ambiguity.

• Identify parallelization boundaries and serial dependencies.

• 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:

• Serial dependencies that must complete first

• Parallel workstreams that can run independently

• 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:

[Feature Name] Implementation Plan

Overview

[2-3 sentence summary of what this implements and why]

Goals

• [Explicit goal 1]
• [Explicit goal 2]

Non-Goals

• [What this explicitly does NOT do]

Assumptions and Constraints

• [Known constraints or assumptions]

Requirements

Functional

• [Requirement]

Non-Functional

• [Performance, reliability, security, compliance]

Technical Design

Data Model

[Schema changes, new entities, relationships]

API Design

[New endpoints, request/response shapes, versioning]

Architecture

[System diagram in text or mermaid, component interactions]

UX Flow (if applicable)

[Key screens, loading states, error recovery]

Implementation Plan

Serial Dependencies (Must Complete First)

These tasks create foundations that other work depends on. Complete in order.

Phase 0: [Foundation Name]

Prerequisite for: All subsequent phases

Parallel Workstreams

These workstreams can be executed independently after Phase 0.

Workstream A: [Name]

Dependencies: Phase 0 Can parallelize with: Workstreams B, C

Workstream B: [Name]

Dependencies: Phase 0 Can parallelize with: Workstreams A, C

Merge Phase

After parallel workstreams complete, these tasks integrate the work.

Phase N: Integration

Dependencies: Workstreams A, B, C

Testing and Validation

• [Unit, integration, end-to-end coverage]
• [Manual test plan if needed]

Rollout and Migration

• [Feature flags, staged rollout, migration steps]
• [Rollback plan]

Verification Checklist

• [Exact commands or manual steps the agent can run to verify correctness]
• [Expected outputs or success criteria]

Risk Assessment

Open Questions

• [Question that still needs resolution]

Decision Log

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

• Persist until the plan is implementable and verifiable by the agent, but avoid user fatigue by batching questions.

• Challenge vague answers when they affect design decisions.

• Identify hidden work and operational overhead.

• Think about the merge and integration steps early.

• Summarize understanding and confirm before writing the final plan.

Completing the Interview

After sufficient rounds of questions:

• Summarize your understanding back to the user

• Confirm the parallelization strategy

• Write the complete plan to the target file

• Ask if any sections need refinement