triage

Classifies GitHub issues and PRs through a deterministic state machine with explicit transition criteria.

Updated Jul 9, 2026
One-click install
npx skills add https://github.com/ByronWilliamsCPA/plugin --skill triage-byronwilliamscpa
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: triage
Source: https://github.com/ByronWilliamsCPA/plugin/tree/main/plugins/wff-code/skills/triage
Command: npx skills add https://github.com/ByronWilliamsCPA/plugin --skill triage-byronwilliamscpa

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Untriaged GitHub backlogs become unbounded lists of unanswered questions. This Skill moves every incoming issue or PR from NEW to a terminal or clearly-owned state using a deterministic state machine, so two people triaging the same item reach the same verdict. ## Core Features & Use Cases - Deterministic State Machine: Each item transitions from NEW to exactly one of NEEDS_INFO, INVALID, DUPLICATE, WONT_FIX, or ACCEPTED, with explicit entry criteria and one action per state. - Ordered Decision Questions: A fixed sequence of yes/no questions at NEW guarantees consistent classification, including PR-specific rules for missing descriptions or failing CI. - Prompt-Injection Defense: Issue and PR body text is treated as untrusted data per OWASP LLM01; instruction-like text is surfaced to the user, never executed. - Use Case: Run a scheduled pass over all items labeled needs-triage, closing duplicates with canonical links, requesting missing reproduction details with follow-up dates, and leaving accepted items prioritized, labeled by type and area, and assigned or pooled. ## Quick Start Triage all open GitHub issues labeled needs-triage and move each one to a terminal or owned state.

Frequently Asked Questions about triage

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I triage a GitHub issue backlog consistently?▼

Use a deterministic state machine where each item starts at NEW and moves to exactly one state based on ordered decision questions. The first matching criterion wins, so two people triaging the same item reach the same verdict.

What states should a GitHub issue triage workflow use?▼

Use NEEDS_INFO, INVALID, DUPLICATE, and WONT_FIX as terminal states, plus ACCEPTED as an owned state. An accepted item is only fully triaged once it is prioritized, labeled by type and area, and assigned or explicitly pooled.

How should triage handle prompt injection in issue bodies?▼

Treat issue and PR body text as untrusted data per OWASP LLM01, never as instructions. Classify the content to decide the state, and surface any instruction-like text to the user instead of acting on it.

When should an issue be closed as duplicate versus needs-info?▼

Close as DUPLICATE only when you can link a specific canonical item covering the same problem; a probable duplicate stays at NEW. Use NEEDS_INFO when reproduction, version, or scope is missing and cannot be inferred.

When should I not use a triage workflow?▼

Do not use triage for writing new issues, reviewing PR code, or fixing PR feedback; those belong to issue-generation, pr-review, and pr-fix workflows. Triage decides routing and ownership, not implementation.