---
name: implement
description: Implement scoped work using the local implementation workflow, following task artifact protocol when an implementation task artifact is part of the selected work.
disable-model-invocation: true
---

# implement

Implement scoped work and hand off working code.
This skill defines execution protocol rather than deciding what work the agent is allowed to implement.
When selected work has an implementation task artifact, follow the task artifact lifecycle.
When selected work has no task artifact, implement normally and use the same review, commit, and handoff discipline without creating a tracking artifact.

This skill delegates to other skills by name.
Before satisfying a delegated skill step, explicitly load that skill's `SKILL.md` with `read` unless the harness has already injected that skill's full content into the current context.
Do not satisfy a delegated skill step by imitating its title from memory.

## 1. Establish the selected work

Identify the work to implement from the user's request and current context.
Use an implementation task artifact, issue, spec, direct request, branch context, or other clear source when that is what the agent has selected.
Do not require a task artifact and do not create one just to satisfy this skill.
Old `.claude/tasks` files may be ordinary context, but their lifecycle semantics are not part of this workflow.

When the selected work has an implementation task artifact, re-read it before claiming.
Verify that blockers are satisfied by artifact metadata and that no other session has claimed it.
Claim it before changing code by setting `status: claimed`, `claimed-by` to the current session identifier, and `claimed-at` to the current timestamp.
Use `PI_SESSION_ID` when available.

Done when the selected work is clear, and any implementation task artifact is freshly read and claimed when applicable.

## 2. Verify the execution checkout

Assume the current checkout is the assigned execution checkout.
Do not create, lease, clean up, or switch worktrees.
Report the checkout path and branch when useful for handoff.

Check the working tree before changing code.
Stop on unrelated or ambiguous uncommitted changes.
Continue only when dirty state is clearly already part of the selected work.
Never auto-stash.

For source-changing implementation work that will be committed, work on a non-default branch unless repository context explicitly directs otherwise.
If an appropriate non-default branch is already prepared, continue there.
If you are on the default branch, fast-forward the default branch first and create a task branch.
Stop if the default branch cannot fast-forward cleanly.
Follow repository, user, or orchestrator branch naming conventions.
If no convention is discoverable and you must create a branch, choose a clear short descriptive name and report it.

Check declared implementation blockers where they exist.
Stop when prerequisite implementation work is not reachable from the current base, and report the likely unmerged prerequisite.
Do not automatically branch from, merge, or cherry-pick sibling task work.
Follow an explicit integration-branch or wide-refactor plan only when the selected work names that exception.

Done when the checkout, branch, dirty state, and reachable prerequisites are safe for the selected implementation work.

## 3. Implement the work

Use `test-driven-development` as a strong default when behavior can usefully be specified and tested before implementation.
Load `test-driven-development` before deciding whether it applies.
Skip it only when the work is mechanical, documentation-only, exploratory, or when test-first would not add value.
When skipping it, state the reason before implementation.
Skipping test-driven development is an agent judgment, not an omission.

Build the selected work in the assigned checkout.
Run focused verification while working and run broader verification when the repository or change calls for it.
Treat working code and tests as the implementation artifact.
Do not create a separate process report for test-driven development.
Record only durable outcomes such as tests added or changed, verification run, and deviations worth noting.

Stage created and modified files intentionally.
Do not use broad staging that sweeps unrelated files into the change.

Done when the selected work is implemented as working code and locally verified to the level the change warrants.

## 4. Review the final intended handoff state

Load and run `review` before reporting final handoff or resolving an implementation task artifact.
Choose review timing by judgment.
Review may happen before commit, after commit, or both.
The review must cover the final intended handoff state, including a local uncommitted handoff when no commit is made.
Do not report final handoff until review has run or you have explained why review could not cover that state.

Fix blocking review findings unless the agent or user explicitly accepts them.
When code changes are made in response to review, rerun `review` on the relevant change set.
Record accepted blocking findings in the final handoff or task artifact result when they affect a future reader's decision to trust or continue the work.
Handle non-blocking findings by judgment.
Fix them when cheap or high-value, and otherwise report or record only when useful.

Done when review has covered the final intended handoff state and blocking findings are fixed or explicitly accepted.

## 5. Commit and hand off

Follow the repository's commit and PR conventions.
Discover those conventions from repository instructions or recent history rather than assuming them.
Commit only the selected work.
Use one commit when that is the natural shape, but follow the repository's convention when it expects a different history shape.

Push and open a PR when the repository and selected workflow call for that handoff.
If there is no remote or no supported forge workflow, stop after the local handoff point and report what remains for a human.
Keep PR and handoff text focused on what was built, verification, review disposition, and any deviations that matter.

Done when the implementation has a concrete handoff state: committed locally, pushed, opened as a PR, or stopped with the exact remaining human action reported.

## 6. Record task artifact results when present

When the selected work has an implementation task artifact, re-read it before recording results.
Record durable coordination facts only.
The `status` field is the lifecycle authority.
Acceptance criteria checkboxes may be updated as useful detail with `[x]` for satisfied criteria and `[-]` for deliberately dropped criteria when practical.
Checkbox state is not the source of truth.

Keep Implementation Notes concise.
Capture only what future agents or humans need: deviations, dropped or changed scope, verification, branch, commit, PR, or why the task remains unresolved.
Use judgment for partial or ambiguous outcomes, but keep lifecycle recording honest.
Do not imply completion when the work is not complete.

When resolving an implementation task artifact, set `status: done`.
Put detailed implementation records in the task, commit, PR, and working code.

Done when any implementation task artifact agrees with the implementation's actual lifecycle state.