plan-implementation

name	plan-implementation
description	Generate SOW, implementation plans, acceptance criteria, and phased backlogs. Decomposes requirements into actionable deliverables. Triggers: plan project, scope feature, write requirements, create SOW, define acceptance criteria.
argument-hint	Project or feature to plan (e.g., 'plan migration from REST to GraphQL API')
allowed-tools	Read, Write, Grep, Glob

Planning & Implementation

Purpose

This skill provides the procedural knowledge for the PLAN phase of any project or task — from initial scoping through detailed implementation planning. It bridges the gap between "we have an idea" and "the team knows exactly what to build and how."

Core Workflow

Idea/Request
    |
    v
+--------------------------+
| 1. SCOPE (SOW)           |  "What are we building and why?"
|    Problem -> Solution    |  Concise, approvable, stakeholder-facing
|    -> Feasibility -> KPIs |  Template: assets/sow-template.md
+-----------+--------------+
            | Approved?
            v
+--------------------------+
| 2. PLAN (Implementation) |  "How exactly do we build it?"
|    Architecture -> Phases |  Detailed, actionable, team-facing
|    -> Tasks -> Acceptance |  Template: assets/implementation-plan-template.md
+-----------+--------------+
            |
            v
+--------------------------+
| 3. EXECUTE               |  Handed off to execute-task skill
|    Sprint -> Build ->    |  or domain-specific project agents
|    Verify -> Commit      |
+--------------------------+

When to Use Which Template

Situation	Template	Audience
New project proposal / internal pitch	SOW	PM, advisor, client, leadership
Approved project ready for development	Implementation Plan	Engineering team, QA, DevOps
Quick feature addition	Neither — use execute-task skill directly	Self
Complex feature with unknowns	SOW (lightweight) -> Implementation Plan (targeted sections)	Team

Scoping: The SOW Approach

The SOW (Scope of Work) is the concise approval document — it defines what we're building, why, for whom, and what success looks like. It does NOT specify technical implementation details.

SOW Structure (9 sections)

1. Project Information — Title, owner, team
2. Problem Statement — Context, motivation, current pain points with quantified impact
3. Proposed Solution — Concept overview, approach type (automation/AI/hybrid), high-level workflow
4. Key Features & Benefits — Efficiency gains, user impact, strategic business value
5. Potential Challenges — Technical constraints, organizational risks, mitigations
6. Estimated Timeline & Budget — Major phases with rough durations, resource estimates
7. KPIs — Technical performance, usability, business value, data integrity, innovation
8. Visualizations — Before/after workflow diagrams, process flows
9. Architecture Logic — Software/data pipeline overview, integration points, output conditions

Key principle: The SOW should be approachable by non-technical stakeholders while containing enough technical signal for engineers to estimate feasibility.

Full template: assets/sow-template.md

Implementation Planning

Once the SOW is approved, the implementation plan provides the actionable technical blueprint. This is the hybrid PRD+SRD — combining product requirements with system requirements into a single working document.

Plan Structure

1. Quick-Start Guide — Elevator pitch, approach summary, phase overview, validation checkpoints
2. Project Overview — Executive summary, problem analysis, stakeholder map
3. Requirements — Functional (user stories + acceptance criteria), non-functional (performance, security, accessibility)
4. System Architecture — Component design, data model, API contracts, technology stack decisions (ADRs)
5. Implementation Phases — Sprint/phase breakdown with per-phase metadata convention (see below) and specific deliverables and gate criteria
6. Testing Strategy — Unit, integration, E2E, performance, security, UAT approach
7. Deployment Plan — Environment strategy, CI/CD, rollback, monitoring
8. Operational Handoff — Documentation, training, maintenance procedures

Per-Phase Metadata Convention

Each phase under Section 5 carries a structured 5-field metadata header before its task table. These fields make phase-level execution decisions explicit and auditable:

Field	Values	Purpose
Priority	HIGH / MEDIUM / LOW (with one-line rationale)	Conveys gating relationship to other phases — what fails if this slips?
Session budget	N sessions (or N hours for non-CC work)	Time accounting for capacity planning + post-hoc velocity calibration
Parallelizable with	none / <other phase> (with reason)	Surfaces sequencing constraints — what can run concurrently vs. must be ordered
Depends on	<prior phase> complete / <external prerequisite>	Phase-level dependency graph — feeds into KG depends_on edges per Wave 8 schema
Intervention type	IN-THE-LOOP (active co-decision per batch) / ON-THE-LOOP (review + intervene on exceptions) / DIRECTED (set policy, not each action)	EU AI Act / NIST conventions for human-AI collaboration mode at the phase level

Format (place between phase header and tier scope / tasks table):

### Phase N — [Title] ([N] sessions)

**Priority**: [HIGH | MEDIUM | LOW] ([rationale])
**Session budget**: [N sessions]
**Parallelizable with**: [none | <phase>] ([reason])
**Depends on**: [<prerequisite>]
**Intervention type**: [IN-THE-LOOP | ON-THE-LOOP | DIRECTED]

**Tasks**:

| Task | Deliverable | Acceptance |
|...

Why these 5 fields specifically:

• Priority synthesizes from prioritization-frameworks.md reference (RICE / MoSCoW / Kano comparative); kept as a 3-tier classification at the phase level for skim-readability — finer-grained scoring lives at the task level.
• Session budget integrates the bootstrap-cost.sh instrumentation discipline (LL-29) into phase planning — sessions are the natural unit of CC work; estimating in sessions surfaces compaction/handoff considerations directly.
• Parallelizable with + Depends on together form the dependency graph that feeds Wave 8's KG schema (depends_on edges) — phases become first-class nodes in the eventual graph, with parallelization possibilities visible at planning time.
• Intervention type integrates the human-AI collaboration model (EU AI Act / NIST IN-THE-LOOP / ON-THE-LOOP / DIRECTED taxonomy) into per-phase execution — sets explicit expectations for human review cadence per phase rather than as a global default.

Reference example: notes/impl-plan-kb-to-kg-2026-04-28-v2.md §4 (canonical realization across 7 phases of Wave 8 work).

Phase Gate Criteria

Every phase transition requires explicit criteria before proceeding:

Transition	Gate
Discovery -> Strategy	Problem validated, feasibility confirmed
Strategy -> Architecture	Requirements approved, KPIs defined, risks accepted
Architecture -> Implementation	Architecture reviewed, designs approved, specs complete
Implementation -> Validation	Feature-complete, code reviewed, CI green
Validation -> Deployment	Critical bugs resolved, UAT signed off, performance acceptable
Deployment -> Operations	Deployed, monitoring active, rollback tested

Full template: assets/implementation-plan-template.md

Requirements Decomposition

From Vision to User Stories

Product Vision (SOW Section 3)
    |
    +-- Epic 1: [Major capability]
    |   +-- Feature 1.1: [Specific feature]
    |   |   +-- User Story 1.1.1: "As a [role], I want [action] so that [benefit]"
    |   |   |   +-- Acceptance Criteria: Given [context], When [action], Then [result]
    |   |   +-- User Story 1.1.2: ...
    |   +-- Feature 1.2: ...
    +-- Epic 2: ...

Prioritization Frameworks

Framework	Best For	Method
RICE	Feature backlogs	(Reach x Impact x Confidence) / Effort
MoSCoW	MVP scoping	Must / Should / Could / Won't
Kano	UX prioritization	Basic / Performance / Delight classification
Value vs. Effort	Quick sprint planning	2x2 matrix: high-value + low-effort first

Acceptance Criteria Standards

Every story/task must have acceptance criteria that are:

• Specific — "Renders within 200ms" not "fast"
• Testable — Can be verified by running a command or inspecting output
• Independent — Each criterion verifiable on its own
• Complete — Cover happy path, edge cases, and error conditions

AI-Integrated Project Planning

When the project involves AI/ML components, add these considerations:

• AI Threat Modeling (Phase 0): Assess agentic failure modes before architecture
• Human-AI Collaboration Model: What AI decides vs. what humans approve
• Responsible AI Integration: Bias monitoring, fairness validation, transparency
• AI-Specific Testing: Hallucination detection, drift monitoring, adversarial evaluation
• Wrap, Don't Rewrite: Expose existing tools via MCP; preserve working automation

Integration with Other Extensions

• Orchestrator agent: Invokes this skill when decomposing complex tasks
• execute-task skill: F011 Option A delegation — execute-task Phase 1 (PLAN) delegates to this skill when work spans 3+ phases, plan body would exceed ~80 lines, user explicitly requests SOW/implementation plan, or a stakeholder review gate is in scope. After this skill produces the SOW + Implementation Plan artifacts, control returns to execute-task Phase 2 (REVIEW). For lightweight single-phase work, execute-task authors the plan inline without delegating here.
• assessing-quality skill: Provides quality framework referenced in Phase 6 (testing strategy)
• designing-workflows skill: Produces the workflow diagrams referenced in SOW Section 8
• verifier agent: Validates deliverables against acceptance criteria from this plan

Full-Stack Sprint Coordination

When planning full-stack implementations, consider the dependency graph between layers:

Pattern	When to Use	Approach
API-first (backend leads ~1 sprint)	Data-heavy apps, complex business logic	Backend builds endpoints -> frontend integrates with real APIs
Design-first (frontend leads with mocks)	UX-critical apps, design-driven products	Frontend builds UI with mock data -> backend implements to match
Contract-first (parallel)	Clear API contracts, experienced teams	Both develop against shared API spec simultaneously

Let the project's actual architecture determine which pattern fits — don't default to one approach for all projects.

Team Formation Advisory (Knowledge Anchor)

When the plan involves team composition or role allocation, consult knowledge/reference/INDEX.md to access the a-team-database — 22 roles with CC extension mapping (cc_mapping field) and scaling tiers (solo / small / medium / enterprise).

Use as a conceptual menu, NOT a checklist. Filter by:

• Project's team size (solo vs medium vs enterprise)
• Active phase(s) from the product-design-cycle (which roles are load-bearing in this phase)
• Pain points surfaced during planning (which roles directly address them)

Suggest only the roles that add value for the specific project. For each suggested role, map to its recommended CC extension type (agent vs skill vs command) per the database's cc_mapping field. This grounds team-shape proposals in a curated reference rather than ad-hoc improvisation.

Mirrors the Team Formation Advisory pattern in skills/scaffold-project/assets/mode-integrate.md.

References

• assets/sow-template.md — Full SOW template
• assets/implementation-plan-template.md — Full hybrid PRD+SRD template
• knowledge/reference/product-design-cycle.md — Universal 7-phase lifecycle (conceptual framework, not prescriptive)
• knowledge/reference/a-team-database.yaml — 22-role team formation reference (Team Formation Advisory pattern)
• knowledge/reference/requirements-doc-guide.md — MRD/PRD/SRD deep dive for hybrid plan structure