| name | boring-triage |
| description | Use for /triage in boring-ui: refresh GitHub state, classify issues/PRs, choose the first unmet gate, route grill/plan/implement/proof/merge, and decide fast-track versus owner-review routing. |
Boring Triage
Triage answers: what is the first unmet gate, then does one next action.
Sweep
- Refresh issue/PR body, comments, current labels, CI, reviews, proof comment,
and head SHA.
- Read newest Julien/owner instruction before touching the item.
- Read enough code/docs to know risk and proof path.
- Pick queued or stale work, then stop at the first unmet gate.
- Record labels, gate, proof, reviewed SHA, and next action.
Labels
| Kind | Rule | Values |
|---|
state:* | exactly one | queued, blocked, active, ready, done |
phase:* | exactly one | triage, grill, plan, implement, review, merge |
track:* | exactly one | owner by default, fast only after risk gate |
| source | optional | source:feedback only |
- No taxonomy labels:
bug, ui, accessibility, package:*, plugin:*,
gate:*.
- Put details in body/card.
Gate Table
| Situation | Labels | Gate |
|---|
| weak issue body or unsafe intake | state:queued phase:triage | intake |
| queued issue is ready to classify | state:queued phase:triage | triage |
| duplicate, invalid, out of scope | state:done | none |
| unclear | state:blocked phase:grill | clarity |
| risk classification | keep track:owner; upgrade to track:fast only if eligible | risk |
| runtime exposure is not controlled | keep current state/phase | flag |
| needs design or sequencing | state:active phase:plan | plan |
| clear and no PR | state:active phase:implement | implementation |
| PR lacks current review, has unresolved comments, or accepted findings remain | state:active phase:review | implementation |
| final proof comment, tests, CI, or demo proof missing | state:active phase:review | proof |
| all gates pass | state:ready phase:merge | merge |
Gate Actions
| Gate | Action |
|---|
intake | repair the issue using docs/kanzen/procedures/well-documented-issue.md |
clarity | use boring-loop-grill: grill-me plus ask-user; stay state:blocked phase:grill |
triage | classify risk, plan need, implementation state, proof, and merge readiness |
risk | keep track:owner; upgrade to track:fast only when all fast-track rules pass |
flag | require not-needed, a safe feature flag, or an abstraction path before code proceeds |
plan | use boring-loop-plan: smallest useful plan; plan file plus thermo review for risky or multi-PR work |
implementation | use boring-loop-implement: one accountable lane for one issue/PR |
proof | follow docs/kanzen/procedures/proof-of-work.md; PR body proof is not a substitute for the final proof comment |
merge | fast-track merge or docs/kanzen/procedures/owner-review-card.md |
Current review means a review artifact for the current head SHA: a GitHub
review, a PR comment/body section that names the reviewed SHA, or a recorded
coding-autoreview/thermo result. Stale reviews and unresolved accepted
findings fail the implementation gate.
Current proof means a final issue/PR comment for the current head SHA. PR body
proof is helpful context, but it does not pass the proof gate by itself. In a
read-only or dry-run sweep, report the exact comment/label/merge action that
would happen and leave the gate unchanged.
Fast Track
Use track:fast only for trusted-author low-risk work with small blast radius,
obvious acceptance criteria, clean review, green CI, and current proof.
Use track:owner for auth, billing, permissions, privacy, secrets, migrations,
public API, releases, broad refactors, destructive/deletion-heavy changes,
unclear requirements, or untrusted authors.
Auto-merge only when labels include state:ready phase:merge track:fast, the
author/agent is trusted, the PR is non-draft on a branch owned by one lane or
explicitly trusted owner/agent, CI/tests and proof are current, no restricted
area is touched, and a proof comment is posted. Otherwise keep track:owner
and prepare a short owner review brief.
Worker Rule
One lane means one accountable Codex/Kanzen thread/run, one branch/worktree, one
GitHub item. Use docs/kanzen/procedures/branch-worktree.md for mechanics. Helpers
may assist, but they do not own labels, merge decisions, owner questions, or
additional lanes. Stop for missing owner input, missing access, destructive
actions, release/publish work, or merge without policy permission.
Card
Return:
URL:
What:
Current labels:
Recommended labels:
Gate:
Track:
Proof:
Next action:
Why:
End with exact next action: /loop-grill, /loop-plan, /loop-implement,
proof, fast-track merge, or owner review.