Triage Incoming Issues With Evidence

What it does

Triage checks the existing implementation and full issue discussion before deciding what an incoming report means. It uses project-specific category and triage-state roles, with exactly one state at a time. Prior notes and rejection knowledge help avoid asking the same questions or reviving settled exclusions. A recommendation goes to the maintainer, supported by verified evidence. The source requires AI-generated triage posts to carry a disclosure, and treats external pull-request discovery differently from an explicitly named PR.

When to use it

• Determine whether a new bug report describes current behavior.
• Evaluate an incoming enhancement against existing capabilities and scope.
• Prepare a verified issue for implementation without repeating earlier questions.

Step-by-step workflow

1. Load project triage-role mappings and resolve conflicting states.
2. Read the complete issue or named PR, comments and relevant diff.
3. Search implementation, prior notes and rejected-scope knowledge.
4. Verify the claim and recommend a brief, needs-info outcome or closure to the maintainer.
5. Apply only authorized tracker updates with the required AI disclosure.

Example request

Use triage on the incoming report Export ignores timezone. Read the entire discussion, current export implementation and previous triage notes. Establish the expected timezone before declaring a bug. Recommend the project’s category and one triage state. Draft any follow-up question and an implementation brief supported by evidence. Do not post, relabel or close the issue until authorized.

Worked example

A report may claim that an export uses UTC when the documented contract already requires UTC. Triage should identify that contract and ask whether the request is for a different feature, rather than fabricate a reproduction. Conversely, a mismatch between the configured timezone and exported rows can support a concrete bug brief. If a prior comment already requested a sample, the agent should use that history instead of asking again. Final posted triage material needs the upstream disclosure.

What you get

A maintainer-facing recommendation and, where appropriate, an evidence-backed agent brief or specific information request.

How to evaluate the result

• Confirm the full thread and current implementation were inspected.
• Check there is exactly one proposed triage state.
• Verify disclosure and authorization before any external update.

What you need

Full issue access, source and diff access, configured label roles and project scope knowledge. Tracker mutations require appropriate permission.

Setup and activation

The publisher documents plugin setup for Claude Code, Codex and Copilot, and manual Agent Skills setup for Gemini CLI and other clients. Choose one distribution method per client to avoid duplicate skills. The engineering collection expects project-specific tracker, triage-label and document-location settings from setup-matt-pocock-skills. Keep referenced companion skills and files available. This catalogue review does not install or run them; scan the exact source before any later installation. Client tools, permissions and subagent support still need separate validation.

Limits and considerations

Triage is intended for incoming work, not already prepared implementation tickets. Conflicting state labels need resolution. AI-written posts must include: This was generated by AI during triage. A plausible explanation is not a verified reproduction.

Related workflows

• Use diagnosing-bugs for deeper reproducible failures.
• Use implement after a brief is ready.

License and reuse

MIT at repository level (Copyright 2026 Matt Pocock). Preserve the copyright and permission notice when redistributing substantial source material; inspect any separately licensed dependencies or assets.

Further reading

• Reviewed SKILL.md (immutable commit)
• Publisher README: setup and compatibility
• Reviewed MIT license