verify

verify is a skill for Claude Code, Codex from emdash-cms/emdash. It costs 33 tokens per session (895 once invoked), scanned A, original, MIT.

A read-only review procedure for deciding whether diagnosed behaviour is truly a software bug or an intentional design choice. It compares the code with its comments, documentation, tests, project instructions, and other uses.

In plain words
What is it for?
Use it after diagnosis to inspect the relevant implementation and supporting materials, then classify the behaviour as a bug or as working as designed.
Why use it?
Finding code that explains a symptom does not prove that the code is wrong. This check prevents unnecessary fixes for documented behaviour, misunderstandings, or incorrect API use.

Skill for Claude CodeCodex

Written for no agent in particular: nothing here depends on one. Also seen: mentions AGENTS.md.

Good fit Use it after diagnosis to inspect the relevant implementation and supporting materials, then classify the behaviour as a bug or as working as designed.

Compare 6 skills from other repositories ↓
Install with agentmods
npx agentmods add skills/emdash-cms/emdash/verify
About the project

EmDash is a content management system for creating and managing websites, built with TypeScript and Astro and deployable on Cloudflare or Node.js with SQLite. It is for site owners and developers who want WordPress-like administration, templates, and plugins without PHP or separate hosting.

emdash-cms/emdash · 13,723 stars · on GitHub · emdashcms.com

Install

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.

Any agent
npx skills add emdash-cms/emdash --skill verify
Clone the repo
git clone --depth 1 https://github.com/emdash-cms/emdash

Made for: Claude Code, Codex.

Wrote 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.

agentmods badge for verify

README.md
[![agentmods](https://agentmods.dev/badge/skills/emdash-cms/emdash/verify/github.svg)](https://agentmods.dev/skills/emdash-cms/emdash/verify)
Your own site
<a href="https://agentmods.dev/skills/emdash-cms/emdash/verify"><img src="https://agentmods.dev/badge/skills/emdash-cms/emdash/verify/github.svg" alt="Measured on agentmods" height="20"></a>

Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.

agentmods 80×15 button for verify

Your own site · 80×15
<a href="https://agentmods.dev/skills/emdash-cms/emdash/verify"><img src="https://agentmods.dev/badge/skills/emdash-cms/emdash/verify.svg" alt="Reviewed on agentmods" width="80" height="20"></a>
Per session 33 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 895 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe. Third-party audits
  • NVIDIA SkillSpector pass 7 Sept 2026
How audits are shown
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce invoked
Fable 5.1 $0.00033 $0.00895
Opus 5.5 $0.00013 $0.00358
Sonnet 5.5 $0.00007 $0.00179
Haiku 4.5 $0.00003 $0.00089

Measured 1mo ago against content hash 36263edcfb8e, method: parsed. Prices are Anthropic first-party input rates as of 2026-10-07, from the pricing page.

Security

Grade A, and why

verify 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 1mo 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.

infra/emdash-bot/.flue/skills/verify/SKILL.md · 44 lines

How it starts

The opening of the file, as written. The whole thing — 44 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Verify

Diagnose found code that explains the symptom. That does not make the code wrong. Plenty of EmDash issues describe behaviour that is intentional but under-documented, surprising at first glance, or a misuse of the API. Tell the difference -- fix runs only when you say bug.

You read code, comments, docs, tests, and AGENTS.md. You modify nothing. No edits, no test runs, no dev servers.

Environment

Pure inspection -- entirely VFS work. Use read_file, ls, grep, and code to cross-reference code, docs, and tests. Do not attach a container.

Do not

  • No edits, no git commit, no git push.
  • No GitHub writes. Read-only API GETs only.
  • No network beyond the clone and the proxy-signed GitHub API.
  • Touch no issue other than the one being investigated.

Procedure

  1. Re-read the diagnose output. The file, the line range, the prose. Hold it in mind as you cross-reference.
  2. Read the surrounding code, not just the line. Comments immediately above and below; the function's docstring/JSDoc; its name and signature (often documents intent); adjacent branches and other call sites.
  3. Cross-reference documentation. AGENTS.md and CONTRIBUTING.md for repo-wide rules (SQL safety, locale filtering, RBAC, request caching, query-count budget); docs/ for user-facing behaviour that may be intentional; the package README or top-level docstring.
  4. Cross-reference tests. An existing test asserting the current behaviour means it is intentional -- unless the test itself is wrong. Open it, read what it asserts and why. A test named for the diagnosed function is the strongest intent signal the repo has.
  5. Decide -- three verdicts only:
    • bug -- behaviour matches the code, the code does not match documented or clearly implied intent, and the reporter's expectation is reasonable. (Missing locale filter; off-by-one pagination; a 500 where a 404 belongs; a permission check admitting the wrong actor.)
    • intended-behavior -- behaviour matches the code, and the code matches documented intent. ({ items, nextCursor } not a bare array; the X-EmDash-Request CSRF header requirement; slugs unique per-locale not globally per migration 019; a maintainer-only endpoint returning 403 to authors.)
    • unclear -- docs are silent and intent cannot be inferred. Maybe a bug, maybe not; the maintainer decides.
  6. Resist two failure modes. Do not call intended-behavior just because a test exists -- a test asserting wrong behaviour is part of the bug. Do not call bug just because the reporter is upset -- frustration is not a verdict.
  7. Explain, with citations. One or two short paragraphs per verdict, citing the specific comment, doc section, or test by path. For intended-behavior, state the documented intent explicitly so the bot's comment can point the reporter at it ("I think this is by design -- see <doc> / <test> -- happy to revisit if you disagree"). For unclear, list what you would need to know to decide.

Read the full file on GitHub · 44 lines

Changes

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.

  1. 1mo ago First seen · 44 lines · 33 tokens per session scan A 36263edcfb8e

Subscribe to this mod's changes

verify is a skill published in the GitHub repository emdash-cms/emdash (13,723 stars, last pushed today), licensed MIT. It adds 33 tokens to every session and 895 once invoked, about $0.0001 per session on Opus 5.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.

Related

Other skills, from other repositories

adversarial-reviewer

Stress-test a code change for concrete correctness defects, unsafe assumptions, and failure modes. Use when the user explicitly asks for an adversarial review, a deep bug hunt, or to tear a change apart. Do not use for ordinary review, style feedback, or general improvement suggestions.

EngDawood/emdash-claude-plugin · 62 tokens

webiny-api-logger-catalog

Name: Logger Import: import { Logger } from "webiny/api/logger" Source: @webiny/api-core/features/logger/index.ts Description: Structured logging with multiple log levels.

webiny/webiny-js · 16 tokens

creating-plugins

Create EmDash CMS plugins with sandboxed hooks, routes, storage, content and media APIs, MCP tools, and declarative admin UI, or native React and Astro extensions. Use when scaffolding or implementing an EmDash plugin.

EngDawood/emdash-claude-plugin · 50 tokens

emdash-cli

Use the EmDash CLI to inspect and manage an EmDash instance from the command line, including content, schema, media, taxonomies, menus, search, authentication, seeds, migrations, generated types, and whole-site export and import.

EngDawood/emdash-claude-plugin · 52 tokens

building-emdash-site

Build the site-facing parts of an EmDash CMS project on Astro, including schema and seeds, content queries, Portable Text rendering, menus, taxonomies, widgets, and deployment configuration. Use for EmDash site and theme work; use creating-plugins instead when the task is plugin authoring alone.

EngDawood/emdash-claude-plugin · 66 tokens

wordpress-plugin-to-emdash

Analyze and port WordPress plugin behavior, custom post types, shortcodes, admin workflows, and stored data to current EmDash extension points. Use for WordPress-plugin migrations or when deciding which behavior belongs in an EmDash plugin, site schema, seed, or Astro code. Do not use for visual theme ports without…

EngDawood/emdash-claude-plugin · 73 tokens