{
  "schema_version": 1,
  "skill_name": "implementation-planning",
  "evals": [
    {
      "id": "ambiguous-conflicting-requirements",
      "prompt": "Approved spec for 'Unified Search' states: 'Search must return results in under 200ms' and 'Search must scan all document repositories including legacy systems that average 3s response times.' These two requirements conflict. Plan the implementation.",
      "expected_output": "Identifies the conflict between latency target (200ms) and legacy-system dependency (3s). Does not silently accept both. Either resolves the conflict (e.g., async pre-indexing, excluding legacy from real-time, or renegotiating the SLA) or flags it as an unresolved decision with owner and deadline. The plan does not proceed with both requirements treated as simultaneously satisfiable without resolution. Claims are scoped to the harness, model, fixtures, and revision under test.",
      "assertions": [
        "Explicitly identifies the conflict between the two requirements.",
        "Does not produce a workstream that assumes both requirements are simultaneously satisfiable.",
        "Either resolves the conflict with a concrete design choice or flags it as an unresolved decision with owner and deadline.",
        "References the approved spec as the source of both requirements.",
        "Output includes a traceability statement linking the conflict back to the original spec."
      ]
    },
    {
      "id": "cross-repository-dependencies",
      "prompt": "Approved requirement: 'Add OIDC-based single sign-on to the customer portal.' The portal is in repo A (frontend team), the auth service is in repo B (platform team), and user profile data lives in repo C (identity team). Auth service must add OIDC support before the portal can integrate. Plan the implementation across the three repositories.",
      "expected_output": "Three workstreams across three repos with explicit ownership. Hard dependency: repo B (auth service OIDC) blocks repo A (portal integration). Repo C (profile data) is a soft dependency that can run in parallel. Includes cross-repo handoff contracts (API contract for OIDC endpoints), integration checkpoints, and a coordination mechanism. Each repo has a named owner.",
      "assertions": [
        "At least three workstreams, each mapped to a repository and team.",
        "Hard dependency from portal (repo A) to auth service (repo B) is explicit.",
        "Repo C (profile data) is correctly identified as parallel or soft dependency.",
        "Cross-repo handoff contract includes API interface definition.",
        "Coordination mechanism named (e.g., shared channel, sync meeting)."
      ]
    },
    {
      "id": "data-migration-with-rollback",
      "prompt": "Approved spec: 'Migrate the orders table from a monolithic Postgres database to a dedicated orders service with its own database. No downtime. Must be able to roll back within 10 minutes at any stage.' Plan the implementation.",
      "expected_output": "Staged migration plan with dual-write period, backfill, verification, cutover, and cleanup. Each stage has a rollback procedure with a time estimate under 10 minutes. Forward and backward schema compatibility addressed. Includes data reconciliation before old data is dropped.",
      "assertions": [
        "Dual-write or backfill strategy defined for the transition period.",
        "At least three stages (e.g., dual-write, cutover, cleanup).",
        "Each stage has a rollback procedure with time estimate.",
        "Schema compatibility (forward and backward) addressed.",
        "Data reconciliation step before old data cleanup."
      ]
    },
    {
      "id": "risky-rollout-with-observability",
      "prompt": "Approved requirement: 'Replace the existing payment provider integration with Provider Y across all regions (US, EU, APAC). Provider Y is new and untested at our scale. The business cannot tolerate more than 0.1% payment failure rate during transition.' Plan the rollout.",
      "expected_output": "Staged rollout by region with explicit gates. Starts with lowest-risk region, includes observability signals (payment failure rate, latency, error budget consumption), defines per-stage rollback triggers, and gates each stage on the failure-rate SLA. Does not propose a big-bang switch. Includes a parallel-run or shadow-mode phase.",
      "assertions": [
        "Staged rollout by region, not big-bang.",
        "Lowest-risk region first with explicit rationale.",
        "Per-stage observability signals defined (failure rate, latency).",
        "Rollback trigger references the 0.1% failure-rate SLA.",
        "At least one stage includes parallel-run or shadow-mode before full cutover."
      ]
    },
    {
      "id": "reject-unapproved-prerequisite",
      "prompt": "The product manager shared a draft PRD for 'AI-Powered Recommendations' in a Google Doc. There is no approved spec, no architecture decision record, and no review gate has been passed. The PM asks: 'Can you put together an implementation plan so we can estimate timeline for the board meeting?' Plan the implementation.",
      "expected_output": "Does NOT produce an implementation plan. States that the input is not approved and cites the missing approval explicitly: no approved spec, no ADR, no review gate passed. Routes to upstream skills (spec-driven-development for spec authoring, product-discovery if requirements are unvalidated). Does not produce a draft plan, partial work breakdown, or timeline estimate.",
      "assertions": [
        "Does not produce an implementation plan or work breakdown.",
        "Explicitly states the missing approval: no approved spec, no ADR, no review gate.",
        "Declines to estimate timeline without an approved foundation.",
        "Routes to upstream skills (spec-driven-development or product-discovery).",
        "Does not produce a 'draft' or 'preliminary' plan to work around the gate."
      ]
    },
    {
      "id": "multi-team-ownership-conflict",
      "prompt": "Approved spec for 'Real-Time Dashboard' requires: (a) streaming pipeline owned by data-infra team, (b) API layer owned by backend team, (c) frontend owned by web team, (d) deployment owned by platform team. The data-infra team and backend team both claim they own the API contract between pipeline and API. No one has authority to resolve the dispute. Plan the implementation.",
      "expected_output": "Identifies the ownership conflict over the API contract as a blocking unresolved decision. Does not assign the contract to one team by assumption. Flags it as DEC-U with owner (the decision-maker who can resolve it, not either team) and deadline. The dependent workstreams are marked as blocked until the decision is resolved. Does not produce a plan that silently picks a side.",
      "assertions": [
        "Ownership conflict over the API contract is explicitly identified.",
        "Recorded as an unresolved decision, not resolved by assumption.",
        "Dependent workstreams marked as blocked until the decision is resolved.",
        "Decision owner is a role with authority to resolve the dispute.",
        "Does not assign the API contract to either team unilaterally."
      ]
    },
    {
      "id": "route-ongoing-project-control",
      "prompt": "Our approved implementation plan is finished. Help run weekly milestone reviews, handle vendor slips and scope changes, and prepare sponsor recovery decisions.",
      "expected_output": "Routes ongoing project control to technical-project-management while preserving detailed planning ownership.",
      "assertions": [
        "Routes recurring milestone, change and recovery management to technical-project-management.",
        "Does not reframe the whole request as writing another implementation plan.",
        "Preserves prerequisite approval for detailed implementation planning."
      ]
    }
  ]
}

# Discovery Brief — Implementation Planning

## Purpose

This brief surveys existing planning-related material in the agent-skills
catalog, identifies overlaps and gaps, and defines the ownership boundary for
the implementation-planning skill. It answers: **what does this skill own, and
what does it deliberately hand off to others?**

## Existing planning material in the catalog

### spec-driven-development — task plans

SDD produces a `TASK-PLAN.md` as part of its phase-4 decomposition step. That
task plan is **specification-local**: it decomposes a single spec into tasks
within the spec's own scope, primarily for a single agent or team following the
SDD pipeline. It is designed for the SDD factory model — spec in, code out.

**What implementation-planning adds:** SDD task plans do not address cross-team
coordination, multi-repository dependency mapping, data migration staging,
rollout strategy design, or the handoff between separately-owned workstreams.
Implementation planning operates at the level **above** a single spec's task
plan — it coordinates multiple workstreams, each of which may be driven by its
own SDD pipeline or specialist skill.

### release-engineering — rollout plans

Release engineering covers promotion gates, canary mechanics, progressive
delivery, feature flags, and release-train coordination. Its rollout plans are
**pipeline-oriented**: how the release system moves artifacts through stages.

**What implementation-planning adds:** Release engineering assumes a single
release artifact or coordinated train. It does not produce the cross-workstream
dependency map, the ownership assignment, or the verification-traceability
matrix from requirement to workstream. Implementation planning hands the rollout
**design** to release-engineering for pipeline mechanics, but owns the rollout
**strategy** — which stages, what each stage gates on, what triggers rollback,
and how the rollout fits the broader plan.

### site-reliability-engineering — change plans

SRE covers change-management practices: change windows, SLO-based gradual
rollout, error budgets, and operational readiness. Its change plans are
**operations-oriented**: what the on-call responder needs to know.

**What implementation-planning adds:** SRE change plans assume an operations
perspective on a single change. They do not design the work breakdown, critical
path, or handoff contracts between teams. Implementation planning produces the
plan that feeds into SRE change management — the SRE change plan is a consumer
of the rollout stage definition, not its author.

### product-discovery — requirements gathering

Product discovery interviews stakeholders, surfaces hidden assumptions, detects
gaps, resolves conflicts, and translates conversations into structured SDD
specs. It is **upstream** of implementation planning.

**What implementation-planning adds:** No plan content. The boundary is
clear: product-discovery produces the **input** to an SDD spec; SDD produces the
**approved spec**; implementation-planning consumes the approved spec and
produces the **delivery plan**. Implementation planning never performs
discovery.

### product-methodology — prioritization (RICE, MoSCoW)

Product-methodology owns tactical prioritization frameworks. Implementation
planning may **cite** a prioritization output (e.g., "these three workstreams
are priority-1 per the product methodology RICE assessment") but never
re-derives RICE, MoSCoW, or other prioritization mechanics.

### Other relevant skills (no ownership conflict)

| Skill | Relationship |
|---|---|
| `qa-methodology` | Consumes the verification section of the plan; designs the test strategy for each workstream |
| `platform-engineering` | Consumes infrastructure or CI/CD requirements surfaced in the plan |
| `secure-software-engineering` | Consumes security requirements; the plan identifies security-sensitive workstreams and routes them |
| `data-engineering` | Consumes data migration staging; the plan defines the stages, cutover, and reconciliation |
| `api-design-and-evolution` | Consumes API contract dependencies identified in the plan |
| `adr-authoring` | The plan may identify architecture decisions that need formal ADRs |
| `backend-engineering` / `frontend-engineering` | Consume individual workstreams from the plan for implementation |
| `neckbeard` | The plan is an input to a neckbeard change-request journey, but this skill does not execute the journey itself |

## Ownership boundary

### What implementation-planning OWNS

1. **End-to-end delivery planning** for approved requirements spanning one or
   more teams, repositories, or systems.
2. **Work decomposition** into vertical slices, workstreams, and completion
   criteria.
3. **Dependency mapping** — hard and soft dependencies, critical path, and
   coordination interfaces.
4. **Ownership assignment** — who is accountable for each workstream and each
   dependency.
5. **Sequencing and parallelism** — which workstreams run concurrently, which
   are sequential, and where they synchronize.
6. **Rollout strategy design** — stages, gates, observability signals, and
   rollback triggers. (Pipeline mechanics are handed to release-engineering.)
7. **Rollback and recovery path design** — per-stage rollback procedures,
   including data rollback.
8. **Verification traceability** — mapping every workstream back to the approved
   requirement.
9. **Unresolved decision and risk tracking** — capturing what could not be
   resolved during planning, with owners and deadlines.
10. **Entry-gate enforcement** — rejecting unapproved inputs.

### What implementation-planning HANDS OFF

1. **Discovery and requirements elicitation** → product-discovery.
2. **Specification authoring and phase gates** → spec-driven-development.
3. **Implementation (coding, debugging, architecture design)** → backend-engineering, frontend-engineering, software-architecture-analysis.
4. **Release pipeline mechanics (canary config, feature flags, promotion automation)** → release-engineering.
5. **SLO definition, error budgets, incident response procedure** → site-reliability-engineering.
6. **Threat modeling, security requirements authoring** → secure-software-engineering.
7. **QA test strategy and verification plan authoring** → qa-methodology.
8. **Platform infrastructure provisioning** → platform-engineering.
9. **API contract design** → api-design-and-evolution.
10. **The neckbeard issue-to-PR delivery lifecycle** — phase gates, delivery-packet sequencing, and orchestration are separate concerns.

# Dependency and Handoff Record

> Complements the [implementation plan template](implementation-plan-template.md).
> Fill one record per implementation plan. Each dependency must have an owner
> and a handoff contract.

## Dependency inventory

### Hard dependencies (blockers)

A hard dependency blocks progress: the dependent workstream cannot start or
complete until the dependency is satisfied.

| ID | Dependent workstream | Depends on (workstream / team / system) | What is needed | Owner of dependency | Needed by date | Status |
|----|---------------------|----------------------------------------|----------------|--------------------|---------------|--------|
| DEP-H1 | _[WS-N]_ | _[WS-M / team-X / service-Y]_ | _[specific artifact or condition]_ | _[name or role]_ | _[date]_ | _[on-track / at-risk / blocked]_ |

### Soft dependencies (preferences)

A soft dependency is preferred but not blocking: the work can proceed without
it, but quality, efficiency, or risk profile improves if it is satisfied.

| ID | Dependent workstream | Preferred input | Why it helps | Owner | Desired by | Fallback if unsatisfied |
|----|---------------------|----------------|-------------|-------|-----------|------------------------|
| DEP-S1 | _[WS-N]_ | _[design review from team-X]_ | _[reduces rework risk]_ | _[name]_ | _[date]_ | _[proceed without review; accept rework risk]_ |

## Critical path

The critical path is the longest chain of hard dependencies from start to
completion.

```
Start → [WS-A] → [WS-B (depends on WS-A)] → [WS-C (depends on WS-A, WS-B)] → Complete
        2 tw          3 tw (blocked without WS-A)        4 tw (blocked without WS-B)
Total critical path: 9 team-weeks
```

### Critical path shifts

| Shift | Trigger | New critical path | Impact |
|-------|---------|------------------|--------|
| _[DEP-H3 delayed by 2 weeks]_ | _[team-Y unavailable]_ | _[path shifts through WS-D]_ | _[+2 weeks to total]_ |

## Handoff contracts

A handoff contract defines what one team delivers to another and how the
recipient verifies it.

| Handoff ID | From (team / owner) | To (team / owner) | Artifact | Delivery date | Acceptance criteria | Verification |
|-----------|---------------------|-------------------|----------|--------------|--------------------|-------------|
| HND-1 | _[Team A / name]_ | _[Team B / name]_ | _[API spec, schema, library, config]_ | _[date]_ | _[what makes it acceptable]_ | _[how the recipient verifies]_ |

## Cross-repository dependencies

When work spans multiple repositories, each repository boundary is a dependency
interface.

| Repository | Owned by | Depends on (repository) | Interface contract | Version / SHA | Coordinated release? |
|------------|----------|------------------------|--------------------|--------------|---------------------|
| _[repo-a]_ | _[team]_ | _[repo-b]_ | _[API v2, shared schema v3]_ | _[tag or SHA]_ | _[yes — coordinated / no — independent]_ |

## External dependencies

Dependencies on teams, vendors, or services outside the plan's direct control.

| Dependency | Provider | Contact | SLA or commitment | Escalation contact | Contingency if unavailable |
|------------|----------|---------|------------------|-------------------|--------------------------|
| _[third-party API]_ | _[vendor]_ | _[email / Slack]_ | _[uptime SLA]_ | _[contact]_ | _[degrade gracefully, cache fallback]_ |

# Implementation Plan: _[plan name]_

> Based on approved _[spec / requirement / decision record]_,
> approved by _[approver name or role]_ on _[approval date]_.

## 1. Work Breakdown

### Workstreams and vertical slices

Each workstream is a vertical slice — an end-to-end deliverable that provides
independent value. Prefer vertical slices over horizontal layers.

| ID | Workstream | Description | Completion criterion | Owner | Estimated effort |
|----|-----------|-------------|---------------------|-------|-----------------|
| WS-1 | _[name]_ | _[what this delivers, end to end]_ | _[observable condition that means it is done]_ | _[name or role]_ | _[team-weeks]_ |
| WS-2 | _[name]_ | _[...]_ | _[...]_ | _[...]_ | _[...]_ |

### Workstream detail

#### WS-1: _[workstream name]_

- **Scope**: _[what is in and explicitly out of scope]_
- **Dependencies**: _[what this workstream needs from others, with owners]_
- **Acceptance criteria**: _[testable conditions that define done]_
- **Verification**: _[how completion will be verified against the original requirement]_

## 2. Dependency Map

Complete the [dependency record](dependency-record.md) for the full dependency
graph. Summarize key dependencies here.

### Critical path

The critical path is the longest chain of dependent work that determines the
earliest possible completion.

```
_[WS-A] → [WS-B] → [WS-C] = critical path of N team-weeks_
```

### Dependency interfaces

| From | To | What | Contract (API, schema, event) | Hard or soft |
|------|----|------|-------------------------------|-------------|
| _[WS-X]_ | _[WS-Y]_ | _[description]_ | _[the interface artifact]_ | _[hard / soft]_ |

## 3. Sequencing and Parallelism

| Phase | Workstreams (concurrent) | Depends on | Duration | Synchronization gate |
|-------|--------------------------|------------|----------|---------------------|
| Phase 1 | _[WS-1, WS-2 (parallel)]_ | _[none]_ | _[N weeks]_ | _[what must be true to exit phase 1]_ |
| Phase 2 | _[WS-3 (sequential after WS-1)]_ | _[WS-1]_ | _[N weeks]_ | _[...]_ |

## 4. Ownership and Coordination

| Role / Team | Owner | Workstreams owned | Coordination mechanism |
|-------------|-------|-------------------|----------------------|
| _[team name]_ | _[name]_ | _[WS-1, WS-3]_ | _[sync meeting, Slack channel, dashboard]_ |

### Cross-team coordination

- **Integration checkpoints**: _[when cross-team work is verified together]_
- **Escalation path**: _[who to escalate to if a dependency is blocked]_
- **Communication cadence**: _[how often teams sync, what artifact tracks status]_

## 5. Rollout Strategy

### Rollout stages

| Stage | Scope (who gets it) | Duration | Gate (condition to proceed) | Observability signal | Rollback trigger |
|-------|---------------------|----------|-----------------------------|---------------------|-----------------|
| Stage 1 | _[internal / 1% / single region]_ | _[N days]_ | _[e.g., error rate < 0.1%, p95 latency < baseline +10%]_ | _[dashboard, alert]_ | _[specific condition]_ |
| Stage 2 | _[10% / beta users]_ | _[N days]_ | _[...]_ | _[...]_ | _[...]_ |
| Stage N | _[100%]_ | — | — | _[...]_ | — |

### Rollback plan per stage

| Stage | Rollback procedure | Data rollback | Time to rollback | Post-rollback state |
|-------|-------------------|---------------|-----------------|--------------------|
| Stage 1 | _[how to revert]_ | _[yes/no, how]_ | _[minutes]_ | _[what the system looks like after rollback]_ |

### For data migrations

- **Dual-write / backfill strategy**: _[how the transition period works]_
- **Schema compatibility**: _[forward-compatible, backward-compatible, or breaking]_
- **Cutover procedure**: _[step-by-step cutover]_
- **Reconciliation**: _[how to verify old and new data match before cleanup]_

## 6. Verification Traceability

| Requirement (from approved input) | Workstream | Acceptance criterion | Verification method | Verified by |
|-----------------------------------|------------|---------------------|--------------------|-------------|
| _[REQ-1 from spec]_ | _[WS-1]_ | _[testable condition]_ | _[test, demo, review]_ | _[name or role]_ |

## 7. Unresolved Decisions and Risks

| ID | Description | Impact | Owner | Resolution deadline | Status |
|----|-------------|--------|-------|--------------------|--------|
| DEC-1 | _[open decision]_ | _[what depends on it]_ | _[name]_ | _[date]_ | _[open]_ |
| RSK-1 | _[risk]_ | _[severity, likelihood]_ | _[name]_ | _[date]_ | _[open / mitigated / accepted]_ |

## 8. Assumptions

| Assumption | Made by | Date | Valid until | If invalid... |
|------------|---------|------|-------------|---------------|
| _[assumption]_ | _[name]_ | _[date]_ | _[date or event]_ | _[what changes in the plan]_ |

# Risk, Decision, and Verification Record

> Complements the [implementation plan template](implementation-plan-template.md).
> Fill one record per implementation plan.

## Risk register

| ID | Risk description | Severity (1-5) | Likelihood (1-5) | Impact | Mitigation | Owner | Status |
|----|-----------------|---------------|-----------------|--------|-----------|-------|--------|
| RSK-1 | _[what could go wrong]_ | _[1-5]_ | _[1-5]_ | _[blast radius, what depends on this]_ | _[what reduces likelihood or impact]_ | _[name]_ | _[open / mitigated / accepted]_ |

### Risk heatmap notes

- **Severity 4-5**: requires explicit mitigation and escalation path.
- **Likelihood 4-5**: requires a contingency plan with trigger condition.
- **Both severity and likelihood >= 4**: flag for leadership review before plan
  approval.

## Decision log

### Resolved decisions

| ID | Decision | Options considered | Chosen | Rationale | Decided by | Date |
|----|----------|-------------------|--------|-----------|-----------|------|
| DEC-1 | _[what was decided]_ | _[A, B, C]_ | _[B]_ | _[why B over A and C]_ | _[name or role]_ | _[date]_ |

### Unresolved decisions

| ID | Decision needed | Options | Blocked by | Impact of delay | Owner | Deadline | Status |
|----|----------------|---------|-----------|----------------|-------|---------|--------|
| DEC-U1 | _[what must be decided]_ | _[A, B]_ | _[waiting on architecture review]_ | _[blocks WS-3 start]_ | _[name]_ | _[date]_ | _[open / escalated]_ |

## Assumptions register

| ID | Assumption | Basis (evidence or guess) | Valid until | Owner | If invalid... |
|----|-----------|--------------------------|-------------|-------|--------------|
| ASM-1 | _[what we assume to be true]_ | _[data, precedent, or explicit guess]_ | _[date or milestone]_ | _[name]_ | _[what changes]_ |

## Verification checklist

Trace every requirement from the approved input to a verification activity.

| Requirement ID | Requirement summary | Workstream | Acceptance criterion | Verification method | Verifier | Evidence artifact | Status |
|---------------|--------------------|-----------|--------------------|--------------------|---------|-------------------|--------|
| REQ-1 | _[from approved spec]_ | _[WS-1]_ | _[testable condition]_ | _[automated test / manual review / demo / monitoring]_ | _[name or role]_ | _[test report, review sign-off]_ | _[pending / passed / failed]_ |

### Verification methods reference

| Method | When to use | Evidence |
|--------|------------|----------|
| Automated test | Deterministic behavior | Test run output, CI pass |
| Manual review | Subjective quality, UX, docs | Reviewer sign-off |
| Demo / walkthrough | Integrated behavior across teams | Demo recording or notes |
| Production monitoring | Rollout health, SLO compliance | Dashboard screenshot, alert silence |
| Data reconciliation | Migration correctness | Row counts, checksums, diff report |

## Rollback verification

For each rollout stage, verify that rollback works before proceeding.

| Stage | Rollback test performed? | Rollback time (actual) | Data integrity verified? | Signed off by |
|-------|------------------------|----------------------|------------------------|--------------|
| Stage 1 | _[yes / no]_ | _[minutes]_ | _[yes / no]_ | _[name]_ |