Triage
Triage a GitHub issue or a reported problem, check it is real and not by design (code...
Install
npx skills add vectorize-io/hindsight --skill triage -g -a claude-code -y- Repository
- vectorize-io/hindsight57.7k
- Category
- Design
- Updated
- 3d ago
- License
- MIT
- Context cost
- Lightabout 1,368 tokens
- Runs scripts
- No, instructions only
What it does
Triage a GitHub issue or a reported problem, check it is real and not by design (code, git history, PRs, Hindsight memory), find the code and patterns to reuse, build a proof-of-concept fix and prove it solves the problem, then explain the problem and the fix in behaviours before doing the full fix. Use when asked to "triage #N", "look into this issue", or "is this a real bug".
Triage
Input: a GitHub issue (number or URL) or a problem described in words. Goal: the user knows whether the problem is real, what it does, and what a fix would change, backed by a working POC, and decides before you do the full fix.
Don't do the full fix in this skill. It ends at step 5, with the user's answer.
1. Is it real, and is it a bug?
Read the issue fully (gh issue view <N> --comments): what the reporter saw, what they expected,
version, config. Then check both sides:
- Reproduce it. Find the smallest way to make it happen: a test, a script, an API call. If you can't reproduce it, say so and say what you tried.
- Check whether it's by design. The code shows what happens, not why. Look for the decision:
git log -S '<key string>' --oneline/git log -L/git blameon the lines involved, then read those commits.- The PRs behind them:
gh pr list --state all --search "<keywords>",gh pr view <N> --comments. - Related or duplicate issues:
gh issue list --state all --search "<keywords>". - Hindsight memory, if the plugin is installed (the
hindsight_*tools are available): search the knowledge pages and, when you need the why, run a reflect. Treat what it says as a past record, check it against the code.
2. If it makes no sense, stop here
If it's not real, already fixed, a duplicate, by design, a local setup problem, or not worth changing: tell the user plainly why, with the evidence (commit, PR, issue, line of code). Propose closing it with a short, kind comment, written out ready to post, e.g.:
This is by design: <one-line reason> (see #<PR>). <What to do instead, if anything.> Closing, feel free to reopen if I missed something.
Ask before posting or closing, never do it on your own.
3. Explore the code
Before writing anything, find what is already there:
