loop-triage

name	loop-triage
description	Triage this repo's real work queue at the start of a loop run or session: read rules/milestones.md (session checkpoint + next not-started chunk), the top of rules/completion-log.md, git/CI status, and the MCP brain. Produces a concise prioritized findings report and updates STATE.md. Report-only unless a chunk is authorized.
user_invocable	true

Loop Triage — TerranSoulApp

Adapted from starters/minimal-loop-claude/.claude/skills/loop-triage (cobusgreyling/loop-engineering, MIT) to this repo's actual mechanics: the queue is rules/milestones.md, not a CI/issue scan.

Inputs (read in this order)

1. rules/milestones.md — the session checkpoint section first (merge queue state, machine notes), then the next not-started chunk; resume any in-progress chunk before starting a new one.
2. Top of rules/completion-log.md — what just shipped (avoid re-doing done work; the completed rows are removed from milestones).
3. Git/CI status: current branch, git status, and the latest GitHub Actions result on main (a red main outranks every queued chunk).
4. MCP preflight: brain_health on :7421/:7423/:7422, then brain_search / brain_suggest_context with the task topic BEFORE any broad repo search. Show the receipt. If MCP cannot start, record the blocker — do not silently skip.
5. STATE.md — the prior run's pointer snapshot.
6. loop-constraints.md — binding rules (run the loop-constraints skill first if not already loaded).

Output format

Produce a markdown report with these sections, then sync STATE.md:

1. High-Priority (act now)

• One line per item: what + why it outranks the queue (red main, floor regression, user mandate) + suggested loop action + effort estimate.

2. Next chunk (the queue's answer)

• The chunk id/title from rules/milestones.md, its acceptance criteria, and the worktree/branch it should run in (D:/Git/ts-<name>-wt).

3. Watch (monitor, don't act)

• Honest-gap branches, flake watchlist items, dependabot majors.

4. Noise / Ignore

• What was looked at and dismissed (keeps the next triage cheap).

5. State updates

• Facts the next run must remember → write them into STATE.md (Last run timestamp, item status, human overrides).

Rules

• Be brutally concise; signal only — never invent architectural work during triage.
• Only mark High-Priority what a maintainer would want to know today.
• A done chunk is logged in completion-log.md and its row REMOVED from milestones.md — never leave done rows.
• Report-only when no chunk is authorized; the standing continue-order (2026-06-11) authorizes queued chunks but never destructive actions outside the queue.