Plan
Use when an ADLC task has an approved spec and needs its technical plan — after /adlc:spec. Writes a phased plan and a progress checklist into the task's card in the configured PM.From its SKILL.md
npx -y skills add johngaynor/adlc --skill planAssembled 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
5.0 KB, as published. Nobody here has run it
Plan
Turn a task's # Specification into a phased technical plan and a live progress
checklist on the same issue — the third stage of the ADLC lifecycle
(brainstorm → spec → plan → execute → pr, see
METHODOLOGY.md).
Arguments
taskRef(optional) — the issue URL or identifier to plan. If omitted:- Use the
taskRefalready held in the session's context (set by a prior/adlc:specin this same session). - Otherwise call
findTasks(has "# Specification", no "# Technical plan")perreference/pm-seam.mdand ask the user which candidate to plan — do not guess when more than one matches.
- Use the
Workflow
- Resolve the task. Determine
taskRefper the Arguments rule above. - Read and gate on the precondition. Call
readTask(taskRef). It must have# Specification. If it does not, refuse and tell the user to run/adlc:specfirst — never draft a plan against an unspecified task. If the spec'sRisks & unknownsblock lists an unresolved blocker, surface it — blockers are resolved or explicitly accepted by the user before planning proceeds. Likewise callreadRelations(taskRef)perreference/pm-seam.md§ Dependencies: when the task has open blockers, name them and get the user's explicit go-ahead before planning proceeds — warn and confirm, never hard-block. - Break the work into phases. Split
# Specificationinto ordered, independently-committable phases. Each phase should be small enough to verify and commit on its own, and named clearly enough that its text can double as a checklist item later. Phases are plain-language engineering tasks with a clear, defined outcome — the pinned skeleton's content rules (engineering-only, brevity) apply here as in the spec. - Write the plan. Call
writeSection(taskRef, "Technical plan", md)perreference/pm-seam.md, following the pinned# Technical planskeleton in its § Artifact skeletons exactly — a short ordering rationale, then one>>> ### Phase <n>: <name>collapsible per phase whose body says in plain language what changes and ends with a**Verify:**line naming that phase's mechanical check, closed by>>>. Never invent or reshape the structure here. This upserts the# Technical planblock; re-running this stage overwrites it cleanly rather than duplicating it. - Write the progress checklist. Call
writeSection(taskRef, "Progress", checklist)per the pinned# Progressskeleton — one- [ ] Phase <n>: <name>line per phase, its text matching the### Phase <n>: <name>heading exactly (minus the###) —/adlc:executeticks these boxes by that same text. - Advance the status. Call
setStatus(taskRef, "Todo")per the seam's Status Mapping — this is the exact point the lifecycle marks the task ready to be worked. - Apply the
planlabel. CallapplyLabel(taskRef, "plan")perreference/pm-seam.md— this auto-creates the label if missing and applies it idempotently, so the card signals the artifact at a glance. - Report and hand off. Point the user at the issue and summarize the
phase breakdown, then invoke the workflow bridge
(
/adlc:next) withcompletedStage: planand thetaskRef. The bridge's prompt is this stage's approval gate — and the last gate before the PR, since the execute→pr hop never prompts: choosing Move to execute — continues through to PR is the user's explicit approval of the plan, Review first shows the new# Technical planand# Progressbefore deciding.
Boundaries
- Never start writing code, create a branch, or touch a worktree in this
stage — that is
/adlc:execute. - Ask First before changing the agreed
# Specification— if the plan surfaces a gap or a needed scope change, flag it to the user rather than quietly reshaping the spec. - Never invent an artifact outside the canonical layout in
reference/pm-seam.md. - Never pass an open blocker silently — per the seam's § Dependencies it is surfaced and explicitly accepted, never ignored and never a hard refusal.
- Never let coding start on an unapproved plan — approval arrives through the bridge (Move to execute, or an explicit Run-to-PR horizon per the bridge's Boundaries), never by assumption.
Done when
The issue has # Technical plan and # Progress matching the pinned skeletons
in reference/pm-seam.md § Artifact skeletons (one - [ ] per phase), carries the
plan label, its status is Todo, and the hand-off has passed through the
bridge — the user approved the plan (or their Run-to-PR horizon chained on), or
chose Stop here and the task rests cleanly at Todo.