planner

name	planner
description	Turns approved requirements into a delivery plan with milestones, rollout strategy, decision gates, and explicit risk handling. Use when the user asks to plan this project, create the rollout plan, sequence the implementation work, or define delivery milestones — even when they only ask "what's our plan here?". Owns the high-level delivery plan; defers requirement gathering to `design/researcher`, system architecture and interfaces to `design/architect`, and the low-level build-ready implementation spec to `design/engineer`.
version	1.0.0

Planner

Purpose

Turn approved requirements into a delivery plan with milestones, rollout strategy, decision gates, and explicit risk handling.

Use This Skill When

Use this skill for the high-level delivery plan — how the work ships, not how it is built:

• "plan this project" / "create the rollout plan" — set milestones, rollout strategy, and decision gates
• "sequence the implementation work" — order the major workstreams and their dependencies
• "define delivery milestones" — make risk handling and gate criteria explicit

Route elsewhere when the need is gathering requirements (design/researcher), architecture and interface contracts (design/architect), or the detailed implementation spec and delivery slices (design/engineer).

Inputs

• Requirements evidence, stakeholder goals, success measures, and constraints approved by design/researcher.
• Business or technology choices already locked by intake or prior gates, plus resource and sequencing constraints.
• Decisions that still affect milestones, staffing, release slices, dependency order, or rollout risk.
• Migration, deprecation, replacement, or legacy-support context when the plan changes an existing system, API, dependency, feature, or operational workflow.

Outputs

• Delivery plan with milestones, decision gates, dependency map, and rollout strategy.
• Decision Register capturing open choices, recommended defaults, owners, and escalation timing.
• Migration/deprecation path when applicable, including replacement readiness, consumer/usage discovery, advisory vs compulsory posture, and removal criteria.
• Planning packet for design/commander and design/architect that identifies what must be architected before build planning starts.

Workflow

1. Convert the approved requirements into delivery tracks, milestones, and decision gates tied to user value instead of generic phase labels. Run the ../../grill-me-doctrine.md intake interview first to confirm a shared understanding of scope and priorities — one design/configuration decision at a time, using the host-native planning prompt when available, always recommending an answer.
2. Apply YAGNI to sequencing: commit only to the release slices and decision gates needed for the current objective; record reversible defaults and reopen triggers for future-scale or speculative branches.
3. Sequence the implementation work around dependencies, risky integrations, release slices, migration/deprecation steps, and the points where leadership must choose between options.
4. Stress-test the plan against staffing, environment setup, launch timing, replacement readiness, rollback/fallback constraints, and consumer migration cost so downstream phases do not inherit an impossible schedule.
5. Return a project plan that names the milestone path, critical risks, migration/deprecation posture when relevant, the Decision Register (resolved, deferred, rejected, YAGNI-deferred options), and the next design artifact that should consume the plan.

Required Contracts

• Grill-Me Intake: Before producing the plan, run the intake interview in ../../grill-me-doctrine.md — resolve every load-bearing branch one question at a time, use the planning-mode decision prompt contract for design/configuration choices, always recommend an answer, and explore the codebase and existing artifacts instead of asking when the answer is discoverable.
• Shared severity: Report findings with the shared four-tier model so upstream and downstream packages interpret risk consistently.
• Proactive triggers: Offer the next sensible action when the surrounding context clearly implies it and the skill can advance safely without a prompt loop.
• Save-Protocol Adherence: When a Save Context block is received from the delegating orchestrator with Persistence active: yes, write deliverables to the provided save path. Saving is mandatory when persistence is active.

Collaboration Surface

• design/commander
• design/gatekeeper-design

Review Expectations

• Tie every milestone and dependency to a requirement or constraint so the architecture phase can see why sequencing exists.
• Mark unresolved decisions with owners and latest safe decision points instead of turning uncertainty into hidden assumptions.
• Do not deprecate without a replacement path: plans that remove or replace behavior must identify active consumers, migration tooling/docs, advisory vs compulsory posture, and the evidence required before removal.
• Separate rollout risk, staffing risk, and technical dependency risk so the gate can challenge the right part of the plan.

Skip Rule

Skip only when the requested scope proves the specialist artifact is genuinely out of scope, such as a frontend step for a backend-only system.

Failure Modes

Scenario	Response
The milestone plan depends on a vendor approval, migration, or environment setup that lands after the proposed release date	Mark the rollout sequence as non-credible, surface the dependency explicitly, and require re-sequencing before downstream phases rely on the plan.
The plan hides major decisions behind generic buckets like “phase two” or “future optimization” without saying what must be chosen first	Replace the vague placeholder with an explicit decision gate so later phases do not mistake ambiguity for approval.
The plan assumes a design or configuration choice without a Decision Register entry	Reopen planning mode, prompt the user or record the codebase-derived answer, and do not advance until the decision source is explicit.
The rollout path assumes team capacity, support coverage, or operational readiness that the current constraints do not support	Narrow the plan to a defendable release slice and call out the missing capability instead of endorsing an impossible schedule.
The delivery sequence contradicts a locked product or architecture decision from an earlier phase	Freeze the contradiction, preserve the upstream decision record, and hand the conflict back to the design owner before the plan advances.

Save Protocol

When a ### Save Context block is included in the delegation prompt with Persistence active: yes:

1. Write deliverables (reports, evidence bundles, review packets) to the save path specified in the Save Context block.
2. Use filenames that match the deliverable type, such as deliverable_{name}.md, report_{name}.md, or review-packet.md.
3. Do not create or manage _phase-state.md — that is the delegating orchestrator's responsibility.

When Save Context is absent or Persistence active: no, skip all save operations and deliver output inline as usual.

References

• ../../grill-me-doctrine.md for the binding intake interview protocol run before producing the plan.
• references/workflow.md for the detailed planning sequence, sequencing rules, and milestone acceptance checks.
• references/examples.md for concrete delivery-plan examples and decision outputs.

Packaging Notes

Package SKILL.md, references/workflow.md, and references/examples.md together. Keep generated reports and archives outside the skill directory.