investigate
by garrytanThe investigate skill guides systematic debugging and root-cause analysis for broken, flaky, or unexpected behavior. Use it for code review, incident triage, bug fixes, and "it worked yesterday" cases when you need evidence before changing code. It follows a four-phase workflow: investigate, analyze, hypothesize, implement.
This skill scores 82/100, which means it is a solid listing candidate for directory users: it clearly covers a common debugging/root-cause workflow and gives enough trigger guidance to reduce guesswork, though it still lacks some supporting repository materials that would make adoption easier.
- Clear, explicit triggerability for debugging and root-cause scenarios, including proactive invocation guidance for errors, stack traces, and "it was working yesterday" cases.
- Operational workflow is named and bounded into four phases—investigate, analyze, hypothesize, implement—with an iron-law constraint against fixes before root cause.
- Uses hooks and allowed-tools, which signals real execution behavior rather than a purely descriptive prompt.
- Repository has no install command, support files, references, or readme, so users must rely mainly on SKILL.md to understand setup and scope.
- Frontmatter includes placeholder markers, which suggests some parts may still be under refinement even though the main workflow content is substantial.
Overview of investigate skill
What the investigate skill does
The investigate skill is for systematic debugging and root-cause analysis when something is broken, flaky, or behaving differently than expected. It is designed for users who need more than a quick patch: if you want to understand why an error happens, what changed, and what fix is safe, investigate helps structure that work.
Who should use it
Use the investigate skill for code review, incident triage, bug fixing, and “it worked yesterday” situations. It is a strong fit when you need an agent to stop guessing, gather evidence, and work from symptoms toward a confirmed cause before changing code.
Why it stands out
The core differentiator is the “no fixes without root cause” rule. That makes the investigate skill more disciplined than a generic debug prompt: it pushes the workflow into investigation, analysis, hypothesis, and implementation instead of jumping straight to edits. It also supports proactive triggering, which is useful in agent workflows where the skill should activate as soon as errors or stack traces appear.
How to Use investigate skill
Install and invoke it
Install the investigate skill with:
npx skills add garrytan/gstack --skill investigate
Use it when your prompt clearly describes a failure state, such as a stack trace, 500 error, regression, or unexpected output. For best results, name the symptom, where it appears, and what “working” should look like.
Give the right starting input
A strong investigate usage prompt includes:
- the exact error message or log excerpt
- the command, endpoint, or user action that triggers it
- what changed recently
- what you already checked
- the impact and urgency
Example: “Investigate why npm test now fails in CI after the last merge. Compare main vs. HEAD, inspect recent changes in auth middleware, and do not propose code changes until the root cause is confirmed.”
Read the right files first
Start with SKILL.md, then inspect SKILL.md.tmpl for templated behavior or routing logic. Because this repository has no separate rules/, resources/, or scripts/ folders, the main value is in the skill file itself and any inline references it makes. For investigate for Code Review, pay special attention to the trigger language and the boundaries around safe operations before editing.
Workflow tips that improve output
Treat investigate as a decision workflow, not a freeform chat. Ask the agent to:
- identify the failure mode,
- collect supporting evidence,
- form one or two testable hypotheses,
- verify the likely cause,
- implement the smallest safe fix.
If you skip step 1, the skill may still generate analysis, but it will be less useful for code review or incident response.
investigate skill FAQ
Is investigate only for bugs?
No. The investigate skill also fits regressions, failed deployments, broken integrations, and unclear behavior changes. If the task is “figure out why this is happening,” investigate is usually the right starting point.
How is it different from a normal prompt?
A normal prompt may ask for a fix immediately. The investigate skill is more structured: it forces root-cause thinking first, which reduces brittle edits and makes the final change easier to defend in code review.
Is investigate good for beginners?
Yes, if the user can provide a symptom and a little context. Beginners usually benefit from the skill because it reduces guesswork, but they still need to share concrete evidence such as logs, steps to reproduce, or a failing command.
When should I not use it?
Do not use investigate when you already know the exact change you want, or when you are doing a straightforward content edit with no failure to diagnose. In those cases, a simpler task prompt is faster.
How to Improve investigate skill
Provide evidence, not just a complaint
The biggest quality jump comes from sharper inputs. Instead of “the app is broken,” provide the failing request, error text, file path, environment, and last known good state. The investigate skill performs best when it can anchor each hypothesis to observable evidence.
Narrow the search space
If the issue is in Code Review, identify the likely subsystem and the change window. For example: “Focus on auth, only changes from the last two commits, and verify whether the bug is reproducible in staging.” That keeps investigate from spreading too wide and improves the chance of a fast root cause.
Iterate after the first pass
If the first answer is inconclusive, ask for a tighter investigation rather than a broader rewrite. Good follow-ups are: “List the top three hypotheses with confidence levels,” “Show what evidence would disprove each one,” or “Trace the failure from input to output and stop before coding.”