Intake

Work the incoming queue. Each item moves through a small set of states until it is either actionable by someone who did not write it, or closed with a reason.

A pull request is an issue with attached code. Same states, same moves, with the deltas noted below. Resolving a bare #42 means checking both.

Adapted from triage in mattpocock/skills (MIT), cut down to the states this repo can actually represent and retargeted at gh and bd.

When To Use

• Open issues or PRs have accumulated and nobody knows which are real.
• A new report arrives and needs sorting before anyone works it.
• An issue has been sitting because it is not clear what it is asking for.
• Before planning, to establish what is actually in the queue.

When Not To Use

• To do the work an item describes. Triage decides what happens to it, not how.
• For local, private notes. That is skill-issues and .octo/ISSUES.md.
• To review a PR's code quality. That is skill-code-review or skill-staged-review; intake decides whether the PR should be reviewed at all.

Inputs

An issue or PR reference, or nothing — with nothing, take the queue in order. gh issue list and gh pr list for the public surface; bd ready and bd blocked for tracked work.

Workflow

1. Categorise

What kind of thing is it: a bug, an enhancement, a question, or noise. For a PR, also: does it correspond to an existing issue, or arrive unannounced?

Do not skip this because the title looks obvious. Titles are written by people who already know what they meant.

2. Verify

The step that earns the whole skill. For a bug: reproduce it, or establish that you cannot. For a PR: check the claim it makes is the change it contains.

An unverified bug report is a hypothesis. Filing it as fact wastes whoever picks it up. If reproduction needs something you do not have — credentials, a dataset, a platform — that is needs-info, not verified.

3. Assign a state

• needs-triage — arrived, not yet sorted. The entry state.
• needs-info — blocked on the reporter. Say exactly what is missing; "more detail" is not a request anyone can act on.
• verified — reproduced or confirmed, ready to be worked.
• needs-decision — real, but what to do is a judgement call the maintainer has not made. Do not resolve these by inference. Escalate, or run skill-pressure-test with the maintainer.
• closed — not a bug, out of scope, duplicate, or fixed. Always with a reason, and for out-of-scope, why.

4. Write the brief

For anything reaching verified, write what someone picking it up needs and would otherwise have to rediscover: where the relevant code is, what you already ruled out, and how to tell when it is fixed. This is the difference between an item that gets worked and one that gets re-triaged.

For a PR, add: whether it has tests, whether CI is green, and whether it conflicts with anything in flight.

5. Record it

For public comment text, stream the completed note through the outbound gate:

printf '%s\n' "$TRIAGE_NOTE" | \
  "${CLAUDE_PLUGIN_ROOT:-${HOME}/.claude-octopus/plugin}/scripts/safe-gh-comment.sh" \
    --repo OWNER/REPO issue-comment ISSUE_NUMBER -

Use gh issue edit --add-label only for the label mutation. Use bd update for tracked work. If bd writes are blocked by pending migrations, say so and do not run the migration — see skill-work-slicing for that constraint.

Provider Or Data Priority

1. The repository — reproduce against the actual code.
2. CI logs and run history for anything claiming a failure.
3. The reporter, for what only they can supply.
4. Never assume the report is accurate because it is detailed.

Stop Or Checkpoint Rules

• Stop before closing anything a human filed deliberately, unless it is a clear duplicate. Closing is the one move that is rude to get wrong.
• Stop before needs-decision items and surface them rather than guessing.
• Do not merge or push as part of triage, even for a PR that looks ready.
• One item at a time. Batch-labelling a queue without reading it is how real reports end up buried under a label.

Output Contract

Per item:

1. Reference and category.
2. State assigned, and why.
3. Verification result — reproduced, could not reproduce, or not attempted with the reason.
4. Brief — for verified items only.
5. Action taken — labels, comments, or the exact commands not run and why.

Then a queue summary: counts by state, and which items are now takeable.

Verification

• Every verified item was actually reproduced, or says explicitly that it was not and why.
• Every needs-info names the specific missing thing.
• Every closure carries a reason.
• Nothing was merged, pushed, or fixed during triage.