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.