| 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)
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.- Top of
rules/completion-log.md — what just shipped (avoid re-doing
done work; the completed rows are removed from milestones).
- Git/CI status: current branch,
git status, and the latest GitHub
Actions result on main (a red main outranks every queued chunk).
- 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.
STATE.md — the prior run's pointer snapshot.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.
