implementation-planning git:20260928.2632ac1A

Immutable. This exact content never changes and is served at /api/v1/blob/64282e205547df19.

---
name: implementation-planning
description: "Standardize the plan produced before implementation starts and ensure design deliberation is explicit before coding begins. Use when: Before writing code for a ready Work Item."
---

<!-- Generated from packages/cli/src/skills/skills.ts. Run `pnpm agent-plugin:sync`; do not edit directly. -->

# Implementation Planning Skill

## Purpose

Standardize the plan produced before implementation starts and ensure design deliberation is
explicit before coding begins.

## When to use

Before writing code for a ready Work Item.

## Inputs

Assemble context proportionally from the Build Contract's five sources:

1. **Work Item:** outcome, acceptance criteria, constraints, out-of-scope, affected_modules, domains.
2. **Knowledge:** business, product, tech and delivery knowledge relevant to the Work Item's domains.
3. **System Context:** topology, module dependencies, system graph when available.
4. **Repository Context:** existing patterns, file structure, test conventions in affected modules.
5. **Related Work Items:** dependencies (depends_on), completed related Work Items for precedent.

## Context assembly

Assemble proportionally to scope. A single-module bugfix needs the affected module's codebase
and tests. A cross-cutting feature needs topology, multiple modules, and business context.
Do not load everything — load what the scope demands.

## Output

A plan covering the template below, ending with a confirmation gate.

### Output template

```markdown
# Implementation Plan — <WI id>

## Context Summary
<!-- Relevant knowledge, system context, and repository observations assembled for this WI. -->

## Design Deliberation

### Technical Approach
<!-- How this will be implemented. Be specific about patterns, modules, layers involved. -->

### Rationale
<!-- Why this approach. Reference existing patterns, constraints, or WI requirements. -->

### Alternatives Considered
<!-- When the change is non-trivial. May be omitted for trivial/obvious changes with a note. -->

### Trade-offs
<!-- When alternatives exist. Explicitly state what is gained and lost. -->

### ADR Recommendation
<!-- When the decision is architecturally significant: recommend materializing as ADR
     via adr-writing skill. Remove this section if not applicable. -->

## Affected Areas
<!-- Modules, files, surfaces impacted by this change. -->

## Implementation Steps
<!-- Numbered steps with expected files per step. -->

## Validation Plan
<!-- How to verify: test commands, manual steps, AC verification. -->

## Stop Criteria
<!-- When to pause and ask: scope expansion, contradictions, missing knowledge,
     architectural uncertainty. -->

## Confirmation Gate
Do not start coding without explicit human confirmation of this plan.
```

## Rules

- Document Technical Approach and Rationale before listing implementation steps.
- Do not start coding without confirmation.
- Do not expand scope without updating the Work Item.
- Never make commits or push — suggest only.
- Review scope coverage before planning: check that expected result, current/target behavior,
  module coverage, and acceptance criteria are consistent. Flag contradictions (e.g., user-facing
  change with unassessed frontend module).
- When you discover an architecturally significant decision during planning, recommend the
  adr-writing skill and pause.
- When alternatives exist, document them. For trivial or obvious changes, Alternatives and
  Trade-offs may be omitted with a note explaining why.
- Context assembly is proportional: do not load all project knowledge for a small fix.

## Quality checklist

- Pre-implementation scope review is documented.
- Technical Approach is documented with specific patterns and modules.
- Rationale references WI requirements or existing project patterns.
- Alternatives documented when non-trivial, or explicitly noted as not applicable.
- ADR recommendation present when the decision is architecturally significant.
- Context sources consulted are listed in Context Summary.
- Scope and expected files are explicit.
- Risks and validations are listed.
- Validation plan includes how to verify each AC.
- Stop criteria are defined.
- Module coverage aligns with planned changes.
- Confirmation gate is present.