Triage

Follow ../../shared/policy.md. Run dev-skills:project-profile first. Goal: decide what this item needs and hand back next steps to approve. Output is a short read plus options, not a fix.

Rules

• No changes: no code edits, commits, branches, PRs, ticket changes, messages, or writes to any shared service. Reads only (tickets, threads, PRs, code, logs, metrics through read tools).
• Stay shallow. Read enough to classify and to make the drafts correct; do not run a full investigation. When the cause of a problem is unclear, the next step is investigate, not a guess.
• Claims in the item are hypotheses until something you read backs them; mark unverified ones.

1. Understand the item

Run dev-skills:gather-context on the input (the whole thread, linked tickets, PRs, docs). Write 2-3 lines: who asks, what they want, what is the deadline or impact, what is unclear.

2. Classify

Pick the main kind; more than one can apply:

• Question: answerable from code, docs or data now.
• Problem report: something broken or unexpected.
• Change request: new behavior or a fix that is already clear.
• Review request: a PR or doc to read.
• Follow-up on my own work: a PR or ticket of mine that needs action.
• FYI / nothing to do: say so and stop.

3. Look just enough

• Question: find the answer in code or docs, with file:line.
• Problem report: one pass on the code path and, if the project has them, logs or errors in the window. Say if it looks real, already known (search the tracker first) or working as designed.
• Change request: find the code involved and judge size (small, medium, large).
• Review request: read the diff summary and the linked ticket.

4. Propose next steps

A short ranked list. Each step has: what it does in plain words, the skill that would run it, and whether it needs the user's ok. Typical steps:

• investigate when a problem's cause is not proven.
• implement when the change is clear (with the ticket; draft one first if none exists).
• spec when it is large or ambiguous.
• pr-review / pr-follow-up for PRs.
• qa, document, deploy when that is what is left.
• Reply draft to the sender, in the thread's tone and language, answering what you found.
• Ticket draft (title, description, fields per the tracker) when none exists and the work is real.
• Other action (change a PR already open, run a read-only command for the user): spell it out. Do not send, post or create any of them. Ask for confirmation with the list.

Output

Print:

# <item> — <one-line read>
**Asks:** <who wants what, by when>
**Kind:** question | problem | change | review | follow-up | nothing to do
**Found:** <2-4 lines with `file:line` or the source of each fact; unverified claims marked>
**Next steps:**
1. <step> — skill: <name> | draft | action — needs ok: yes/no
2. ...
**Drafts:** <reply and/or ticket, ready to edit>

End with "Reply ok to do these, or tell me which to change." Nothing is sent until then.