User Story

As an operator planning a new initiative (the strategic unit above features — usually 1-3 per quarter, multi-feature, multi-week), I want a /plan-initiative skill that walks me from initiative → milestones → tasks with dependency-aware sequencing and Socratic-shape interview on uncertainties, so that I can structure quarter-shaped work without manually decomposing in prose and losing the dependency graph.

Acceptance Criteria

• Skill at .claude/skills/plan-initiative/SKILL.md
• Starts at initiative level — asks for the strategic goal in one sentence, the rough quarter/timeframe, and the success criterion that would let the operator close the initiative as "done"
• Breaks the initiative into milestones (typically 1-4 weeks of work each) via interview, not auto-decomposition — operator names each milestone, the skill asks clarifying questions
• Captures dependencies between milestones explicitly: per milestone, asks "what blocks this?" and "what does completing this unblock?". Result is a dependency graph (DAG).
• Recommends a sequence based on the DAG + what blocks the most downstream work first (topological sort, with ties broken by operator-stated risk/value)
• Socratic uncertainty interview — for each milestone, surface the questions whose answers would change the plan: "you said X is a milestone — what's the success criterion?", "what would make you cancel this milestone?", "if you had to drop one milestone today, which goes?", "what's your prior on milestone N taking the time you estimated?". Operator can defer with "TBD" — the skill records the uncertainty, doesn't force an answer.
• At end, optionally files the structured milestones as tracker tickets — per-milestone y/n, mirrors the /handover next-task-filing UX from the sibling ticket [Feature] /handover — offer to file 'Next Steps' as tracker tickets after the assessment #376. Each milestone becomes a Feature-shaped or epic-shaped ticket with the dependency links recorded in the body (blocks #N, blocked by #N).
• Outputs a structured initiative doc at projects/<name>/initiatives/<slug>.md (per-project scope) OR at projects/initiatives/<slug>.md (cross-project / framework-wide initiatives). Operator picks scope during the interview.
• Templates: templates/initiative.md + templates/milestone.md (or extend existing templates/prd.md / templates/tickets/feature.md — design call recorded in the skill's AgDR)
• AgDR documenting: (a) the initiative→milestone→task hierarchy, (b) the interview-shape design (Socratic vs LLM-decompose), (c) why dependency-aware sequencing is the headline feature (vs flat lists), (d) how /plan-initiative slots relative to the existing /write-spec / /validate-idea / /feature skill chain
• Skill is idempotent — re-running on an existing initiative doc reads the prior state, asks only the deltas (new milestones, changed dependencies, resolved uncertainties), never starts from scratch
• TBD — refine before starting work

Why this matters

Today's planning skills start at the ticket level (/feature, /task, /bug, /spike) — one unit of work each. The closest "zoom out" surface is /write-spec (PRD-shape — a single feature's full spec) or /validate-idea (5-question pre-spec gate). Neither helps an operator decompose a strategic-shape initiative — "build X capability over the next quarter" — into a sequenced milestone plan.

Operators end up doing this in prose: a markdown file with "Milestone 1: ... Milestone 2: ..." that drifts from the tracker, loses the dependency graph, and rots the moment one milestone slips. /plan-initiative slots BEFORE the existing ticket-level skills — quarter-shape planning that decomposes deterministically into the ticket primitives.

Slot relative to existing skills

/idea            (capture a raw idea)
/validate-idea   (5-question pre-spec gate)
/plan-initiative (NEW — initiative → milestones → tasks, dependency-aware)  ← this ticket
/write-spec      (PRD for one feature)
/feature / /task / /bug / /spike (one ticket at a time)

/plan-initiative is the orchestrator above per-feature work, not a replacement for it. After the interview, each milestone naturally becomes a /write-spec invocation, which decomposes into multiple /feature invocations.

Out of scope (v1)

• Auto-decomposition without operator input — the interview shape is the point; an LLM "write me 10 milestones for X" without Socratic-shape questions is a different product (and a worse one). v2 maybe.
• Cross-initiative dependency graphs (initiative A blocks initiative B) — v1 is one initiative at a time.
• Time/effort estimation per milestone — /plan-initiative captures relative sequencing + uncertainty, not absolute estimates. Operator handles estimates downstream when filing each milestone's tickets.
• Resource allocation / role assignment — out of scope; the framework already has the role-trigger machinery for who-picks-up-what once tickets are filed.
• Gantt chart output / project-management-tool sync — Mermaid for the dependency graph (DAG) is enough for v1; PM-tool integration is its own ticket if anyone needs it.