Feature: skill to autonomously drive feature implementation from work items via sub-agents

[taminomara]

Summary

A skill that, given a set of work items, drives feature implementation end-to-end — offloading development and code review to sub-agents — and only pauses for input on human-in-the-loop (HITL) tasks or on blockers that can't be resolved without changing the planned spec/architecture.

Motivation (current flow)

I use han to implement small-to-medium features on a pet project. After the planning phase, han produces an implementation plan, but the implementation itself is manual: for each work item I hand-invoke tdd and then code-review.

That per-item loop is great for work units with high uncertainty, but it becomes tedious for long features that already have a good specification. Running tdd and code-review also consumes a lot of context, so I have to compact the session every few work items, which costs extra time.

Proposed behavior

A new skill that takes work items and drives implementation, offloading the heavy lifting (development via tdd, review via code-review) to sub-agents, pausing only for:

• HITL tasks, and
• blockers that require my explicit decision because they can't be resolved without changing the planned feature spec, architecture, or similar.

Prior art (I've reproduced this manually)

I've already reproduced the flow by instructing Claude to implement a set of work units while passing development and code review onto sub-agents. Two things were needed to make it reliable:

• I had to explicitly pass the skill names to the sub-agents, otherwise they wouldn't invoke tdd / code-review.
• I had to give explicit per-task model instructions (in the end I just told it to use opus for everything).

Design direction

Where I have a direction, and where I don't:

• How work items are supplied — from plan-work-items. In practice I commit the feature spec and instruct the agents to read it before proceeding.
• Per-work-item completion gate — tests green and code-review reports no findings at severity medium or above. The severity threshold should probably be configurable; pinning down the exact mechanism needs a closer look at the code-review skill.
• How a HITL task is recognized — plan-work-items already classifies each task as AFK or HITL; the skill keys off that.
• How a "blocker requiring an explicit decision" is detected — genuinely open. We'll need to try different approaches and see what works.
• Model-selection policy — to be decided later. Likely an optional skill input with an adaptive default. Worth researching the superpowers skill pack, which does a fairly good job of this.
• Failure handling when a sub-agent's tdd/code-review fails or returns findings — either escalate to me, or run a tdd → code-review → tdd → … loop with a hard cap on the iteration count.

Implementation considerations

• Claude workflows could orchestrate this automatically. Caveat: agents spawned via workflows can't use the Agent tool, so skills that themselves rely on sub-agents (notably code-review) will need additional consideration.

Suspected areas

• New skill placement: likely a coding-time skill under han-coding/skills/ (alongside tdd/code-review), or an orchestration skill bridging planning and coding.
• The tdd and code-review skills (han-coding/skills/) — the per-item steps dispatched to sub-agents.
• The work-item pipeline: plan-work-items / work-items.md and plan-implementation (han-planning/skills/) — the upstream that feeds this skill.
• Sub-agent dispatch and the agent roster (han-core/agents/) — including the per-task model selection and explicit-skill-name concerns above.

Ask

Would you be interested in a PR contributing such a skill?

[taminomara]

Han Feedback — 2026-06-27

Skills used: han-coding:tdd, han-coding:code-review
Agents used: han-core:junior-developer, han-core:adversarial-security-analyst, han-core:test-engineer, han-core:behavioral-analyst, han-core:edge-case-explorer, han-core:structural-analyst (dispatched by han-coding:code-review's panels)
Context: Implementing a 7-item feature (operator-selectable plugin themes + a hashed-asset build pipeline) on a SvelteKit + Postgres app, driven by a hand-built main-loop orchestrator that ran han-coding:tdd then han-coding:code-review per vertical slice through disposable sub-agents — the orchestration we now want to turn into a skill (follow-up to #96).
Outcome: 7 work items in 6 commits, each built test-first, panel-reviewed, fixed where needed, and committed green; verified end-to-end (lint + check + unit + integration + e2e). Review caught 3 real latent bugs (each shipped with a regression test) and 2 plan inconsistencies were escalated to the human for a decision.

---

What worked well

• The two skills are excellent loop stages. tdd reliably produced minimal, test-first changes with a visible RED→GREEN trace in each sub-agent report (e.g. the per-asset-hash Fake-It→Triangulate, the escaping-symlink rejection red, the route-rename "slashed path can't match [file]" red). code-review's specialist panel repeatedly out-performed a single reviewer: it empirically proved a silent-clobber bug (posting a settings form with no theme input backfills '' and overwrites the stored value) while debunking a competing agent's "saves will 400 / break e2e" claim with runtime evidence — that self-reconciliation is the headline value.
• Evidence discipline held under adversarial pressure. The security analyst disproved a path-traversal hypothesis with sink-level evidence (params.file only reaches an equality gate, never the disk read), and verified the realpath containment had no /foo vs /foobar prefix bug — empirically, not by assertion. Base-path correctness was checked against the actual layout server, not assumed.
• Structured, machine-consumed return contracts made the orchestration context-cheap. Forcing each sub-agent to return STATUS / FILES / RED→GREEN / FINAL GATE / ESCALATION (~300 words) let the orchestrator make accept/fix/escalate decisions from the report alone, never reading diffs. Seven items + ~10 review/fix rounds fit in one orchestrator context window only because the heavy work lived in sub-agents.
• The escalation channel surfaced the right things. Sub-agents bubbled up genuine plan inconsistencies instead of guessing: two work items were mutually dependent (a declared font preload can't validate until the build emits it), and a work-item acceptance bullet ("editing only the font changes only its hash, not the stylesheet's") was unsatisfiable under content-addressing. Both reached the human as clean decisions.
• code-review's size-aware calibration + uncommitted-diff (Mode B) handling fit a review-before-commit flow. Warnings were correctly demoted to Suggestions with rationale on trivial slices, and escalated on the security-critical one when run at medium.

---

What didn't work

• Neither skill provides the loop glue — the orchestrator supplied all of it by hand. There is no native "re-review after fix" cycle, no accept threshold ("no findings ≥ Warning"), no iteration cap, no "skip a redundant re-review when the fix was a pure deletion." I encoded every bit of that conducting logic manually. This is exactly the gap a skill should fill, and the single most important takeaway for Feature: skill to autonomously drive feature implementation from work items via sub-agents #96.
• No way to continue a finished sub-agent. SendMessage to a completed agent was unavailable, so fix rounds either fell back to the orchestrator doing surgical edits itself (a JSDoc + log-guard fix) or spawning a fresh agent that had to re-read the file from scratch (the relative-url() fix) — the original implementer's context was lost. A composing skill needs either a continue-agent primitive or one long-lived agent per item.
• Sub-agents over-claimed "all gates green" while real issues remained — verify-before-trust was mandatory. One implementer reported green, but a type error surfaced after a partial revert; two others reported qa:check green while the harness threw a wall of red LSP diagnostics. Every one turned out to be a stale pre-svelte-kit sync view that contradicted a genuinely-green qa:check — but I had to independently re-run qa:check each time to tell stale-diagnostic from real-breakage. On a project with generated types, the loop must run the project's sync/typecheck and trust that, not the raw diagnostics, and not the sub-agent's self-report.
• Scope policing was entirely manual. I ran git status after every item and excluded an untracked doc from every commit; one review agent left a temp test file behind (claimed it cleaned up — it had, but a stale diagnostic implied otherwise); one implementer reached slightly past its slice and cited the wrong decision id. The orchestrator caught these; the skill would need to bake in "verify the changed-file set matches the slice" as a gate.
• code-review's natural output is a long review document. It mostly honored a "concise, machine-consumed verdict" contract, but left to its default it emits a full report — heavy for a per-item gate fired a dozen times. A composing skill should pass the concise-contract by default.

---

Overall

For composing into an orchestration skill, the finding is sharp: han-coding:tdd and han-coding:code-review are strong, evidence-disciplined stages, but they ship no conductor. Roughly 80% of what I did this session was a deterministic loop — for each slice: tdd → review → (while findings ≥ Warning and rounds < 3) fix → re-review → verify green → commit — and 20% was judgment the loop should expose as gates (accept threshold, when to escalate a plan-fork vs decide, fix-myself vs delegate, serial-vs-parallel given a shared working tree, pre-commit verification depth). The skills compose cleanly as stages precisely because their I/O is already structured and their evidence standard is high; what's missing and worth encoding is the loop, the structured-report contract, the verify-before-trust discipline against stale generated-type diagnostics, the scope-diff gate, and a sub-agent-continuation primitive so fix rounds don't lose context. A good orchestration skill is mostly that glue plus a few human-decision gates — the two underlying skills are already the right building blocks.

---

Rating

Dimension	Score
Output accuracy	4/5
Evidence discipline	5/5
Finding signal-to-noise	5/5
Output length vs. decision count	4/5
Turn efficiency	4/5
Loop composability (orchestration fit)	3/5

[mxriverlynn]

hey @taminomara!

this is interesting... i have s few questions, tho. the first one that comes to mind is whether you've tried building a Ralph loop to do this. what you're describing is pretty much exactly what i did with my Ralph loop, pr9k - though i haven't used it in about a month, and it was kind of hallway into a rewrite. the only thing i never resolved was the HITL aspect, which is what the rewrite was trying to do

🤔 and now that I've said this out loud, i guess a Ralph loop might not be what you're wanting, because of the cost of API pricing for Claude?

[taminomara]

Hm, I never experimented with Ralph (or other orchestrators, for that matter), might give it a try. Regarding costs, yeah, API cost is prohibitively high for me; but IIRC, claude -p is counted towards subscription usage, not API. If Ralph can run agents via Claude code executable, this might be feasible.

In any case, it would be nice if han had something for this; even if it was a pointer in documentation saying "use tool X to execute plan".

[mxriverlynn]

i remember something about -p being changed to api pricing, but i don't know if that changed with the fable 5 ban. the Ralph loop i built used -p to do work, tho.

I'm definitely look into adding something like what you're asking. at the very least, a how-to doc. but i also want to dig further into the whole idea you posted here. i should be able to start digging in, this week. but i don't know when I'll have any results