Imported from leonletto/thrum-pro (cursor-plugin/skills/coordinator-running-autonomous-feature-development/SKILL.md). Install upstream with npx skills add leonletto/thrum-pro --skill coordinator-running-autonomous-feature-development. Copyright stays with the author.

Coordinator: Running Autonomous Feature Development

Overview

When idle and a qualifying backlog item exists, the coordinator drives the whole front half: scan, select, stand up a brainstormer, drive the design Q&A on the questions it owns, surface only the genuine judgment calls (batched), dual-review to a clean plan, and present the human a finished plan for go/no-go. On approval, execution routes through a standing orchestrator.

This skill sequences existing coordinator skills and adds two guardrails; it cites each sibling at its handoff and never restates their mechanics.

Worked example: the catch-up / anti-entropy tier — a ~12-task epic taken scan-to-finished-plan this way.

When to Use

Trigger: you are the coordinator, you have idle capacity (or just hit a post-merge lull), and a real qualifying backlog item exists.

The trigger is two conditions, not one: (a qualifying item exists) AND (idle capacity exists). It is not "invent work to stay busy." Manufactured busywork is the failure this skill prevents — see the guardrail below.

When NOT to use:

• No qualifying backlog item exists → stay idle. Do not manufacture work.
• The item is cross-cutting / schema / release-gating / public-facing / touches the threat model or branch policy → surface to the human first (it fails selection — see below).
• You are mid-dispatch or running the back half (execution, code review, merge) → those are owned by the sibling skills, not this one.

The loop (the winning pattern)

Project-setup (step 5) is researcher-owned — the researcher runs thrum:project-setup in their own worktree; it is not coordinator-owned.

Scope ends at step 7. Everything past the handoff (orchestrator dispatch, epic execution, code review, merge) is owned by the back-half siblings.

Keep the brainstormer warm until merge. At the handoff the brainstormer is not dismissed — it stays warm as a review tie-breaker through implementation until merge, then is torn down. It holds the design rationale and adjudicates review disputes the implementer/reviewer can't resolve.

Backlog selection — pull autonomously only when ALL hold

1. Bounded blast radius — single subsystem/package; not a cross-cutting protocol or schema change.
2. Reversible — no irreversible data migration; no public-API or release commitment.
3. Narrow design space — direction already implied by prior decisions; you have the domain depth to drive the Q&A.
4. Sized — roughly one epic, ~one orchestrator-driven cohort (one orchestrator running one epic wave without spawning a second). Soft guidance, not a task-count gate.
5. No manufactured urgency — not release-gating.
6. Traceable source — a bd backlog item, a deferred follow-up, or a project-state "queued" note.

Fail any → surface to the human before pulling. Hard escalation triggers: schema migration, cross-version/release-line change, public-facing/website, security/threat-model shift, branch-policy, or anything the human flagged as theirs.

Trigger source matters. The 6 criteria gate coordinator-initiated idle scans — those require all 6. An explicit human-directed pull bypasses criteria 1–6 (the human already made the selection call), but you still run the Q&A-vs-escalate logic and the mandatory plan-approval gate. The human choosing the item does not waive the finished-plan go/no-go.

Guardrail 1 — proactive backlog, not idle-and-wait

Default posture when idle: scan for qualifying backlog and pull it. Do not sit waiting for instructions.

Never write invented discipline into a restart snapshot. Self-imposed rules survive restarts and propagate silently — an undocumented invented rule can outlive its author and later be enforced as if it were the human's mandate.

Guardrail 2 — ALWAYS route through a standing orchestrator

NEVER stand up a dedicated implementer yourself. ALWAYS route implementation through a standing orchestrator.

The reason, in one line: orchestrators own the implementer lifecycle and the --model sonnet pin; standing one up yourself risks the implementer inheriting opus. Your lane is dispatch-decision + gate + merge. Full dispatch mechanics live in coordinator-dispatching-work.

Recovery: if an implementer was ever stood up directly, tear it down before handing to the orchestrator. Do not let the orchestrator adopt a coordinator-spawned implementer — it may carry the wrong model.

Coordinator-run Q&A vs escalate

Drive far, surface little.

Answer yourself when the question is a technical/design detail inside a subsystem you understand, has a clear best answer given prior decisions, and is reversible / low-stakes.

Escalate to the human when the answer changes user-visible behavior/shape, touches philosophy/policy (threat model, release strategy, branch policy), creates an irreversible commitment, or has multiple defensible options with material product tradeoffs.

Default behavior: drive as far as possible, then batch the genuine judgment calls into ONE surfacing — don't interrupt per-question.

Mid-brainstorm fork: if a genuinely contentious design fork surfaces mid-brainstorm on an item that already passed selection, escalate immediately (batch to the human) — do not retroactively un-select the item. Also surface to the human that the selection criteria failed to catch the fork, so the criteria can be tightened.

Runway management

A refinement of the Q&A rule — how to surface questions without burning your own context.

• Default — batch-surface. The brainstormer surfaces its full question agenda; you answer in one batch, not per-question round-trips. This is the runway-efficient default.
• Per-question inline is the variant for short brainstorms (few questions; you are the domain driver).
• Escalate to human-joins-the-pane when your context crosses the ~50% tier or the human signals they want to drive — then you step out.

Human gate

Mandatory human-in-the-loop:

1. Plan approval before implementation dispatch — go/no-go on the finished, dual-reviewed plan (step 6).
2. Backlog-item selection when the item fails the selection criteria.
3. The batched judgment calls from the Q&A rule, as needed.

Optional / informational: progress status, final merge report (the merge report itself is produced by coordinator-managing-state-and-lifecycle).

Do not over-gate. Once the human approves the plan, execute and report — do not re-ask.

Red Flags — STOP

• "I'll just stand up the implementer myself." → Route through a standing orchestrator.
• "I lack authorization to pull this, so I'll wait." → Scan-and-pull when all 6 criteria hold.
• "I'll note in my snapshot not to manufacture work." → Never write invented discipline into a snapshot.
• "The human picked this item, so I can skip the plan-approval gate." → Human-directed pull still hits the mandatory go/no-go.
• "This fork is contentious, so the item was a bad pick — un-select it." → Escalate the fork; keep the item in flight.
• "It's a schema/release/public change but small, I'll just pull it." → Fails selection. Surface first.
• "The plan is approved, I can dismiss the brainstormer now." → Keep it warm as a review tie-breaker until merge.

Common Mistakes

• Standing up the implementer directly — the single most-corrected misstep. Always the orchestrator.
• Surfacing every question instead of driving and batching — burns the human's attention; defeats the pattern.
• Re-gating approved work — re-asking after go/no-go. Execute and report.
• Dismissing the brainstormer at handoff — keep it warm as a tie-breaker until merge.
• Restating sibling mechanics here — cite the sibling skill; this skill is the spine, not a copy.