triage-issue — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited triage-issue (Agent Skill) and scored it 92/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 2 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 2 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Investigate a reported problem, find its root cause, and create a GitHub issue with a TDD fix plan. This is a mostly hands-off workflow - minimize questions to the user.
This is an invoked helper skill, not a normal first stop for bug work. It normally runs from /qa when the per-issue depth check decides a specific reported bug needs root-cause analysis before it can be filed as a lightweight issue.
Use /triage-issue when the cause is unclear after lightweight exploration, the bug is a regression, reproduction is intermittent, multiple symptoms may share an upstream cause, or the user explicitly asks for diagnosis.
Do not use it directly as the entry point for bug conversations — start with /qa, which delegates here per issue when depth is warranted. Do not use it once the fix task is already clear enough for /execute either.
One question per turn. When the diagnosis requires user input, ask one question at a time and wait for the answer before asking the next. Triage is mostly hands-off — minimize questions, but the ones you ask are sequential.
>
Prefer single-select. Use single-select multiple choice when the user is choosing one direction, one priority, or one next step.
>
Use multi-select rarely. Reserve it for compatible sets — goals, constraints, non-goals, success criteria — that can all coexist. If prioritization matters, follow up asking which selected item is primary.
>
Use the platform's question tool when available. In Claude Code, useAskUserQuestion; in Codex,request_user_input; in Gemini,ask_user. Otherwise, present numbered options in chat and wait for the user's reply before proceeding.
Get a brief description of the issue from the user. If they haven't provided one, ask ONE question: "What's the problem you're seeing?"
Do NOT ask follow-up questions yet. Start investigating immediately.
Destination check (carry through from `/qa` or ask now). If this triage was delegated from /qa, the user has already answered the destination question and a Verification destination: line is attached to the report — carry it through into the issue (Step 5 template). If the triage was invoked directly without going through /qa, ask the destination question now from references/destination-check.md:
How will we know the fix worked end-to-end? Name the specific destination — a file/function, a log query, a dashboard view, a user-observable behavior, an assertion in a test — where the fix's effect must land.
At triage rigor, the answer must be substantive — by the time deep diagnosis is running, the destination should be answerable concretely. A vacuous answer (paraphrases the source-of-change, names "the code change exists", names emission without consumption) is a stronger signal here than at /qa intake: it suggests the structural condition references/destination-check.md describes (source-level finding without destination-side framing) is in play, and Step 2 should explicitly grep for the consumer/setup code before generating hypotheses. Two-or-more signals firing on the signal table AND a vacuous answer → pause triage and recommend /research Phase 0 before continuing.
Construct a deterministic feedback loop first. Before any code analysis or hypothesis work, build a fast, agent-runnable, pass/fail signal that reproduces the failure the user described. This is the highest-leverage activity in this skill — every later step is guessing without it. The loop can be a failing test, a curl returning the wrong status, a script that prints a known-wrong value, or whatever the stack supports. It must:
Do not proceed to hypothesis generation until the loop reproduces the failure. Hypothesizing without a deterministic loop is guessing; Zeller's TRAFFIC framework names "Reproduce" and "Automate" as separate prerequisite steps for a reason, and they dominate time-to-fix on hard bugs. If you cannot construct a reproducing loop within ~5 minutes, scan Zeller's six dimensions of uncontrolled input — data (specific values, sizes, encodings), user interaction (sequence and timing of clicks, keystrokes, navigations), time (clock state, time-of-day, scheduling), randomness (seeds, UUIDs, hash collisions), OS environment (locale, filesystem, network, env vars, container vs host), and thread schedules (concurrent ordering, race windows) — and stop to ask the user for the one missing input from those dimensions that would unblock reproduction. The taxonomy is a probe, not a recital: name the specific value, flag, environment, or sequence the loop is missing, not the catalog. If reproduction is genuinely impossible (live-only failure, hardware-dependent race), say so explicitly in the issue and flag the diagnosis as best-effort code reading rather than silently proceeding.
Recognize the Heisenbug pattern. If the failure disappears under a debugger, vanishes when logging is added, or shifts shape under different observation tools, the bug is almost certainly undefined behavior interacting with environmental differences (memory layout, optimization level, instrumentation overhead). The remedy is to find the undefined behavior in the code — uninitialized memory, a data race, reliance on unspecified ordering — not to switch debuggers or strip the logging. A vanishing bug is evidence about the bug's shape, not a reason to abandon the trace; do not silently downgrade Heisenbug-shaped reports to "live-only failure."
Use the Agent tool with subagent_type=Explore to deeply investigate the codebase. Your goal is to find:
Look at:
git log on relevant files)Form falsifiable hypotheses before testing any one. With the feedback loop in hand and the code path traced, list 3-5 ranked candidate causes. State each in falsifiable form:
If X is the cause, then changing Y will make the loop pass, and changing Z will make the failure worse or leave it unchanged.
Rank by strength of evidence — recent changes to the suspect path, structural plausibility, prior incident patterns. Show the ranked list to the user in one short message before testing the top hypothesis. The user checkpoint is cheap and catches insights you cannot infer from code reading alone ("we just deployed a change to candidate #3" is a common save). Drive the loop against the top hypothesis, revise the ranking when evidence contradicts it, and avoid anchoring on the first plausible idea — Zeller's scientific-method recipe.
If the bug is straightforwardly isolated (off-by-one, missing null check, typo), skip this section. Not every bug is systemic — structural diagnosis is for bugs where the root cause suggests a recurring condition.
After gathering evidence, step back from the code and diagnose the structural condition that allowed this bug to exist. This is the difference between "what broke" and "why the system is prone to this type of breakage."
Start by reading the failure at three levels: event (what just happened), pattern (what keeps happening), and structure (what conditions, incentives, delays, or missing feedback loops make the pattern likely). If you only explain the event, you have not finished diagnosing the issue.
Apply the diagnostic playbook:
If the structural diagnosis reveals a deeper architectural problem, note it in the issue for follow-up via /improve-codebase-architecture.
Feedback-loop diagram (optional). If a system archetype applies (shifting the burden, drift to low performance, fixes that fail, or any other named archetype from the catalog), consider invoking /mermaid to render the causal-loop diagram and embed it in the issue. Meadows' archetypes are canonically drawn in the source material; rendering them as prose loses part of what makes the archetype transferable to a reader pattern-matching their own failure. Skip when the archetype is named but its loop is one short causal step that prose already captures cleanly.
Run the proposed fix against the Step 2 feedback loop and confirm the loop now passes. If the loop still fails, your root cause identification is wrong — return to Step 2 and revise the hypothesis ranking. Only in the explicit "reproduction was genuinely impossible" branch from Step 2 may you skip this verification; in that case, restate that the root cause is a best-effort analysis based on code reading.
Based on your investigation, determine:
Seam check first. Before drafting cycles, confirm a regression test can be written at the right call site — a seam that exercises the real bug pattern, not a shallower stand-in. If the only available seam is too shallow (the bug lives in an inline closure inside a private method, only manifests through a global side effect with no public observer, or requires dependencies the production caller never injects), the regression test will encode false confidence.
Stop and treat that as the diagnosis output. A regression test at the wrong seam is worse than no regression test — it locks in a false-positive guard. Note in the issue that the bug exposes a missing test seam, recommend /improve-codebase-architecture with the specific call-site pattern, and either:
This is Ousterhout's rules-of-thumb red-flag posture: when the right test is "too hard to write," the structure itself is the finding.
Create a concrete, ordered list of RED-GREEN cycles. Each cycle is one vertical slice:
Rules:
Create a GitHub issue using gh issue create with the template below. Do NOT ask the user to review before creating - just create it and share the URL.
<issue-template>
Open with a short plain-language walkthrough (usually a single paragraph) that frames the bug for a reader who doesn't have the codebase in their head: what part of the system this touches in domain terms, what the user or system was trying to do, and why the failure matters. Then the concrete details:
Skip the walkthrough only for narrow, self-evident failures whose domain meaning is obvious from the stack trace. See references/writing-for-humans.md for the shape and revision bar.
[The destination the fix's effect must reach, named in domain terms — a user-observable behavior, a log/trace observation, a dashboard view, an assertion in a test. Distinct from the source-of-change. See references/destination-check.md for substantive vs vacuous examples. The TDD Fix Plan below should land its final passing assertion at this destination, not at a paraphrase of the source.]
Describe what you found during investigation:
Fix type: Correction (addresses root cause) / Workaround (suppresses symptom — note what the real fix would require)
Do NOT include specific file paths, line numbers, or implementation details that couple to current code layout. Describe modules, behaviors, and contracts instead. The issue should remain useful even after major refactors.
[Omit entirely for straightforward isolated bugs.]
A numbered list of RED-GREEN cycles:
GREEN: [Minimal change to make it pass]
GREEN: [Minimal change to make it pass]
...
REFACTOR: [Any cleanup needed after all tests pass]
</issue-template>
After creating the issue, print the issue URL and a one-line summary of the root cause.
/qa's per-issue depth check, that needs diagnosis before implementation/qa would otherwise have filed for this bug/improve-codebase-architecture when the bug reveals a deeper structural pattern, or when the Step 4 seam check finds no correct call site for a regression test/qa/qa loop for the next observation, or /execute (often via /tdd) when the bug is ready to implement~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.