---
name: implement-plan
description: Implements a Markdown plan from a file path. Use when you have a feature plan or a production review fix plan and want the agent to execute it carefully, validate the changes, and stay within the documented scope.
---

# Implement Plan

Implement a plan from a Markdown file path.

Supported plan types:
- feature implementation plans
- production review fix plans

## Goals

- Read the provided plan file completely
- Determine whether it is a feature plan or a production review fix plan
- Implement the plan as written
- Stay tightly scoped to the plan
- Ask questions when the plan is ambiguous, incomplete, or conflicts with repository reality
- Run validation before reporting completion
- Do not commit unless the user explicitly asks

## Required Input

The user should provide a file path to the plan.

If the file path is missing, ask for it before doing anything else.

## Before Starting

Before implementation begins, ask the user one question:
- should this be done in a single pass, or step by step?

Do not start editing until the user answers.

## Workflow

### 1) Read and classify the plan

Read the entire plan file.

Determine whether it is primarily:
- a feature plan, or
- a production review fix plan

Extract:
- confirmed scope
- non-goals or scope boundaries
- implementation steps
- affected files or areas
- acceptance criteria
- validation requirements
- blocking open questions

### 2) Validate readiness to implement

Before making changes, verify that the plan is implementable.

Ask follow-up questions first if:
- the plan is ambiguous in a way that affects correctness
- the requested behavior conflicts with current repository structure or conventions
- the plan depends on missing context
- the plan requires a meaningful deviation from what is written

If exact file paths are missing but the intent is clear from repository context, proceed.

Do not silently change the plan’s intent.

### 3) Inspect relevant repository context

Read only the code needed to implement the plan safely.

Use repository context to:
- confirm existing architecture and conventions
- identify the correct implementation points
- align changes with existing patterns
- avoid over-broad edits

### 4) Implement within scope

Implement only what the plan requests.

Rules:
- do not broaden scope unless an important issue or risk makes that necessary
- if an important issue or risk requires a deviation or additional work, stop and ask first
- for production review fix plans, address blocker issues first, then major issues, then any explicitly listed minor items
- prefer minimal, production-safe changes
- follow repository conventions already present in the environment

### 5) Validation

After implementation, always run:
- `npm run lint`
- `npm run typecheck`

Also run targeted tests when relevant tests exist for the changed behavior.

If no targeted tests exist, still run lint and typecheck.

If a validation command is missing or fails because of an unrelated existing issue, report that clearly.

### 6) Completion output

When finished, reply concisely with:
- confirmation that the plan was implemented
- any important remaining risks, if any

Do not include unnecessary detail unless the user asks.

## Execution Mode Guidance

### Single pass

If the user chooses single pass:
- implement the full plan in one cohesive pass when feasible
- ask questions only when required by ambiguity, conflicts, or important risks

### Step by step

If the user chooses step by step:
- complete one logical section at a time
- pause after each major section for confirmation before proceeding
- keep each pause concise and tied to the plan structure

## Scope Rules

Stay within the plan.

Allowed:
- small supporting refactors required to implement the plan safely
- test updates directly required by the plan
- minimal adjacent fixes required to avoid breaking existing behavior

Not allowed without asking first:
- unrelated cleanup
- architectural expansion beyond the plan
- speculative improvements
- updating the plan file itself to change scope or intent

## Handling Risks and Deviations

If you discover an important issue or risk during implementation:
- stop and ask the user before proceeding if it changes scope, design, or required work
- do not update the plan file unless the user asks

If the plan conflicts with repository reality:
- explain the conflict briefly
- ask the user how to proceed

## Quality Bar

A good implementation:
- matches the plan’s intent
- follows repository conventions
- is production-safe
- is validated with lint, typecheck, and relevant tests
- avoids unnecessary scope growth

## Final Reminder

Do not commit changes unless the user explicitly asks for a commit.