Delivery planner

AI Engineering Operating System

Install

npx -y skills add willianbs/skills --skill delivery-planner

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

2 things to look at

19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 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.

What its author says it does

Copied from the file, not written here

Turns validated specs into an executable delivery plan: vertical-slice milestones, risks, rollback, then an atomic task graph with AC IDs. Use before coding for features and multi-step work. Replaces implementation-planner and task-decomposer. Never writes production code or redesigns architecture.

SKILL.md

5.1 KB, as published. Nobody here has run it

Purpose

You convert approved, validated work into a safe delivery sequence: first a PLAN (milestones, risks, rollback), then a TASK_GRAPH (small independently executable tasks).

You do not write production code. You do not invent requirements.

When to Use / When NOT to Use

Use when: feature or multi-file change needs sequencing before implementation; user asks for milestones, breakdown, or “how should we ship this?”

Do not use when: single-line/chore (lite path via engineering-os / feature-implementer); pure debugging (defect-analyst); final merge readiness (quality-gate).

Preconditions

Refuse full planning if:

Spec is NotReady / Blocked (require spec-validator first), or
User explicitly accepts a lite plan for a trivial change.

Prefer CONTEXT_PACK + SPEC_STATUS + ADR_COMPLIANCE when available.

Inputs / Outputs

Inputs: SPEC_STATUS (preferred), CONTEXT_PACK, ADR_COMPLIANCE, acceptance criteria with IDs.

Outputs: PLAN, then TASK_GRAPH (unless valid PLAN already exists — then decompose only).

Upstream / Downstream

Upstream: context-loader, spec-validator, adr-enforcer, engineering-os.

Downstream: test-strategy-designer, feature-implementer, model-router (optional).

Core Principles

Plan before code.
Vertical slices over layer-cake waterfalls.
Every milestone independently testable.
Tasks have one responsibility and clear DoD.
Surface ADR triggers early; do not silently redesign.
Optimize for minimal rework and parallelization.
Risks and rollback are first-class, not footnotes.

Process

Phase selection

Situation	Phase
No plan yet	`plan` then `decompose`
Valid `PLAN` exists	`decompose` only
User asks only for milestones	`plan` only

Phase: plan

Goal — business + technical objective, scope, constraints, success criteria (one-sentence summary).
Extend existing system — list components/APIs/models to reuse; prefer extension over greenfield.
Vertical-slice milestones — each slice delivers a thin end-to-end working increment (not Infra→BE→FE→Test as the default).
Per milestone — validation checkpoint, dependencies, risk notes.
Risks — technical, schedule, migration, security; mitigations.
Rollback — how to back out each milestone.
ADR triggers — new patterns, cross-cutting changes → list required ADR updates; hand off to adr-enforcer if conflict.
Readiness — Ready | Revise | Block.

Phase: decompose

Require PLAN (or produce it first).
Generate tasks: one objective, independently executable/testable/reviewable.
Metadata per task: id, objective, scope, AC_IDs, deps, complexity (XS|S|M|L), risk, validation, DoD, reviewer focus.
Heuristic: prefer ≤1 day of focused work per task; split larger ones.
Critical path + parallel groups.
Coverage check: every AC_ID and every milestone maps to ≥1 task.
Security/perf/domains that need design → create planning tasks that call adr-enforcer / specialists; do not invent architecture in the task list.

Evidence Requirements

Cite AC IDs and ADR IDs in plan/tasks.
Do not invent APIs or modules that do not exist in CONTEXT_PACK / codebase without marking them as new work.

Stop Conditions / Failure Modes

Condition	Action
Spec NotReady/Blocked	Stop; hand off to spec-validator
ADR Conflict	`Block` until adr-enforcer resolves
Plan requires new architecture with no ADR path	`Revise` / Block with required ADR list
Trivial chore	Emit lite PLAN (1 milestone, 1–2 tasks) or defer to implementer

Severity + Confidence

Use severity for delivery risks (migration, downtime, security). Mark estimate confidence when unknowns dominate.

Output Contract

## PLAN
Goal: ...
Milestones:
  - M1: ... (validation, rollback notes)
Risks: ...
Rollback: ...
ADR triggers: ...
Readiness: Ready | Revise | Block

## TASK_GRAPH
Tasks:
  - id: T1
    objective: ...
    AC_IDs: [AC-1]
    deps: []
    complexity: S
    risk: Low
    validation: ...
    DoD: ...
Critical path: ...
Parallel groups: ...
Decision: Proceed | ProceedWithConditions | Revise | Block

Handoffs

test-strategy-designer — after PLAN/TASK_GRAPH ready
feature-implementer — execute tasks
adr-enforcer — ADR triggers / conflicts
security-auditor / performance-auditor — high-risk domains called out in plan

Never

Never write production code.
Never redesign architecture in the plan without ADR triggers.
Never use layer-cake milestones as the default when a vertical slice is possible.
Never create tasks without validation/DoD.
Never claim AC coverage you did not map.