* test(evals): scope claims to harness model fixtures and revision Append the neckbeard claims-scoping sentence to one representative expected_output per per-skill manifest so every corpus member states VAL-EVL-032 scope (harness, model, fixtures, revision under test). Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> * test(product-lifecycle): upgrade integrated launch trajectory Add an explicit launch-decision assertion to the new-product lifecycle case so the integrated product-launch scenario terminates in a launch decision recorded as a lifecycle evidence-ledger entry (VAL-CRP-010), and scope its expected_output claims per VAL-EVL-032. Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> * test(production-excellence): add integrated migration reconciliation failure case Add integrated-migration-reconciliation-failure: the production-excellence gate model returns No-go on a reconciliation mismatch, records the failure evidence, produces a rollback/roll-forward decision with an accountable owner, and does not proceed to launch (VAL-CRP-012). Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> * test(agent-production-operations): add privacy boundary escalation case Add integrated-privacy-boundary-escalation (VAL-CRP-015): the runtime control plan halts a cross-boundary EU PII trace export before any data processing, names the privacy boundary, and escalates to jurisdiction- specific legal review and a human operator. Also add a tool-authority- health handoff assertion to the read-only contract case (VAL-CRP-016). Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> * test(lifecycle-evals): add lifecycle evaluation corpus Add the #204 corpus home: run tooling (run-corpus.sh, fake adapter only), programmatic coverage validator (validate-corpus-coverage.py), machine- readable coverage index + human-readable coverage matrix, regression- detection and fixture/source notes, the bounded discovery brief, and a one-snapshot committed set of fake-adapter per-trial run artifacts with harness/model/date scoping fields. Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> --------- Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
Implementation Planning — Turn approved specs into executable delivery plans
Why Install This Skill
A great specification answers "what to build." It does not answer "how to build it across three teams, two repositories, a data migration, and a staged rollout." That gap — between an approved requirement and the first line of code — is where teams lose weeks to misalignment, missed dependencies, and last-minute surprises.
Implementation Planning fills that gap. Give your agent an approved spec or product brief, and it returns a concrete, dependency-aware delivery plan with work breakdown, critical path analysis, ownership, rollout strategy, rollback paths, and verification traceability back to the original requirement.
This skill is designed for real-world complexity: cross-team coordination, multi-repository changes, data migrations with rollback, and staged rollouts with observability gates. It does not assume a single repo or a single team.
What You Get
| Directory entry | What it provides |
|---|---|
SKILL.md |
Core planning workflow: ingest approved input, decompose into workstreams, map dependencies, find the critical path, assign ownership, sequence and parallelize, design rollout and rollback, verify against the original requirement. Includes entry gate (stop if not approved), handoff table to specialist skills, and cross-team/cross-repo guidance. |
README.md |
This file — human-facing overview of what the skill does and how to use it. |
references/discovery-brief.md |
Bounded comparison of existing planning material across the catalog (SDD task plans, release-engineering rollout plans, SRE change plans, product-discovery) and a clear definition of what implementation-planning owns vs. hands off. |
templates/implementation-plan-template.md |
Fillable template for a complete implementation plan: workstreams, ownership, sequencing, rollout stages, rollback triggers, and verification checklist. |
templates/dependency-record.md |
Structured record for dependency mapping, critical path, and handoff contracts between teams or repositories. |
templates/risk-decision-verification.md |
Sections for recording risks, assumptions, unresolved decisions, and verification traceability from plan back to requirement. |
evals/evals.json |
Five output-quality evaluation cases covering ambiguous requirements, cross-repository dependencies, a data migration, a risky rollout, and a plan rejection due to missing prerequisite approval. |
Quick Start
- Ensure you have an approved requirement or specification ready. The skill will stop and decline if the input is not approved.
- Load the skill: your agent reads
SKILL.mdand follows the core workflow. - The agent produces a plan using the templates in
templates/, starting with the implementation plan template. - Review the plan, resolve any open decisions, and hand it off to the specialist skills named in the handoff table.
Triggers
Load this skill when:
- An approved spec or product brief needs a delivery plan.
- A cross-team or multi-repo feature needs work coordination and dependency mapping.
- A data migration needs a staged execution plan with rollback.
- A risky or high-stakes change needs a rollout strategy with observability gates.
- Multiple workstreams need critical-path analysis and ownership assignment.
Do not load this skill when:
- The requirement has not been approved — route to product-discovery or spec-driven-development first.
- You need to write a spec from scratch — route to spec-driven-development.
- You are coding, debugging, or implementing — route to the appropriate engineering skill.
- You are executing the neckbeard issue-to-PR delivery flow — this skill plans work, it does not execute delivery.
Requirements
- No runtime dependencies, API keys, or external services.
- The skill expects an approved requirement or specification as input. An unapproved input triggers the stop condition — no plan is produced.
- Templates use markdown and work with any text editor or agent.