work-items(work): per-issue execution should compose installed skills as a role-separated mini-SDLC (implementer ≠ reviewer ≠ verifier, ephemeral fresh-context agents)

[kyle-sexton]

Category: design/behavioral · Source: operator direction, control-tower checkpoint 2026-07-19

Problem

The work lane's per-issue execution is a single dispatched agent doing everything: understand, implement, test, self-review. That is a small, flattened subset of the SDLC we run manually every day. Two gaps:

1. No skill composition. The dispatched agent does not invoke the installed skill catalog the human uses for the same work. The marketplace ships a full pipeline; the loop uses almost none of it.
2. No role separation. The agent that writes the code is the agent that reviews and tests it. Boris's autonomy guidance and our own review plugins are built on the opposite premise: fresh, unbiased eyes per layer. Same-agent review is biased review.

Direction

Per-issue execution should be an orchestrated mini-SDLC composed from installed skills, with role-separated, ephemeral, fresh-context subagents (nesting is available up to 5 levels — layers don't all have to be concurrently active):

• Baseline lanes for a typical issue: explore (discovery:explore / explore-deep), research when external facts matter (discovery:research / research-deep), plan (planning:architect), adversarial pass (planning:devils-advocate) on non-trivial plans, implement (implementation:implement / implement-dispatch), test (tdd:principles posture + testing:*), verify (toolchain:build, verification:confirm), review (review:* — a DIFFERENT agent than the implementer), re-anchor (re-anchor:*) periodically.
• Complexity-scaled: trivial mechanical fixes skip most layers; large/foggy items escalate (planning:wayfind, planning:brainstorm, planning:prd, prototype:*). The orchestrator sizes the pipeline to the ticket, it does not run every skill every time.
• Separation of duties is the invariant: implementer ≠ reviewer ≠ verifier. Fresh context per role — ephemeral agents, never long-lived (context degradation, "dumb zone"). Return-payload contracts per loops/skills: orchestrator context economy — subagent return-payload contracts + GitHub-externalized state #496 keep the orchestrator lean.
• Deterministic steps get scripts, not reasoning. Anything mechanical (version bump, CHANGELOG insert, PR skeleton, gate checks) is scripted; agents reason only where reasoning is needed.
• Dogfood/empowerment principle: the pipeline should detect and recommend gaps like this itself (self-observation rule already standing in lanes) — record this issue as the pattern to emulate.

Relations

• work-items(work): loop orchestrator implements issues inline instead of dispatching per-issue subagents #451 (dispatch posture — prerequisite), work-items(work): absorb v4 loop-prompt execution rules into the skill #479 (absorption umbrella — this extends the target skill design), loops/skills: orchestrator context economy — subagent return-payload contracts + GitHub-externalized state #496 (context economy — the payload contract these subagents follow), autonomy pipeline: no dedicated security-review pass — automated code review only #509 (security review is one of the separated review lanes), implementation: TDD-by-default fires when consumer CLAUDE.md is silent — no userConfig toggle #406 (TDD-by-default seam).

Triage questions

• Where does the pipeline definition live: work-items:work skill, a new orchestration skill, or per-issue in the T2 plan (triage lane already writes plans — plan could name the lanes required)?
• Complexity heuristic: label-driven (existing priority/complexity labels), plan-driven, or orchestrator judgment?

---

Reference: Boris Cherny, "Steps of AI Adoption" (Google Doc)

[kyle-sexton]

This was generated by AI during triage. · Category: design/behavioral · Priority: priority: high (core work-lane execution model; north-star pipeline quality). Routed needs-human + wayfind: design.

Why needs-human

This redefines the work lane's entire per-issue execution model — from a single agent doing everything to an orchestrated, role-separated mini-SDLC. That is core product/architecture design, not a defaultable fork. The INVARIANT is clear and well-grounded (implementer ≠ reviewer ≠ verifier; ephemeral fresh-context subagents; deterministic steps scripted; complexity-scaled pipeline; return-payload contracts per #496) — but the design decisions the maintainer must own:

1. Where the pipeline definition lives — the work-items:work skill, a NEW orchestration skill, or per-issue in the T2 plan (the triage lane already writes plans; a plan could name the required lanes). This is an architecture-placement decision with cross-skill blast radius.
2. Complexity heuristic — label-driven (existing priority/complexity labels), plan-driven, or orchestrator judgment. Determines how the orchestrator sizes the pipeline per ticket.

Grounded recommendation (for ratification, not a default)

Pipeline definition authored in the T2 plan (triage already produces plans; naming the required lanes there keeps sizing close to the ticket analysis) with the work skill/implement-dispatch executing it; complexity heuristic = plan-driven with orchestrator override. But this is genuinely the maintainer's call given the blast radius.

Relations

Extends #479 (work absorption umbrella) and #451 (dispatch posture — prerequisite). Composes #496 (context-economy return-payload contracts the subagents follow), #509 (security review = one separated review lane), #406 (TDD-by-default seam). The "pipeline self-detects gaps like this" dogfood principle is already the standing self-observation rule — this issue IS the pattern to emulate.

[kyle-sexton]

Gap-hunt input (control tower 7/19): quantified motivation + one guardrail addition. Motivation: single-agent feature PRs measurably accrue 10-15 define-before-use review findings each (#356 ~15, #341 ~14, #343 ~9) — the role-separated pre-PR review lane this issue proposes is what prevents that class. Guardrail addition for the implement/test lanes: immutable test-spec rule — implementer agents may never remove or edit tests to make work pass; spec manifest in JSON (resists inappropriate overwrite better than prose) with per-item pass booleans (anthropic.com/engineering/effective-harnesses-for-long-running-agents). Reviewer-model diversity requirement now specified in #536.

[kyle-sexton]

This was generated by AI (needs-human decision-brief pass).

Decision brief (2-minute read)

Problem. The work lane executes each claimed issue as a single agent that explores, implements, tests, and reviews its own code inline — a flattened SDLC with no role separation and no reuse of the installed skill catalog. The invariant (implementer ≠ reviewer ≠ verifier; ephemeral fresh-context subagents) is settled direction; what's unresolved is where the pipeline is defined and how it's sized per ticket.

Today. plugins/work-items/skills/work/SKILL.md:142 (Step 5) instructs the claiming agent to "Execute the project's development workflow ... explore → plan → implement → test → review → PR" — as prose the one agent follows in its own context. No subagent dispatch, no invocation of the marketplace skills (discovery:*, planning:*, implementation:*, review:*), and the agent that writes the code is the agent that reviews it. #451 confirms this from live loop observation (inline implementation, no per-issue dispatch). So both gaps in the issue are real in code today.

Options. (These resolve the two open triage questions — pipeline placement, and complexity heuristic. The role-separation invariant itself is not in question.)

• RECOMMENDED — Split the two concerns: durable pipeline shape + per-ticket sizing. A single durable artifact (a new work-items orchestration skill, or a pipeline reference doc) owns the stable policy — the lane catalog, the implementer≠reviewer≠verifier invariant, and the complexity tiers. The triage-authored T2 plan names the sized subset of lanes this specific ticket needs; the work skill dispatches that subset. Complexity heuristic = plan-driven with orchestrator override. Rationale: the pipeline shape is stable policy that must evolve in one place and be eval-covered (quality-net: skill changes ship with zero regression detection — 120 evals.json unexecuted, skill-quality:check uninvoked (staged eval/gate/pass^k umbrella) #530), while sizing is genuinely ticket-specific and triage already analyzes the ticket. This refines the triage-comment recommendation (which put the whole pipeline in the T2 plan) — pure plan-authored shape has no single source of truth and drifts across issues. Reversibility: highest. Shape lives in one file you can edit or inline-collapse later; sizing is per-issue data with zero committed machinery. The quantified payoff is already on the issue — the gap-hunt comment shows single-agent PRs accrue 10-15 define-before-use findings each; a role-separated pre-PR review lane is precisely what catches that class before merge.
• Inline the pipeline in the work skill. No new artifact. But work/SKILL.md is already ~12 KB of selection/claim logic; folding orchestration in couples "which item" with "how to build it" and bloats a hot-path skill. Reversibility: medium — extractable later, but the coupling accrues in the interim.
• Whole pipeline authored per-issue in the T2 plan (the triage-comment default). Sizing sits closest to the ticket analysis and needs no new skill. But every plan re-specifies the lane set and invariant from scratch — no SSOT, so the pipeline can't be evolved or eval-gated centrally, and drift is guaranteed. Reversibility: low on consistency (drift is hard to walk back once many plans encode divergent shapes).

Cross-links. Constraining carriers: #440 (decided: outward_write_mode: report-only|write, default report-only) gates the pipeline's terminal outward write — opening the PR; a report-only default means the mini-SDLC runs but stops short of pushing/opening until switched to write. #476 (autopilot merge tier, APPROVED staged) is downstream — the consumer of the review/verify lane's APPROVED verdict, not a constraint on the pipeline's internal design. Related: #451 (dispatch prerequisite — this builds on it), #463 (no in-review state → re-pick risk once the pipeline produces long-running PRs), #530 (eval umbrella — a new orchestration skill needs regression coverage), #509 (security review = one separated review lane), #536 (reviewer-model diversity for the review lane). Builds on the existing triage brief and gap-hunt comment above rather than restating them.