implement-change

Implement the change and match how the repo already builds and tests. Stop when the change is built and verified — reviewing the diff and committing are the user's next move, on separate skills.

Locate

Take the issue from the argument, else the current branch, else the issue under discussion. Resolve the tracker per references/issue-tracker.md and read the issue's title and body alongside the user's context.

Look for an existing workspace per references/issue-workspace.md. Read PLAN.md and CONTEXT.md when present, then inspect the affected code and its callers.

Choose the path

• Saved plan → follow its acceptance criteria and open tasks.
• No saved plan → proceed directly when the intended behavior, affected scope, and verification are clear. State those briefly in the conversation; keep this path free of plan and workspace creation.

If investigation reveals an unresolved product or design decision, explain the decision and pause dependent implementation. Point the user to /plan-implementation, or /update-plan when revising an existing plan. Routine implementation details are yours to resolve.

Build

Before writing code, move the issue to states.in_progress per Moving an issue's state in references/issue-tracker.md. When a plan exists, move its Status to In Progress, work its open tasks top to bottom, and check off each as it lands. Otherwise implement against the issue's requirements.