Menu
Investigates a question to a grounded conclusion in which every claim is either verified against a primary source or explicitly flagged as an untested hypothesis.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Computes the optimal Claude usage-window ping schedule from work hours and creates or reconciles the scheduled cloud routines that pin the window boundaries.
Reviews changes to prose files (markdown, text, blog posts, docs). Focuses on voice, grammar, factual claims, dead links, and structure. Loads the project's voice or style guide when one exists. Skips linter and Actions hash verification.
Full code review for large or security-sensitive changes. Gathers requirements first, loads all relevant language references, runs the linter where applicable, applies the full review checklist with security as the top priority.
Reviews infrastructure changes: GitHub Actions workflows, Terraform, Dockerfiles, docker-compose, IaC. Focuses on supply-chain pinning, secret handling, least-privilege permissions, action versions, and CI failure modes. Always verifies action hash pins when present.
Abbreviated code review for small or low-stakes code changes. Skips requirements gathering. Skips the linter in PR mode (CI runs it). Focuses on correctness against obvious intent, readability, and pattern consistency. For large or security-sensitive diffs, use code-review-deep instead.
Orchestrator. Triages a PR, local diff, patch file, or staged/branch changes into one of four review types (content, code-lite, code-deep, infra) and dispatches to the matching child skill. Use this when you don't already know which depth or type of review you want. For a known type, invoke the child skill directly.
| name | investigate |
| description | Investigates a question to a grounded conclusion in which every claim is either verified against a primary source or explicitly flagged as an untested hypothesis. |
| when_to_use | Use when the user invokes /investigate, or asks you to get to the bottom of something, find a root cause, determine whether a reported issue is real, or verify a claim before acting on it (e.g. 'investigate X', 'why is X happening?', 'is this actually a bug?', 'are you sure?'). Do NOT use for a trivial single-fact lookup whose source is already known and unambiguous. Follow all steps in order; do not shortcut based on this description. |
| argument-hint | [what to investigate] |
Write one line: exactly what you are trying to determine, and what a confident answer looks like (a specific observation, value, or reproduction). This is the target every later step is measured against. If the question is ambiguous, ask one focused clarifying question and wait; do not guess the intent and investigate the wrong thing.
Do not reason from stale local files, cached ticket text, prior summaries, or memory. Re-fetch each input at its origin: pull the live ticket/PR, checkout or read the current code, look at the actual data. List the sources you will trust and mark which you have versus still need. This step is not optional when anything could have changed since you last saw it.
A claim is only as good as what it rests on. Read the actual code, not a comment describing it. Read the actual ticket thread, not a one-line summary of it. Check the actual data, not an assumption about its shape. Comments, docstrings, ticket summaries, and variable names are leads that tell you where to look, not evidence you can cite.
If a claim is about what happens when the system runs (it 404s, it breaks, it redirects, it regresses, it returns X), observe it happening: run the command, curl the endpoint, drive the page with Playwright, or write a test. Do not infer runtime behaviour from reading static code, config, or data files alone. Static inspection generates the hypothesis; execution confirms it.
"I can't verify this because X" is usually premature. Enumerate what you actually have (Playwright MCP, curl, git history, the dataset, a test harness, an MCP server) and try one before concluding a thing cannot be checked. An auth wall, a missing file, or an unfamiliar system is a reason to find the right tool, not to give up and guess.
If a step genuinely requires something you cannot do (the user runs the query, holds the credentials, or has context only they have), stop and give the user the exact query, command, or thing to observe, plus what result would settle the question. Do not guess it or quietly drop it. This is distinct from Step 5: that is for tools you have; this is for checks that are legitimately someone else's to run.
For every factual statement in your conclusion, mark it. Verified: say how (which file and line, which command, what you observed). Inferred: call it a hypothesis and state the single thing that would confirm or refute it. Confidence must track evidence, never present a plausible guess in the same voice as a checked fact.
When new information reverses an earlier claim, say so explicitly and state the fact that changed your mind. Do not silently swap conclusions; a reader who saw the first answer needs to know why it moved.
Lead with the answer in one or two sentences. Then give only the evidence that supports it. Cut restated context, alternatives you did not take, and hedging padding. If the reply runs long, the length must be load-bearing, not decoration.
