implementation-plan

Implementation Plan

Use this skill to produce the plan-first artifact for a later implementation chat. Do not implement code while using this skill unless the user explicitly changes the task.

Purpose

Create a plan that makes each agent loop narrow, boring, and auditable. The output should be good enough that a new chat can implement one slice without needing the original discussion.

Workflow

1. Inspect the codebase enough to understand the requested change and the relevant conventions.
2. Identify the likely implementation model/profile if the user supplied one. If not supplied, default to conservative atomic slices but include batching guidance for stronger models when adjacent slices can safely share one review.
3. Define the smallest useful acceptance slices. If the request has multiple concerns, split it into ordered slices, but do not split purely mechanical setup/docs/runtime work so finely that the plan becomes harder to execute than the change.
4. Group adjacent slices into optional implementation batches when a stronger model could reasonably implement them together under one drift audit and code review. Never group slices that cross an approval-needed gate, mix unrelated risky surfaces, or would make rollback unclear.
5. For each slice, freeze the contract before proposing implementation detail.
6. Identify risky surfaces: auth, billing, permissions, persistence, database schema, migrations, shared types, API contracts, routing, global state, concurrency, generated files, public CLI flags, or release/deployment config.
7. If a slice touches a risky surface, mark it as requiring explicit approval or split it until the risk is isolated.
8. Define validation before coding: tests to add/update, targeted checks to run, and behaviours that must not regress.
9. End with a copyable implementation prompt for the next chat.

Slice Granularity

Choose slice size based on risk, coupling, rollback, and expected implementer strength.

• Frontier model / senior human profile: prefer one to three substantial slices for a coherent feature when the change is internally coupled, low-to-medium risk, and can be reviewed with one clear diff per slice. Use optional batches so the implementer can run multiple atomic contracts together when that improves coherence.
• Standard strong model profile: prefer smaller slices with one main runtime concern per slice and explicit validation after each. Keep batching optional, not required.
• Weaker or less trusted model profile: prefer narrower atomic slices, more checkpoints, and less cross-file autonomy.