Skills DirectorySkills Directory
SkillsLearnSecurityCategoriesDocsCommunityBlog
Sign InSubmit Skill
Skills Directory

Security-tested agent skills for Claude, coding agents, and AI workflows.

Directory

  • Browse Skills
  • All Skills A–Z
  • Claude Skills
  • Claude Code Skills
  • Agent Skills
  • Categories
  • Authors
  • Submit a Skill

Learn

  • Learn Hub
  • Install Claude Skills
  • Write SKILL.md
  • Skills vs MCP
  • Directories Compared

Security

  • Security
  • Methodology
  • Secure Claude Skills
  • Security Badges

Company

  • About
  • Community
  • Blog
  • API Docs
  • Advertise

2026 Skills Directory. All rights reserved.

ProTermsPrivacyRefunds
Back to skills

Investigate

ASecurity

Root-cause a failure before any fix - the iron law is no fixes without investigation. Exact symptom statement, minimal repro, known bug classes first, a hypotheses-vs-evidence table with discriminating tests, root cause at file:line, and a hard stop after three failed fixes. Use when debugging an error, a failing test, or unexpected behavior, or when the user asks to investigate or root-cause something.

2 stars
0 votes
0 copies
0 views
Added 9/28/2026
ai-agentsrustgobashdebugginggit

Security Analysis

A100/100

Scanned 9/28/2026

Install to Claude Code

$npx -y skills add AaravChadha/acstack --skill investigate --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Investigate?

Add the live security badge to your README — it updates automatically with every re-scan.

Security grade badge for Investigate
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/aaravchadha-investigate/badge)](https://www.skillsdirectory.com/skills/aaravchadha-investigate)

More formats (shields.io, HTML) on the badges page.

Files
SKILL.md
---
name: investigate
description: Root-cause a failure before any fix - the iron law is no fixes without investigation. Exact symptom statement, minimal repro, known bug classes first, a hypotheses-vs-evidence table with discriminating tests, root cause at file:line, and a hard stop after three failed fixes. Use when debugging an error, a failing test, or unexpected behavior, or when the user asks to investigate or root-cause something.
argument-hint: "<symptom | issue#>"
---

# /investigate — no fixes without investigation

You are finding out why, not making it go away. A fix written before the
root cause is named is a guess wearing a fix's clothes.

`Adjacent skills:` /audit code (broad defect hunt over a path; /investigate
chases one symptom to its cause) · /do (executes planned work; /investigate
determines what the fix should be).

<!-- acstack:runtime -->
Run before the skill's steps — per invocation, not per session (4.36); failures degrade to markdown:
```bash
link="$(readlink "$HOME/.claude/skills/health" 2>/dev/null || true)"   # empty = not symlinked
pack="$(dirname "$(dirname "$link")")"   # NEVER trust this unless $link was non-empty
if [ "${link#/}" != "$link" ] && [ -x "$pack/bin/acstack-config" ] && ! "$pack/bin/acstack-config" runtime | grep -q '=off'; then
  "$pack/bin/acstack-config" || true          # resolved keys, with sources
  "$pack/bin/acstack-update-check" || true    # ≤1 fetch/day; silent ONLY if already checked today
  "$pack/bin/acstack-recall" || true          # LEARNINGS.md + bug-class names, capped 3KB
else
  echo "runtime off — proceeding without recall/update-check"
fi
```
<!-- /acstack:runtime -->

<!-- acstack:principles -->
## Operating principles

- Be direct. Push back in writing when the plan or the user is wrong. No sycophancy.
- Never delete a decision. Supersede it: `~~old~~ → **Verdict (YYYY-MM-DD):** new call — reason.`
- Never fix, tune, or delete a test or eval case to raise a score. Log the miss honestly and leave the case unchanged.
- Name exact things: regex patterns, function signatures, model names, before → after numbers. Never "fixed bugs".
- Attribution: follow the project's `attribution` setting (default `none`) — no AI-tool mentions in generated docs, no attribution trailers in commits or PRs. Commit with explicit `-m`/`-F` messages only.
- Config: read `.claude/acstack.md` at the project root (fall back to `~/.claude/acstack.md`) before acting. `## Settings` keys override pack defaults; a `## <skill-name>` section overrides both. Unknown keys and sections are ignored.
- Docs: BRIEF.md (frozen seed) / PLAN.md (living plan) / JOURNAL.md (rolling journal). If the repo uses legacy names (PLANNING_PROMPT.md / PLANNING.md / STATUS.md), use those instead — never create both.
- Recall: if `LEARNINGS.md` exists at the project root, read it before starting.
- Conduct: follow the `acstack-conduct` block in this repo's AGENTS.md — the word is the mode; the user sets the pace.
- Hackathon lane: if the project's AGENTS.md carries the `acstack:hackathon-lane` block, only `/do` changes the repository during the event. Any other skill that would write a tracked file, commit or push says what it would have done and stops; a change that is not a task goes through the lane's operator route.
<!-- /acstack:principles -->

**One document set.** Resolve exactly ONE BRIEF/PLAN/JOURNAL set and name
its path in the report's scope line. If more than one candidate set exists
— a monorepo, nested products, an `apps/*` tree each with its own docs —
list the candidates and STOP. Never pick one silently: a confident answer
about the wrong product is worse than no answer (conduct rule 8).

## The Iron Law

No fix is written until the investigation names a root cause backed by
discriminating evidence. This binds the model too: hitting a bug mid-task is
not an exemption from the law — it is the trigger for this skill.

## The investigation

**The verdict leads the report.** Open with the root cause in one line —
`root cause: <file:line> — <what is wrong>`, or `not found: <what was
ruled out>` — then the evidence that earned it. The cause currently lands
at step 5 of a long report; a reader who stops after one line must still
get the answer, which is the same verdict-first stance every other
report-shaped skill in the pack takes.

Method details in `references/investigation-method.md`. The sequence:

1. **Symptom statement.** Exact observed behavior: the error text verbatim,
   the failing input, expected vs actual. "It's broken" is not a symptom;
   neither is a paraphrased error message.
2. **Reproduce first.** A minimal command that shows the failure on demand.
   Can't reproduce → the investigation continues (narrow the conditions);
   a fix is not attempted against a failure you cannot summon.
3. **Known classes first.** Check the pack's
   `../audit/references/known-bug-classes.md` and the project's
   LEARNINGS.md before inventing hypotheses — most bugs are reruns.

   **Naming a class requires having read it.** The runtime recall preamble
   prints class *names* only, so a session can name a class it never opened
   — and one did, reporting "known class hit … checked first" on a run whose
   trace held no read of the file at all. Say which you did, in these words:

   - read the class → cite it, `known-bug-classes.md § <class name>`, and
     state which part of the class matched this symptom;
   - matched a name from recall without opening the file → say
     **"matches a class name from recall (full class not read)"**.

   The weaker claim is entirely acceptable — recall exists to be used, and
   the recall output itself says to read the full class when one matches.
   What is not acceptable is the stronger claim without the read behind it,
   because a reader cannot tell them apart afterwards.
4. **Hypotheses vs evidence.** A table: hypothesis | evidence that would
   confirm or kill it | test performed | result. A hypothesis with no
   discriminating test does not belong in the table — it's a hunch, and
   hunches don't gate fixes.
5. **Root cause.** `file:line`, the mechanism, and why it produces exactly
   this symptom — that last clause is what separates a root cause from a
   correlation that happens to sit nearby.
6. **Proposed fix + verification.** The fix, the command that proves it
   worked, and the regression risk. The fix is APPLIED only if the user
   asked for a fix; a bare `/investigate` ends with this report
   (assessment first, per conduct).

## Three strikes

After 3 failed fix attempts: STOP. Write the state up — each dead
hypothesis with the evidence that killed it, what remains untested, the
exact current symptom — into JOURNAL.md (document mode) or an issue comment
(tickets mode), and hand it to the user. There is never a silent fourth
attempt; a fourth guess destroys more context than it could recover.

## Tickets mode (`tracking: tickets`)

Preconditions — `gh` installed, `gh auth status` succeeding, and a GitHub
remote present. Name exactly which one failed and fall back to document
mode; never guess.
An `issue#` argument reads the issue for symptom context and prior
attempts. Findings are offered as a `gh issue comment` so the investigation
travels with the ticket — offered, not posted unasked.

**Invoked with no `issue#`, the offer still has to resolve to something.**
The instruction above named no target for a bare invocation, so a live run
in tickets mode simply made no offer at all. Do one of two things, and say
which:

- an open issue plainly describes this failure → name it and offer the
  comment against it, still unposted;
- none does → say so in one line — "no issue matches this failure; filing
  one is `/ticket`'s job" — and stop there. Do not open an issue to have
  somewhere to put the comment.

## Hard rules

- Every applied fix traces back to a row of the hypotheses table. No
  shotgun fixes, no "while I'm here" changes.
- Error text is quoted verbatim, always — paraphrases hide the clue.
- An investigation that overturns a plan assumption records it in PLAN.md
  as a dated decision (supersede, never silently edit).
- A failed investigation is a valid result: report what was ruled out and
  what evidence is missing. That is progress; a premature fix is not.

Attribution

AaravChadhaAaravChadha
View sourceMore from AaravChadha →
SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Related Skills

Caveman

Ultra-compressed communication mode that cuts output tokens while keeping technical accuracy. Levels: lite, full, ultra and the wenyan variants. Use for /caveman, "caveman mode", "talk like caveman", "be brief" or "less tokens".

1074701 votes

Hyperplan

Adversarial multi-agent planning skill. Self-orchestrates 5 hostile category members (unspecified-low, unspecified-high, deep, ultrabrain, artistry) via team-mode for ruthless cross-critique debate, distills only the defensible insights, then MANDATORILY hands the distilled insight bundle to the `plan` agent for executable plan formalization. Use when planning needs maximum rigor and surfacing of weak assumptions, blind spots, and over-engineering. Triggers: 'hyperplan', 'hpp', '/hyperplan', ...

695601 votes

Mcp Code Execution

Routes multi-tool workflows through MCP servers for large datasets and pipelines. Use when Bash tool overhead is limiting throughput on data-heavy tasks.

3351 votes

catchup

Recovers the conversation and failed tool calls of a previous Codex, Claude Code, Antigravity, Cline, Copilot CLI, Cursor, DeepSeek Harness, Kimi, OpenCode, Pi Agent, or ZCode session. Use when the user says "catch up", "what did the last session do", "get me up to speed", "I switched agents", asks to recover/summarize a previous session before continuing, or asks to diagnose or report a catchup failure. Do NOT use for the current conversation, git history, or any non-agent log.

691 votes

math-skill

A comprehensive mathematical reasoning skill for AI assistants — handles arithmetic to research-level problems with rigorous step-by-step reasoning, systematic verification, and transparent uncertainty handling

381 votes
View all in ai-agents →