Implement Plan

Implement an Approved Plan

Use this skill only to implement a defined change. Do not start source-code changes until the plan is clear and the user has authorized implementation.

Non-negotiable rules

1. Implement only a clear plan. Read the plan, relevant source, tests, and repository instructions. Confirm the intended behavior, scope, constraints, affected files, and acceptance criteria. If any material detail is ambiguous, stale, contradictory, or missing, stop before editing and explain the gap with a focused question. Do not fill in requirements from guesswork.
2. Resolve ordinary implementation friction autonomously. Continue through incomplete intermediate states, type errors caused by the current refactor, test failures that can be investigated from repository evidence, and fixture or test-harness changes required by the approved plan. Stop only when resolving the issue requires a material product decision, changes the approved scope, needs unavailable access or secrets, risks data loss, or cannot be resolved from repository evidence. When stopping is necessary, explain the concrete blocker and ask one focused question; do not merely announce a pause.
3. Use an implementation branch by default; honor explicit authorization to work on main. Before any source or test edit, inspect the Git state. Start from a clean worktree and create/switch to a new, clearly named feature branch unless the user explicitly authorizes implementation on main for the current task. That authorization permits source edits and commits directly on main; do not require a branch or ask again. If the worktree is dirty, the current branch is not suitable, or branch creation would discard/conflict with work, stop and ask for guidance.
4. Test thoroughly by default. Add or update focused unit tests unless the user explicitly says not to. Cover required happy paths, meaningful boundaries, failure/empty states, and behavior likely to regress from the change. Follow repository test conventions; do not add redundant or speculative tests merely to increase the count.
5. Prefer the simplest clear implementation. Make the narrowest change that meets the approved plan. Prefer direct, readable code over a new abstraction, layer, configuration option, dependency, state model, or extension point. Introduce one only when a current requirement, two real current use cases, or an established repository convention justifies it. Do not refactor nearby code merely to make the change feel cleaner.

Working mode

During an approved implementation, keep taking the next concrete investigation, edit, or verification step. Do not end a response merely to provide a progress update, announce the next step, or ask for confirmation already supplied. Return to the user only with a completed result or a genuine blocker under rule 2.

Workflow

1. Preflight

• Read the nearest applicable AGENTS.md, contributor guidance, and relevant task/issue/PR material.
• Inspect the current implementation, related tests, existing utilities, and recent relevant changes before designing new code.
• Check git status --short and the current branch.
• Establish the implementation understanding, including non-goals and acceptance criteria. Do this silently unless a material ambiguity requires a focused question.

2. Branch safely

• If currently on main with a clean worktree, create and switch to a descriptive branch (for example, feature/issue-123-short-description) unless the user explicitly authorized implementation on main for this task. When such authorization was given, work on main without requesting branch confirmation.
• If already on an explicitly designated, clean implementation branch, confirm it is appropriate before using it.
• Never use forceful Git operations, overwrite unrelated changes, or alter another branch's history without explicit user authorization.

3. Confirm the test plan

Before writing tests, derive the specific test cases to add or change from the approved plan and repository guidance. Ask the user only when repository guidance explicitly requires test-plan approval or the expected behavior is materially ambiguous.

Implement tests and the smallest clear production change that satisfies the plan. Reuse an existing abstraction when it fits; otherwise prefer local, direct code to creating a new general abstraction for one use case. Keep unrelated cleanup out of the change.