name	implementation-plan
description	Apply when planning before writing code, defining scope, or producing an implementation plan for a feature or change.
license	MIT
version	1.0.0
tokens_target	1300
triggers	implementation plan, planning before code, scope definition
loads_after
supersedes

Sub-Skill: Implementation Plan

Purpose: Ensure every non-trivial change is planned before execution, reducing rework, missed files, and undetected regressions.

Rules

List affected files first. Always list all files that will be modified before beginning implementation. Reference: ERR-2026-029
Define scope boundaries. Before writing code, explicitly state what is in scope and what is out of scope to prevent scope creep.
Map dependencies. Always identify which modules, services, or packages depend on the code being changed before touching it.

Order migrations before rollouts. Always sequence database migrations before application deployments in the plan; never assume they run together.
Write the rollback story. Before starting, define the rollback procedure: which commands revert the change and restore the previous state.
Identify stop-the-line criteria. Always define explicit conditions that would cause you to halt implementation and reassess (e.g., test failure rate, latency spike).

Include a test plan. Always specify which tests will be added or modified and what scenarios they cover before writing implementation code.
Assess risk per change. For each file in the touch list, note the risk level (low/medium/high) based on blast radius and test coverage.

Estimate time per step. Always provide a rough time estimate for each implementation step so stakeholders can track progress.
Define done explicitly. Always write a definition of done (DoD) that includes passing tests, updated docs, and any required approvals before starting.
Communicate blockers immediately. After discovering a blocker during implementation, surface it immediately rather than working around it silently.
Verify the plan against the codebase. Before executing, confirm each file in the touch list exists and the planned change is compatible with its current state.