Stats
Actions
Tags
From anvil
Run the agentic execution loop on a claimed anvil task — fetch the work packet, do the work, submit completion evidence. Use this skill when an agent has just claimed a task and needs to execute it end-to-end without juggling individual CLI commands.
How this skill is triggered — by the user, by Claude, or both
Slash command
/anvil:executeThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Carry a `ready` task all the way to `needs_review`: fetch the work packet, read it in full, do the work, heartbeat the lease, run verification, and submit evidence. Nothing moves to `needs_review` without passing through here.
Carry a ready task all the way to needs_review: fetch the work packet, read it in full, do the work, heartbeat the lease, run verification, and submit evidence. Nothing moves to needs_review without passing through here.
anvil claim TASK_ID has succeeded — claim ID and branch are in hand.Do not use this skill to inspect the queue without taking work — use /anvil:state-ops. Do not use it to make the ship decision on completed tasks — that is /anvil:finish.
An active claim by the current actor on TASK_ID. Verify before proceeding:
anvil list --status claimed
If the task does not appear, claim it first via /anvil:claim. Phase 5 commands used in this skill:
| Command | Phase | Status |
|---|---|---|
anvil packet TASK_ID | Phase 5 | available |
anvil submit TASK_ID | Phase 5 | available |
anvil apply TASK_ID | Phase 5 | available (human-only) |
anvil renew CLAIM_ID | Phase 4 | available |
anvil release CLAIM_ID | Phase 4 | available |
anvil packet TASK_ID
Example:
anvil packet T012
Writes .anvil/packets/T012.md with the full operating context for this task: intent, acceptance criteria, likely files in scope, prior decisions, verification commands, and the output contract. The packet is a derived view regenerated from canonical state — it reflects the current snapshot of state.db, not a cached copy.
Read the packet immediately after fetching it. The acceptance criteria in the packet are the contract that submit validates against. Skipping the packet and working from memory or from show TASK_ID output risks submitting evidence that misses a required item.
To get the JSON form instead (useful when another tool or agent consumes the packet programmatically):
anvil packet T012 --format json
Before touching any file, confirm:
likely_files list in the packet does not overlap with files another active claim owns. If overlap exists, resolve it via /anvil:state-ops before editing.anvil release CLAIM_ID --reason "acceptance criteria ambiguous on T012 item 3"
Ask the user to clarify, update the PRD, re-parse, and re-claim once the criteria are concrete.
This check costs one minute. A wrong interpretation discovered at submit costs the full lease window plus rework.
Do the work directly in this session. Read the work packet, implement against the acceptance criteria, and run the verification commands yourself (Step 5) when the implementation is complete.
Commit incrementally to the claim's branch:
agent/t012-add-retry-backoff
(Or whatever branch prefix the project configured — v1.15.0 made branch_prefix host-project-configurable via .anvil/config.yaml. The default is agent/.)
Incremental commits create a recoverable trail. If the agent session is interrupted, the commits survive on the branch and the work does not need to restart from zero.
Two hooks run automatically during this step — no manual action required:
check-claim.sh (PreToolUse on Edit, Write, NotebookEdit) — warns whenever any active claim exists, prompting a check that the file being modified is within this claim's likely_files scope. The warning is non-blocking: the edit proceeds. Heed the warning; file overlap with another claim creates a merge conflict that is painful to resolve after submit.
record-file-change.sh (PostToolUse on Edit, Write, NotebookEdit) — appends a file_changed event to events.jsonl for every file touched. This populates the files_changed list that submit reads and includes in the Evidence row. Do not maintain a manual list; the hook tracks it.
The default lease is 60 minutes. For sessions longer than 55 minutes, renew before the lease expires:
anvil renew CLAIM_ID
Example:
anvil renew C004
Renewing extends lease_expires_at by another 60 minutes from now and updates last_heartbeat_at. Run this every 5 minutes during active work — set a timer at the start of a long session. A missed heartbeat does not immediately lose the claim; the stale detector fires on the next CLI or MCP operation. Once the lease has expired, the task returns to ready and another agent can claim it mid-work.
Renewed C004: lease extended to 2026-05-25T14:35:00Z
Only the owning actor can renew. To check remaining lease time without renewing:
anvil list --status claimed
The output includes lease_expires_at for each active claim.
Execute the task's verification.commands from the work packet. The capture-evidence.sh hook (PostToolUse Bash) captures stdout, stderr, and exit code from each registered verification command into the claim's pending evidence buffer automatically.
The verification commands are the objective acceptance gate. Submit only when all verification commands exit 0. If a command fails:
Do not submit failing evidence. The Review engine checks evidence_complete against the task's required_evidence list — missing or failed verification commands are flagged and block apply.
For tasks with expensive verification (integration tests, linting over a full codebase), run the cheap unit tests first to catch obvious failures before the slow gate.
anvil submit TASK_ID --commands "pytest -x" --files-changed src/foo.py,src/bar.py
Additional flags:
anvil submit T012 \
--commands "pytest -x,ruff check src/" \
--files-changed src/anvil/claims/manager.py,src/anvil/cli.py \
--output-file /tmp/pytest-out.log \
--pr-url https://github.com/org/repo/pull/42
--commands is a comma-separated list of the verification commands that were run. --files-changed is a comma-separated list of files the agent touched. --output-file attaches a log file to the Evidence row. --pr-url links the branch's PR if one exists.
submit does the following atomically:
Evidence row to state.db with the commands run, files changed, and output excerpt.claim.released event).claimed to needs_review (task.status_changed event).The CLI prints the evidence summary immediately:
Submitted T012: add-retry-backoff
Evidence: E000041
Commands: pytest -x (exit 0), ruff check src/ (exit 0)
Files: 2 changed
Status: needs_review
Review the printed evidence summary before walking away. If a field looks wrong (wrong file list, missing command), inspect with anvil show T012 and coordinate with the human reviewer before they invoke apply.
anvil apply TASK_ID is a human-only step. The task stays in needs_review until the human reviewer invokes it. The /anvil:finish skill drives that decision — surfacing the evidence, picking a disposition (accept, reject, hold, discard), and running apply.
Until apply is called:
anvil list --status needs_review.No action required here. Proceed to the next task in the queue:
anvil next
Verification fails mid-work: do not submit. Fix and re-run. The packet's verification.commands are the contract; submit only when they all exit 0.
Claim went stale mid-work: the task has returned to ready. Re-claim it:
anvil claim T012
The branch's commits are preserved on agent/t012-<slug>. Continue work on the same branch; the new claim ID replaces the expired one. If another agent claimed the task in the window between expiry and re-claim, coordinate via anvil show T012 to check the current holder.
Need to abandon: release the claim so the task returns to the pool:
anvil release CLAIM_ID --reason "blocked on upstream T009 — not merged yet"
The --reason string is stored in the Claim row and logged in events.jsonl. Another agent picks up the task via anvil next.
Packet is stale: if the PRD was revised after the packet was generated, re-fetch:
anvil packet T012
The command overwrites the previous .anvil/packets/T012.md. Re-read the packet before continuing.
anvil show TASK_ID is a summary; the packet is the full operating context. Always read the packet before writing code.apply time. Submitting partial evidence delays the ship decision and may require reopening the task.record-file-change.sh hook tracks this automatically from every Edit, Write, and NotebookEdit call. Pass the hook-tracked list to --files-changed; do not reconstruct it by hand.| Position | Skill |
|---|---|
| Before this skill | /anvil:claim — active claim required before execute starts |
| If scope is ambiguous before step 3 | Return to /anvil:state-ops to inspect conflicts; resolve before editing |
If complexity >= 4 at packet read | Return to /anvil:plan — the task should have been expanded; release claim first |
| After submit | /anvil:finish drives the apply step and ship decision |
If task returns nothing from next after submit | /anvil:state-ops to diagnose queue state |
| Feature | Phase | Status |
|---|---|---|
anvil packet TASK_ID | Phase 5 | available |
anvil submit TASK_ID | Phase 5 | available |
anvil apply TASK_ID | Phase 5 | available (human-only) |
capture-evidence.sh hook (PostToolUse Bash) | Phase 5 | available |
| LLM-assisted self-review on submit | Phase 7 | pending |
MCP generate_work_packet (JSON form via MCP) | Phase 6 | pending |
anvil conflicts (full conflict map) | Phase 5 | available |
Per-file scope check refinement in check-claim.sh | Phase 5 | available — warns per claim's likely_files scope |
npx claudepluginhub fakoli/anvilProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.