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.