vac-optimizer/.agents/skills/tiered-verified-implement/SKILL.md

name, description

name

description

tiered-verified-implement

Implement a spec or ticket in Claude Code by delegating the work to the cheapest Claude model that can handle each piece (Haiku for mechanical edits, Sonnet for normal work), then independently verify the final change on the orchestrator's model. Use when the user asks to implement, build, or fix work and wants it done cheaply, on a cheaper model, or with delegated implementation and a verification pass.

Tiered Verified Implement

Invoke /implement and follow it as the baseline workflow. This skill is its cost-saving, delegated, verified variant: cheap models write the code, the orchestrator's model checks it.

Model tiers

Pick the cheapest tier that can do each piece without guessing:

• haiku: mechanical work with no design decisions — renames, boilerplate, fixture or snapshot updates, wiring an existing pattern into one more place, translations, doc edits.
• sonnet: the default — new logic, bug fixes, tests for real behavior, anything touching several files in one seam.
• Orchestrator (yourself): only for work a cheap agent failed on twice, or that needs a consequential design call the spec leaves open. Ask the user about such calls before delegating rather than letting a cheap agent guess.

When unsure between two tiers, choose the lower one; escalation is cheaper than defaulting high.

Workflow

1. Read the spec or ticket, repository guidance, affected flow, and existing worktree changes. Record the starting commit and task-owned scope; preserve unrelated changes.
2. Split only genuinely independent, bounded work. If the change is small or one seam owns it, use one implementation agent; do not manufacture parallelism. Assign each piece a tier.
3. Spawn each implementation agent with the Agent tool: subagent_type: "general-purpose" and model set to its tier. Never use subagent_type: "fork" for this — forks ignore the model override and run on the expensive orchestrator model. Fresh agents start cold, so the brief carries everything: exact owned files/seam, acceptance criteria, relevant file paths and existing patterns to copy, required checks (targeted tests, typecheck), and an instruction not to overwrite or revert other agents' work. A precise brief is the main cost lever: it stops the cheap agent from re-exploring the repo.
4. Wait for agents, inspect their diffs (not their whole exploration), resolve overlaps minimally, and run the checks required by /implement: targeted tests and typecheck during work, then the full relevant suite once.
5. If an agent's result fails checks or misses the spec, send it back once with the concrete failure (SendMessage keeps its context). If it fails again, escalate one tier: haiku → sonnet → orchestrator.
6. Spawn a fresh, read-only verification agent (subagent_type: "general-purpose") with model set explicitly to the orchestrator's own tier (e.g. opus when you run on Opus). Set it explicitly rather than omitting it, since a configured default subagent model could silently downgrade the verifier. Give it the original request, starting commit, current diff, and test output, but not implementation conclusions. Ask it to check correctness, regressions, specification coverage, and test evidence, and to report findings without changing files.
7. Fix confirmed findings (delegate back to the cheap tier when the fix is mechanical), rerun affected checks, and repeat verification once if fixes were needed. Run /code-review on the current working result (including staged, unstaged, and new files), passing the original spec, starting commit, and task-owned scope. Follow /implement's commit boundary: commit only when requested, otherwise hand off the verified diff.

In the final report, list which tier did each piece and any escalations, so the user can see where the cheap models held up.

Delegation rules

• Keep all agents in the same workspace; assign non-overlapping ownership before they edit.
• Do not delegate secrets, production writes, destructive operations, or changes requiring new user authority.
• If subagents are unavailable, implement directly, run the same checks, and state that delegated implementation and verification were unavailable.