122 lines
7.2 KiB
Markdown
122 lines
7.2 KiB
Markdown
---
|
|
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.
|