| name | triage |
| description | Triage an incoming issue or external PR — verify the claim, then write a behavioral agent brief or record the rejection in the out-of-scope KB. |
| argument-hint | [issue/PR number or what to triage] |
| disable-model-invocation | true |
| allowed-tools | Bash(gh *), Bash(git *) |
You are the coordinator/architect. You run the tracker/PR mechanics (gh/git) yourself, read for synthesis, and delegate the doing — verification goes to a dobby:researcher, and any resulting build work is a downstream /dobby:scope goal, never inline edits by you. Take an incoming issue or external PR from "reported" to a decision the maintainer signs off on, backed by a durable brief or an out-of-scope record.
Scope of this skill (portable half): verify-the-claim, the behavioral agent brief, and the out-of-scope KB. The tracker is always the gh-authenticated repo, but building out a full role/state-machine — canonical role names, discovery queries, elaborate label transitions — is out of scope here. Triage what the maintainer points you at; don't invent a labeling machine.
Triage vs. address-review. This skill triages incoming requests — an issue or an external PR proposing a change. Review-bot / reviewer comments on your own open PR (Greptile, CodeRabbit, humans) belong to /dobby:address-review — if the user hands you review threads on their active PR, point them there.
gh mechanics. For every GitHub read/write (fetch an issue/PR, read comments, post a comment, checkout a PR branch) reuse the recipes in ../address-review/references/github-api.md — derive OWNER/REPO from gh repo view --json owner,name, nothing hardcoded. Don't re-author gh commands.
AI disclaimer. Every comment you post to the tracker during triage MUST start with this line:
> *This was generated by AI during triage.*
Step 1: Gather context
Read the full issue or PR — body, comments, author, dates; for a PR, the diff too (gh pr diff N, per ../address-review/references/github-api.md). Then run two checks against the codebase, reading for synthesis (explore with the project's domain glossary in CONTEXT.md, respect ADRs in the area):
- Redundancy — search for an existing implementation of the requested behavior by domain concept, not the request's wording, and report where you looked. If it already exists, it's an already-implemented outcome (Step 4) — point to where it lives; do not write to the out-of-scope KB.
- Prior rejection — read
docs/out-of-scope/*.md and surface any concept that resembles this request (match by concept, not keyword — "night theme" matches dark-mode.md). If one matches, tell the maintainer: "This resembles docs/out-of-scope/dark-mode.md — rejected before because [reason]. Still holds?"
Both checks may also scan the tracker's open issues (is this concept already filed or previously rejected there?); that scan reads the configured tracker — read the tracker key from dobby.config.json narratively (absent → github) and follow the dedup / search recipe in ../backlog/references/trackers.md.
Present a short recommendation (bug vs enhancement, and your leaning) plus the codebase summary, including whether it's already implemented. Wait for the maintainer's direction before verifying or briefing.
Step 2: Verify the claim — dispatch a dobby:researcher
Before any brief, confirm the claim actually holds. Delegate this to a dobby:researcher (Agent tool, subagent_type: "dobby:researcher") — the architect does not run repros itself. Task it to:
- For a bug — reproduce it from the reporter's steps. Return the concrete code path that produces the symptom, or note where the repro diverges.
- For a PR — check out the branch (
gh pr checkout N, per the github-api reference) and run the tests/commands the diff claims to satisfy. Confirm the diff does what it says.
The researcher returns one of three verdicts:
| Verdict | Meaning | Effect on the brief |
|---|
| confirmed | Reproduced / the diff's tests pass | Strongest brief — fold the confirmed code path into it |
| failed | Could not reproduce / the diff's claim doesn't hold | Not a bug as reported (or the PR is broken) — tell the maintainer before briefing |
| insufficient | Not enough detail to attempt it | A strong signal to go back to the reporter for specifics before briefing |
Report the verdict to the maintainer and let them steer the outcome.
Step 3: Write the agent brief (when it's actionable)
If the maintainer wants this actioned by an agent or a human, write a behavioral, not procedural brief following references/agent-brief.md. The brief is the contract; the original discussion is only context.
The one hard rule: describe interfaces and behavioral contracts — never file paths or line numbers. The brief may sit unactioned for weeks while the codebase moves; paths and line numbers go stale, interface descriptions don't. Sections: Category · Summary · Current behavior · Desired behavior · Key interfaces · Acceptance criteria (checkboxes, each independently verifiable) · Out of scope.
- Actionable by an agent — post the brief as a comment (prefixed with the AI disclaimer). This brief can be handed straight to
/dobby:scope as a goal to start a work session.
- Needs a human — same structure, plus a line on why it can't be delegated (judgment calls, external access, design decisions, manual testing).
Step 4: Out-of-scope outcomes
When the maintainer decides not to action a request:
- Already implemented — the behavior already exists. Post a comment pointing to where it lives. Do NOT write to
docs/out-of-scope/ — that KB is for rejected requests only; recording a built feature there poisons the dedup checks with a false rejection.
- Rejected bug — a polite explanation comment, then close it as rejected via the close-as-rejected recipe in
../backlog/references/trackers.md (github: gh issue close --reason "not planned"; linear: the MCP tool that sets the issue state to Canceled; local: n/a). No KB entry (the KB is enhancements only).
- Rejected enhancement — this is the only case that writes to the KB. Record it in
docs/out-of-scope/ following references/out-of-scope-kb.md: one file per concept (kebab-case), deduped by concept not keyword — append to an existing concept file's "Prior requests" rather than creating a near-duplicate. Then post a comment linking the record (AI disclaimer first) and close it as rejected via the close-as-rejected recipe in ../backlog/references/trackers.md (same recipe as the rejected-bug outcome — github not-planned / linear Canceled / local n/a).
Next step
Present an AskUserQuestion restating that triage is done, with the applicable next-step routes as options (recommended first, plus Stop here). On selection, invoke the chosen /dobby:<skill> via the Skill tool; Stop here ends the turn.
- Briefed and ready to build →
/dobby:scope (Recommended) with the brief as the goal, to open a work session.
- Wontfix-rejected an enhancement → the concept is now recorded under
docs/out-of-scope/; future triage will surface it. Stop here.
- Verification came back
insufficient → the maintainer goes back to the reporter for specifics; re-triage when they reply. Stop here.
Language
Interact with the user in their language. The brief, out-of-scope records, and any posted comments are in English; keep domain terms in their real-world form.
Acceptance checklist
Adapted from mattpocock/skills engineering/triage (portable half — verify-first, behavioral brief, out-of-scope KB; the tracker/state-machine is intentionally not ported).
