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 agentmods add skills/emdash-cms/emdash/investigatenpx skills add emdash-cms/emdash --skill investigategit clone --depth 1 https://github.com/emdash-cms/emdashWhat 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 | $0.00048 | $0.02729 |
| Opus 5 | $0.00024 | $0.01365 |
| Sonnet 5 | $0.00010 | $0.00546 |
| Haiku 4.5 | $0.00005 | $0.00273 |
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 yesterday.
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 — 101 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Investigate an EmDash issue
You investigate one issue on emdash-cms/emdash. You run inside a durable Workspace filesystem owned by your agent. The EmDash source tree is hydrated into it at /workspace/repo -- that is your working root. The issue title, body, and any quoted comments are handed to you in your inputs; you do not need to fetch them.
You proceed through five stages: classify -> reproduce -> diagnose -> verify -> (conditionally) fix. The leaf skills carry the detail; this skill is the spine that decides which of them runs and in what order.
The one rule that overrides everything: no confident noise
Every stage produces a verdict, and every verdict carries its evidence -- the exact commands you ran and the output they produced. A claim with no transcript behind it is not a finding, it is noise, and posting it is worse than saying nothing.
"I could not reproduce this" with a transcript of what you tried is a first-class success. "I could not reproduce this" with nothing behind it is a failure. The same holds for a diagnosis, a verify verdict, or a fix: if you cannot show the work, downgrade the claim to what you can show.
Two corollaries when you report:
- "Reproduced" means you demonstrated the reported defect -- so demonstrate it. A failing test you ran, an error in command output, a browser transcript: any one of these is a full demonstration, and it does not need to copy the reporter's steps -- a failing unit test that exercises the same defect a UI report describes is a full reproduction of the issue. When you have one, report
reproduced: truewithout hedging. Time-box it: if a demonstration is not converging after a couple of angles, stop grinding and report the diagnosis. - A confident diagnosis without a confirming repro is its own verdict. When you identified the reporter's defect but could not demonstrate it here (environment limits, browser-only path), report
rootCauseFound: truewithreproduced: false-- that is thediagnosedverdict, and it is different fromnot_reproduced, which says "I investigated and found nothing wrong (or something else)." rootCauseFoundmeans a located defect, not an explanation. It requires a concrete flaw in this repo's current code -- file and mechanism -- that produces the reported misbehavior. "The behavior traces to X" is not a root cause when X is correct code, a since-fixed version, the reporter's environment, or infrastructure outside this repo: those arereproduced: false, rootCauseFound: false, with the explanation in the summary as a finding. If your "cause" implies no code change could fix it here, it is not a root cause.- Reproducing something is not reproducing the issue. Investigations surface real adjacent findings -- a latent defect the reported behavior never triggers, an infrastructure symptom outside this repo, a different bug nearby. Those are valuable: put them in the summary as findings, with
reproduced: falseandrootCauseFound: false(you did not find this issue's cause). The test is simple: is the failure you demonstrated the one the reporter described? Answer it honestly indemonstratedReportedIssue. - Distinguish "tried and could not" from "could not try." If the issue is missing the details a reproduction attempt would need (versions, config, content shape, exact steps), report
verdict: "unclear"and name precisely what is missing, instead of an emptynot_reproduced. Decide this from the issue text before standing anything up: a build or dev server cannot recover details the report never contained, and grinding the toolchain against an underspecified report burns the whole run to prove nothing. Asking the reporter early is the correct, complete outcome for such an issue -- not a lesser one.
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.
- yesterday First seen · 101 lines · 48 tokens per session scan A 7af6c2a1ca7c
investigate is a skill published in the GitHub repository emdash-cms/emdash (12,111 stars, last pushed 3d ago), licensed MIT. It adds 48 tokens to every session and 2,729 once invoked, about $0.0002 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-30.
Other skills, from other repositories
wordpress-plugin-to-emdash
Port a WordPress plugin to EmDash CMS. Use this skill when asked to migrate, convert, or port a WordPress plugin, theme functionality, or custom post type to EmDash. Provides concept mapping and implementation patterns.
building-emdash-site
Build and customize EmDash CMS sites on Astro. Use when creating pages, defining collections, writing seed files, querying content, rendering Portable Text, setting up menus/taxonomies/widgets, configuring deployment, or any task involving an EmDash-powered Astro site. Assumes basic Astro knowledge but provides all…
emdash-cli
Use the EmDash CLI to manage content, schema, media, and more. Use this skill when you need to interact with a running EmDash instance from the command line — creating content, managing collections, uploading media, generating types, or scripting CMS operations.
emdash-github-actions
Sets up GitHub Actions CI/CD workflows for EmDash plugins — TypeScript type-checking, ESLint linting, Vitest testing, npm publishing, and automated releases. ALWAYS use this skill when a user wants to create, add, set up, or configure GitHub Actions, CI/CD, automated checks, or deployment workflows for an EmDash…
adversarial-reviewer
Adversarial code review that assumes bugs exist and hunts for them. Use when asked to review code, find bugs, audit for correctness, stress-test a PR, or when someone says "tear this apart" or "what's wrong with this". Give no benefit of the doubt — every line is guilty until proven innocent.
agent-browser
Browser automation for testing and verification. Use when you need to interact with web UIs, verify visual changes, fill forms, or capture screenshots.