Daily Triage Fan-out

How one iteration works

discover → plan → execute → verify → escalate

1. 1
   Discover

   Run a triage pass: read CI failures, new/assigned issues, and recent commits; write each actionable item to the memory store.

2. 2
   Plan

   For each item, decide if it's small and well-specified enough to attempt; defer the rest to the human inbox.

3. 3
   Execute

   Open an isolated worktree per item; a worker sub-agent drafts the fix; a separate reviewer sub-agent checks it against tests and project skills.

4. 4
   Verify

   The reviewer is a different agent from the author and must pass tests + a skills/style check before a PR is opened.

5. 5
   Escalate

   Anything ambiguous, risky, or that failed review lands in the triage inbox for a human, not a PR.

The prompt

The tool-agnostic spec the loop runs each pass — copy it, then wire it to your tool below.

Run a morning triage. Step 1, discover: read failing CI on main, newly opened or assigned issues, and commits since yesterday; write each actionable item to the triage board with status 'queued'. Step 2, filter: keep only items that are small, independent, and well-specified; move the rest to the human inbox with a note. Step 3, for each kept item: open a fresh worktree, have a worker draft a minimal fix, then have a SEPARATE reviewer agent check it against the test suite and our project conventions. If it passes, open a draft PR and set the item to 'pr-open'; if it fails or is ambiguous, move it to the inbox with the reason. Never merge. Update the board so the next run skips finished items.

/schedule weekday mornings: run the triage skill and fan out fixes

You draft the smallest correct fix for one triaged item in an isolated worktree. Make the change, add/adjust a test, run the suite. Output the diff and test result. Do not open the PR.

You review a fix you did NOT write. Run the full test suite and check the diff against project conventions/skills. Approve only if tests pass and conventions hold; otherwise reject with specific reasons.

Memory contract

A board (or markdown file) lists each discovered item with status: queued -> in-progress -> pr-open / inboxed. Read at start, updated as items move, so reruns don't double-process.

Verification & guardrails

How it checks itself. Independent reviewer sub-agent must pass the project's tests and a conventions/skills check; failing items are inboxed with the reason, not opened as PRs.

• Opens draft PRs only — a human approves and merges
• The author and reviewer are separate agents (no self-grading)
• One worktree per item so parallel fixes never collide
• Items it isn't confident about go to the inbox, never straight to a PR

Failure modes

• Reprocesses the same item every run if the memory status isn't updated
• Worktrees collide if items aren't isolated
• Reviewer rubber-stamps if it's the same agent as the author — keep them separate
• Floods you with low-value PRs — tune the 'small and well-specified' filter and cap PRs per run

Variations

• Linear-driven. Use Linear issues as the memory store; the loop pulls 'Triage' status issues and pushes them to 'In Review' when a PR opens.
• Single-repo lite. Drop worktrees and process items serially on throwaway branches if your repo is small and items rarely overlap.

Example run

Discovered 6 items. Filtered to 3 small ones (2 deferred to inbox: needs product decision). Drafted fixes in 3 worktrees; reviewer passed 2, rejected 1 (test regression). Opened 2 draft PRs, inboxed the rejected one with the failing test. Board updated.