agentsclimarketplace
Sign in

Breakdown milestone

Skill johngaynor/adlc/skills/breakdown-milestone

Use when a milestone needs its issues derived — "break the milestone into issues", "file the phase's tasks", "fill the milestone with issues". Runs a dialogue deriving the task-sized issues from the milestone's exit criteria and the project PRD, then files them into the milestone via /adlc:issue after one batch approval.From its SKILL.md

Install
npx -y skills add johngaynor/adlc --skill breakdown-milestone

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

6.9 KB, as published. Nobody here has run it

Breakdown milestone

Decompose one milestone — an ordered checkpoint per reference/pm-seam.md § Hierarchy — into the task-sized issues that complete its phase: the issue-breakdown stage /adlc:breakdown-project points downstream to. Each derived issue gets only its summary top section (the untitled preamble plus collapsed Notes) per the issue template at skills/issue/template.md — spec and plan depth arrives later through each issue's own lifecycle. This is a planning-layer skill consuming the milestone's exit criteria plus the project's PRD; creation itself is delegated to /adlc:issue — the single owner of issue creation — one call per approved issue, so no creation logic is duplicated here.

Arguments

  • projectRef (optional) — the project whose checkpoint is being filled, threaded in when invoked from /adlc:breakdown-project's closing hand-off. When standalone and omitted, default to .adlc/config.json's pm.project and confirm that default as part of step 4's approval; when neither resolves, ask the user which project.
  • milestoneRef (optional) — the milestone's name or ID. When omitted, call listMilestones(projectRef) per reference/pm-seam.md and ask the user which checkpoint to break down.

Workflow

  1. Resolve the project and milestone. Per the Arguments rule. Load the dialogue context: the milestone's exit criteria from listMilestones(projectRef) and the project's PRD via readProject — with no PM configured (no pm block with "provider": "linear" in .adlc/config.json), the milestone may instead be a stub under .ai/product/milestones/ and the PRD a draft under .ai/product/projects/; read those. A milestone with no exit criteria, or a project still carrying its PRD pending-marker, is a question, not a refusal: issues derived without them are guesses, so recommend /adlc:milestone or /adlc:project first; the user may override and continue from the dialogue alone.
  2. Pre-flight the checkpoint's existing issues. With Linear configured, call findTasks(project + milestone) per reference/pm-seam.md and show what already sits in the checkpoint. This run is additive, never editorial: existing issues are never modified, re-scoped, or moved here.
  3. Derive the issues in dialogue. One question at a time, propose the task-sized changes the exit criteria and PRD imply and refine them with the user. Each candidate must pass the seam's § Hierarchy decision test at issue size — one agent could spec → plan → PR it; an oversized candidate is split here, never filed whole. Each issue gets the issue template's top-section ingredients: a concise title, the 1–2 sentence preamble, and Notes bullets carrying problem, motivation, and success criteria sharply enough that a fresh session could run /adlc:spec from the card alone. Spec-level detail is declined, not stored — it belongs to each issue's own lifecycle stages.
  4. Present the issue set for approval. The full ordered list — titles, preambles, Notes — plus the project and milestone they land in, approved as a set before any write. A title colliding with an existing issue in the checkpoint is resolved here: adopt that issue as the task (leave it untouched, skip its create) or rename the new one — never a duplicate. When the set's order implies real dependencies, propose the chain here per reference/pm-seam.md § Dependencies — each issue blocked by its predecessor; ordered does not always mean dependent, so the chain is offered with the set, never assumed. Iterate until approved. This batch approval satisfies /adlc:issue's own approval gate for every draft in the set — the threaded drafts arrive pre-approved, so the delegated runs re-prompt only if something changes mid-flight.
  5. Create the issues. One /adlc:issue delegation per approved issue, run serially in the approved order, threading the title, the approved top section, and the project + milestone. Never call createTask directly from this stage — creation is /adlc:issue's surface in both its modes, Linear (status stays the seam's Backlog default) and no-PM (.ai/product/issues/<kebab-slug>.md); each delegated run's URL or path report rides back into this stage's report. When the approved set includes the dependency chain, call linkDependency(predecessor, successor) per reference/pm-seam.md after each create, so every issue lands linked to the one before it (Linear path only — the no-PM drafts carry no relations).
  6. Verify by read-back. With Linear configured, re-read the checkpoint's issue list (findTasks(project + milestone) again) and diff it against the approved set: every approved issue present, attached to the project and the milestone. A missing or unattached issue is reported with the corrective step, never silently dropped. With no PM, confirm each .ai/product/issues/ file exists.
  7. Report and point downstream. List the created issues in order with their URLs (or file paths) and close by noting each rests at Backlog with only its top section: any of them continues through the normal lifecycle — /adlc:spec, then /adlc:plan — starting with whichever the user wants to work first.

Boundaries

  • Never write to the PM or the fallback files before the user approves the full issue set.
  • Never accept spec or plan depth into a top section — preamble + Notes only, per the issue template; depth belongs to each issue's own /adlc:spec and /adlc:plan.
  • Never modify, re-scope, or move an existing issue — this skill is additive; a same-title hit is resolved at the approval gate (adopt or rename).
  • Never call createTask directly — every create goes through /adlc:issue with the approved draft threaded.
  • Never chain a dependency the user didn't approve — the chain is part of the step 4 approval, per the seam's § Dependencies.
  • Ask First before deriving issues beyond what the exit criteria and PRD state.

Done when

Every approved issue exists at Backlog in the project and milestone (or as a draft under .ai/product/issues/ with no PM), the read-back diff matches the approved set with any gap reported, each issue carries only its summary top section — and the user holds the list, knowing each issue continues through its own lifecycle from /adlc:spec onward.

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.