# Triage — drain this project's inbox items into the right place

You are running inside one project repo. Your job is to take the items in the cross-project
inbox that belong to *this* repo and route each one to where it actually lives — then clear
it from the inbox. This is the deliberate, with-context counterpart to `/capture`: capture
is dumb and uniform, triage is where the judgment happens. Routing decisions are the user's
call — propose, don't impose.

The inbox is `~/Projects/standards/INBOX.md`. This repo is identified by its current working
directory's folder name (and `AGENTS.md`/`README.md` if you need to confirm the name).

## Procedure

1. **Gather.** Read `~/Projects/standards/INBOX.md`. Select the unchecked items whose
   `(project)` tag matches this repo's folder name. Also surface any `(?)` items and ask the
   user whether each belongs to this repo — don't assume. **Never select `(new)` or
   `(new:…)` items** — those are proposed new repos, not work for this one; if any exist,
   note them in your report as awaiting the new-repo bootstrap, but leave them in the inbox.
   If there are no matching items, say so and stop.
2. **Orient.** Read this repo's `AGENTS.md` (especially `## Current state`) and `ROADMAP.md`
   (if present) so your routing proposals fit what's already there and you can spot
   duplicates of items already tracked.
3. **Propose a routing for each item.** Present them as a short list, each with a proposed
   destination and a one-line reason. The destinations:
   - **`## Current state` in AGENTS.md** — near-term, act-on-it-now items (high priority,
     active work, a bug to fix this session).
   - **`ROADMAP.md`** — longer-term backlog (features, ideas, deferred work). Create
     `ROADMAP.md` if it doesn't exist and there's anything to put there.
   - **A `docs/guides/<topic>.md`** (or this repo's equivalent guide location) — if the
     item is durable subsystem guidance rather than a task.
   - **Escalate to the standards repo** — if the item is really a cross-repo idea (a new
     command/agent/standard), it belongs in the standards `ROADMAP.md` or stays in the
     inbox tagged `(standards)`, not in this project. Flag these; don't force them into the
     project.
   - **Discard** — already done, duplicate, or no longer wanted. Say why.
   Let the captured priority (`Pn`) inform the destination but use judgment — a `P1` bug
   goes to Current state, a `P3` idea to ROADMAP.
4. **Get approval.** Wait for the user to confirm or adjust the routing. Do not edit any
   file before they approve — these are their durable project files.
5. **Apply.** Make the approved edits to this repo's files (keep `## Current state` lean —
   present tense, ~15 lines max per the close-out convention; if it overflows, push older
   items to ROADMAP). Then remove the triaged items from `~/Projects/standards/INBOX.md` — delete the
   lines outright (the git history is the record); leave untriaged and other-repo items
   untouched.
6. **Commit.** Two repos changed — present the proposed commit message(s) for both and
   **wait for the user to confirm before committing or pushing anything** (the same gate as
   step 4): this project's AGENTS.md/ROADMAP changes, and the standards repo's INBOX.md
   (`git -C ~/Projects/standards …`). Follow `how-i-work.md` for messages and the
   no-AI-attribution rule.
7. **Report** what landed where, what was discarded, and any items escalated to the
   standards repo that the user still needs to handle there.

## The portable inbox-check line

So pending items surface automatically at the *start* of a session (not only when the user
remembers to run `/triage`), every project repo's `AGENTS.md` should carry this line — it's
vendor-neutral, so any harness that reads AGENTS.md honors it:

> **Inbox check:** At session start, if `~/Projects/standards/INBOX.md` exists, scan it for
> items tagged `(this-repo)` and surface them before proposing next steps; triage with
> `/triage`.

If this repo's AGENTS.md lacks that line, offer to add it as part of the triage.

## Rules

- Never invent items or routings. If an item is ambiguous, ask.
- Never edit a project file before the user approves the routing.
- If you cannot read `~/Projects/standards/INBOX.md`, stop and report precisely that — do
  not guess what was captured.