mission-breakdown

Mission Breakdown

Break down roadmap features into implementation missions — requirement-focused, session-sized, design before code.

Config Preamble

Before any operation, locate the PlanKit folder and read its config:

1. Check if PlanKit/ exists in the project root. If not, check plan-kit/.
2. If neither exists, tell the user: "No PlanKit folder found. Run /plankit:init to set up PlanKit first."
3. Read .config.json from the PlanKit folder to get the naming convention.

Determine file paths:

• Roadmap: PlanKit/Roadmap.md or split PlanKit/Roadmap/ — UpperCamelCase
  • Or: plan-kit/roadmap.md or split plan-kit/roadmap/ — kebab-case
• Features dir: PlanKit/Features/ or plan-kit/features/
• Progress: PlanKit/Progress.md or plan-kit/progress.md

Mission Breakdown Workflow

1. Read the Roadmap — load all active (non-✅) versions and their features
2. Select a feature:
   • If the user specified a feature name → find it in the roadmap
   • If not: a. Tell the user: "Let me review your roadmap and codebase first, then I'll help you pick the right feature to break down." b. Scan the codebase — read relevant source files, project docs (AGENTS.md, README.md, etc.), and existing Features/ directory to understand the current state c. Present a roadmap summary with recommendations — show ALL active features with brief descriptions, note which ones have dependencies on others, which seem most impactful or foundational, and which already have missions defined. Recommend which feature to tackle next based on your investigation. d. Ask via AskUserQuestion — include every non-✅ feature that doesn't have missions yet. If there are more than 4 features, present the top recommendations as options and note others are available via "Other"
   • If the feature has ✅ already, warn: "This feature is marked complete. Continue anyway?"
3. Deep investigation — after feature selection:
   • Tell the user: "Let me investigate your codebase to understand the current architecture for [feature name]."
   • Read relevant source files, data models, existing implementations, and any related documentation
   • This is always done automatically for code features — no need to ask permission
4. Determine feature number:
   • Read nextFeatureNumber from .config.json
   • Use that number (zero-padded to 3 digits) for this feature
   • Increment nextFeatureNumber in .config.json and write it back
   • This ensures globally unique feature numbers that are never reused
5. Discuss details and open questions — before proposing any mission breakdown:
   • Present your investigation findings: what you found in the codebase, what's already implemented, what the current architecture looks like
   • Review the roadmap feature's Key decisions and Open questions sections
   • Identify the biggest uncertainties that affect mission scope or content
   • Discuss these with the user conversationally — ask questions grounded in specific findings (e.g., "I found X in your codebase, which means Y — does that match your intent?" NOT generic questions like "What framework do you prefer?")
   • When referencing project files, always include the file path and a one-sentence description of what the file contains
   • Cross-reference existing spec documents and project docs before asking questions that may already be answered
   • Record the user's answers — they will be baked into the mission files as requirements
6. Plan the missions:
   • Analyze the feature's scope, decisions (including from the discussion), and remaining open questions
   • Apply splitting guidelines:
     • Design always separate from implementation
     • Content creation separate from code
     • One session ≈ one mission (completable in one focused working session)
     • Small cross-repo changes can combine
   • Determine: single mission (→ just a file) or multiple missions (→ folder with mission files)
7. Present the plan — show the proposed mission breakdown using standard markdown (NOT decorative boxes — they constrain text width):