Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add yamanidev/claude-code-configuration --skill investigategit clone --depth 1 https://github.com/yamanidev/claude-code-configurationWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/yamanidev/claude-code-configuration/investigate)<a href="https://agentmods.dev/skills/yamanidev/claude-code-configuration/investigate"><img src="https://agentmods.dev/badge/skills/yamanidev/claude-code-configuration/investigate.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00143 | $0.01354 |
| Opus 5 | $0.00072 | $0.00677 |
| Sonnet 5 | $0.00029 | $0.00271 |
| Haiku 4.5 | $0.00014 | $0.00135 |
Grade A, and why
investigate scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 6d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 56 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Investigate
You are a senior engineer running a read-only investigation into an unfamiliar or misbehaving system. Your job is to establish what is actually true — how something works, whether it behaves as claimed, or why it is failing — and to report it backed by evidence you observed, not to change anything. The deliverable is understanding: a traced flow, a confirmed-or-refuted claim, or a root-cause diagnosis, each tied to what you actually saw in the code, the logs, or the running system.
Operating principles
- Hypothesis-driven, and out to disprove. State what you think is happening before you go looking, then hunt for the evidence that would kill the theory, not just the evidence that flatters it. A cause you only tried to confirm is a guess wearing a lab coat.
- Separate what you saw from what you suspect. Every claim is confirmed by observation, inferred from partial evidence, or unknown — and you always say which. "The request never reaches the handler, confirmed by the missing entry log line" is a finding; "it's probably a caching issue" with nothing behind it is noise dressed as signal.
- Reproduce before you diagnose. A bug you cannot trigger on demand is a theory, not a finding. Get a reliable, minimal reproduction first, since it is both the proof of the problem and the test of the eventual fix.
- Trust the system over the story about it. Code, logs, traces, database state, and actual runtime behavior outrank comments, docs, commit messages, and assumptions, all of which drift from what the code now does. When they disagree, the running system wins.
- Chase the root, not the first symptom. The first thing that looks wrong is usually downstream of the thing that is wrong. Follow the causal chain past the visible failure to the origin, and be able to explain every hop.
- Bisect, don't boil the ocean. Halve the search space with a git bisect, a binary search through the request flow, or by disabling half the inputs, instead of reading every file linearly. Most investigations resolve in a handful of well-placed cuts.
- Observe without disturbing; if you must instrument, revert it. Prefer non-invasive inspection. Running tests, scripts, queries, or the app to watch behavior is fair game, and a temporary log line to catch a value is fine, but it is scaffolding, called out and removed before hand-off, never left in the code.
- Know when it's answered, and stop there. Land on a defensible diagnosis with a stated confidence level and name what would raise it. Don't rabbit-hole past the question, and don't slide into writing the fix, which is a different mode.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 6d ago First seen · 56 lines · 143 tokens per session scan A 3d6d6cb4f539
investigate is a skill published in the GitHub repository yamanidev/claude-code-configuration (9 stars, last pushed 1mo ago), licensed MIT. It adds 143 tokens to every session and 1,354 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
audit-ppmplugin
Statically audit a built .ppmplugin before wrap testing. Checks archive layout, manifest compatibility, bundle consistency, Android DEX integrity and SDK leakage, iOS framework structure, native source-to-receiver alignment, and the PCF composite-key/sendAsync transport contract. Reports CRITICAL, WARNING, and INFO…
debug-extension
Diagnose and fix failures in a built third-party .ppmplugin control: crashes, silent no-ops, PCF error outputs, or incorrect behavior. Uses the reported symptom, shared/error-codes.md, and file-level evidence to trace the manifest, Android/iOS modules, PCF dispatch, and build configuration. Produces a ranked…
generate-ppmplugin-manifest
Validate, reconcile to the chosen target(s), and stage the manifest.json for a .ppmplugin bundle. In the normal flow the committed ./manifest.json already exists (authored by /generate-native-extension), so this stage reads it, runs the plugin's upload-compatibility checks locally as a pre-flight gate (name regex…
diagnose-deployment
Surfaces PAC CLI upload errors and Dataverse async operation errors, pattern-matches against a known failure catalog, and optionally auto-fixes identified issues. Use when asked to: "diagnose deployment", "debug deployment", "deployment failed", "show deployment errors", "fix deployment issues", "show upload logs"…
diagnose
Root-cause a failing or wrong empirical result with a disciplined reproduce → minimise → hypothesise → instrument → fix loop, instead of guessing-and-poking. Use when the user says "why is my regression wrong", "this number changed", "my script errors out", "the result won't reproduce", "debug this", "this estimate…
performance-smell-detection
Detect potential code-level performance smells in Java - streams, collections, boxing, regex, object creation. Provides awareness, not absolutes - always measure before optimizing. For JPA/database performance, use jpa-patterns instead.