plan-project

name	plan-project
description	Turn ideas and design docs into a sprint-ready, dependency-linked backlog — reconcile intake, break down, write tickets, sequence, assign, and shape for Jira or Linear.
disable-model-invocation	true

Plan Project

Take a project from "I have ideas" — plus whatever design docs, ADRs, or notes exist — to a review-ready backlog: reconciled scope, well-formed tickets, sequenced with real dependencies, assigned by capacity, shaped for the target tracker.

You produce the artifacts; the user reviews and redirects. Output is structured markdown, never a live write to any tracker. When a repo is present, read the code — real slices, real dependencies, and real ownership beat anything inferred from a description.

This is one pipeline of six stages. Run them in order for a full goal→backlog pass, or enter at any stage when the user asks for just that slice ("break this down", "write this ticket", "sequence these", "who takes this"). Each stage discloses its craft to a reference file — read it when that stage runs, not before.

Input contract (entering mid-pipeline)

A stage consumes the previous stage's artifact. When the user enters directly:

• If the upstream artifact is present — pasted, in a file they point at, or already in the conversation — use it as-is.
• If it is absent, reconstruct the minimal prerequisite from what exists (the stated goal + the repo), mark it (inferred), and proceed. Never stall to demand ceremony; a concrete draft the user corrects beats an interview.
• Never fabricate a roster or capacity (Stage 4). A missing roster falls back to role-shaped assignment, not invented people.

Stage 0 — Intake & reconcile

Gather the idea and every design doc, ADR, spec, or note in scope. Read them. Real formats you will meet: MADR ADRs (status / context / options / consequences), meridian specs (Overview / Requirements / …), handover docs, freeform brain-dumps.

Reconcile them into one work-inventory — a flat list of the actual atoms of work. Across multiple docs, dedupe overlaps and surface contradictions rather than silently picking a side; park genuinely-undecided points under a Needs decision heading. The inventory is the single source of truth the rest of the pipeline reads.

Done when: every decision and work-implying statement in every source doc is either an entry in the work-inventory or an explicit Needs decision item — nothing dropped, no contradiction silently resolved.

Stage 1 — Break down → read breakdown.md

Decompose the work-inventory into initiative → epic → story, MECE (no overlap, no gaps). Default to thin vertical slices; the first slice of each epic is a tracer bullet that proves the path end-to-end. When a repo is present, ground slices and sizes in the real modules.

Done when: every work-inventory entry maps to exactly one vertical-slice leaf (MECE). Full bar in breakdown.md.

Stage 2 — Write tickets → read tickets.md

Draft each leaf into a ticket at the quality bar: a rationale-backed Why, a Scope, and a checkbox Acceptance criteria ending in a concrete ship gate. Lift thin/title-only items up to the bar rather than transcribing them.

Done when: no ticket is title-only — each has a Why, a Scope, and ≥1 checkable acceptance criterion. Full bar in tickets.md.

Stage 3 — Sequence → read sequencing.md

Build the dependency graph (from the breakdown and, when present, the codebase), find the critical path, and order the work risk-first: enabling work before dependents, independent slices in parallel, large structural changes last — one slice per PR, never big-bang. Lay the order onto cycles/sprints and milestones.

Done when: every ticket's blockers are named (or "none") and the dependency graph is acyclic. Full bar in sequencing.md.

Stage 4 — Assign → read assigning.md

Propose owners from the user's roster, folding in a git-history ownership signal when a repo is present. Capacity comes from the user. Flag bus-factor risk and respect WIP limits.

Done when: every ticket has a proposed owner or role profile, and no owner exceeds the capacity the user gave. Full bar in assigning.md.

Stage 5 — Shape for the tracker → read jira.md or linear.md

Render the backlog into the target tracker's model. Pick the target: use the tracker the user names; else infer from what's actually wired to the repo — a linked Jira or Linear integration, tracker URLs in config/docs, the issue-reference style in recent commits and PRs — and state the inference; else ask once. (Key prefixes like PSY- don't disambiguate: Jira and Linear both use PREFIX-123.) Read jira.md for Jira, linear.md for Linear. If the tracker is GitHub Issues, the tool-neutral markdown ships as-is.

Done when: the backlog uses the target's real hierarchy, link/dependency model, and estimate convention — gradable against that file's checklist.

Output

One markdown document, in pipeline order: work-inventory → epic/milestone tree → tickets → sequence + dependency notes → assignment proposal → tracker-shaped rendering. If you defer, cap, or leave a dependency unresolved, say so — never let a partial backlog read as complete.

Principles

• Opinionated on craft, flexible on ceremony. Decisive defaults (vertical slices, INVEST, outcome-framed criteria, tracer-bullet first, small WIP). Scrum / Kanban / cycles / Shape Up are ceremony options, chosen by fit — never forced.
• The artifact is the teaching. Output good enough that a strong engineer who has never planned a sprint learns the shape by reading it. No tutorials, no experience-gating; any "why" is one skimmable line.
• Ticket ≈ issue. Jira and Linear both call them issues; the user may say tickets. Same thing.