Parallel work execution: generalize kweblens ticket-triage into the marketplace, compose with dev-crew

[alexmond]

Parallel work execution: generalize ticket-triage into the marketplace, compose with dev-crew

dev-crew's relay is sequential by design (architect → dev → qa → deployer is a dependency chain), but one run at a time / one dev at a time is an accident of the run-dir convention, not architecture. A review of the fleet found the parallel-execution problem already solved empirically — just in the wrong place to reuse.

What exists today

Skill	Lives	Job	Parallelism
ticket-triage	kweblens-local (.claude/skills/ticket-triage/)	Scheduler — rank the backlog, compute honest width, dispatch role-briefed agents in worktrees, merge, re-triage on every completion	across tickets, one conductor
dev-crew	this marketplace	Executor — one task through a gated phase relay	none (sequential)
ticket-loop	private-skills	Transport — cross-session coordination over an issue tracker	across sessions/repos

kweblens' ticket-triage is battle-tested (its Learnings log covers 2026-08-12 → 2026-08-20) and already answers the hard questions:

• worktree isolation as the default for every dispatched agent (two agents in a shared checkout nearly destroyed each other's work)
• honest parallel width = what is independent, not what is open ("nine open tickets, honest width 2")
• merge-before-dispatch ordering — merging is what moves main and frees files
• one writer per role file per round; seed the role registry before dispatching
• ownership partitions edits to existing files, never blocks committing something new
• verify load-bearing claims before merging; check main's run after merging, not just the PR's
• it already dispatches by role from the shared .claude/roles/ substrate

It is ~90% project-agnostic; the kweblens-specific bits (snapshot script, roadmap path, verify command, protected ports) map onto the same profile pattern dev-crew's scout already uses.

Cuts

1. Extract + generalize ticket-triage into this marketplace as a new plugin (category: workflow — the plural/parallel sibling of implement-issue). Repo specifics move to a per-repo profile in .claude/ticket-triage/; learnings go to the consuming repo (installed plugins are a read-only cache). Ship a portable backlog-snapshot script with a repo-extension hook.
2. dev-crew: a "Parallel work" composition section (triage schedules across tickets → crew executes within a ticket → an issue-tracker loop transports across repos/sessions), and resolve the tech-lead forward-reference in SKILL.md (§Steering names "the tech-lead fan-out"; the role exists only as a candidate row in roles.md). tech-lead stays the intra-ticket fan-out — decompose one big contract → parallel devs → integration review — which neither triage nor loop covers.
3. Spike: can a triage-dispatched agent be a crew conductor? dev-crew declares the orchestrator is the main session; nested subagent-spawning inside a dispatched agent is the unproven link. Fallbacks if not: the main session runs the triage loop and conducts relay-worthy tickets itself (interleaved), or dispatched tickets stay single-role agents.

Notably not needed: run-id awareness in the phase-gate hook. .claude/dev-crew/runs/ is untracked and the hook's glob is CWD-relative, so per-worktree crew runs isolate for free.

[alexmond]

Cuts 1 and 2 are implemented locally (pending push):

• ticket-triage 0.1.0 — new plugin under plugins/ticket-triage/. The kweblens skill generalized: repo specifics (backlog locations, verify command, protected instances, merge policy) move to .claude/ticket-triage/profile.md; run lessons append to .claude/ticket-triage/learnings.md in the consuming repo; portable backlog-snapshot.sh with a snapshot-extra.sh repo extension. All the earned rules kept: honest width, worktree-per-agent, one-writer-per-role-file, merge-then-dispatch, verify-before-merge, check-main-after-merge, ownership-partitions-edits-not-new-files. Skill-linter clean, make validate green, docs page + nav + index wired.
• dev-crew 1.3.0 — new "Parallel work — compose, don't multiplex" section (across tickets via ticket-triage + worktrees; within a ticket via tech-lead; interleaved pipelining as fallback), and the dangling tech-lead reference in Steering now points at the candidate role + New-role protocol.

Still open on this issue:

• Cut 3 spike: can a triage-dispatched agent be a crew conductor (nested subagent spawning), or does relay-worthy work stay with the main session?
• Follow-up (kweblens side): once ticket-triage ships, decide whether kweblens' local .claude/skills/ticket-triage/ becomes a thin wrapper (profile + learnings only) over the installed plugin, keeping its repo-specific learnings where they are.

[alexmond]

Cut 3 spike: answered — a triage-dispatched agent CAN be a crew conductor, with gates machine-enforced.

Two empirical probes (this repo, dev-crew@alexmskills enabled globally):

1. Nested spawning works end to end. A dispatched general-purpose subagent carries the Agent tool, successfully spawned a nested general-purpose agent, and — the load-bearing part — resolved the plugin's namespaced agent type dev-crew:dc-scout from inside the subagent. So the whole dc-* roster is reachable one level down.
2. The phase-gate hook fires inside subagents. With a fixture run dir containing CONTRACT.md carrying status: BLOCKED, a subagent's attempt to spawn dc-dev was denied by the PreToolUse hook with the exact escalation-ladder message. Machine-enforced handoff gates hold for nested conductors, not just the main session — and since the hook resolves the run dir CWD-relative, a conductor dispatched into a ticket's worktree gates against that worktree's own runs.

Consequences:

• ticket-triage may dispatch a relay-worthy ticket as "conduct a dev-crew relay in this worktree" — no separate session required. The 1.3.0 "interleaved conductor" fallback is now truly a fallback.
• One real constraint remains: a nested conductor cannot pause for the user, so a dispatched relay runs in autopilot steering; the roster checkpoint collapses into the triage brief, and the deploy gate's "stop for explicit go-ahead" becomes "return with the irreversible commands staged" — the triage conductor surfaces them to the user, which keeps the hard gate at a human boundary.

Cut 3 is done. Remaining on this issue: the kweblens follow-up (thin-wrapper its local skill over the installed plugin).