---
name: Verify
slug: verify-2
category: Quality
description: Verify decides whether diagnosed behavior is a real bug or expected by design. Use it when you need to compare code against docs and tests before allowing a fix.
github: "https://github.com/emdash-cms/emdash/tree/main/infra/emdash-bot/.flue/skills/verify"
language: TypeScript
stars: 11579
forks: 1083
install: "npx degit https://github.com/emdash-cms/emdash/tree/main/infra/emdash-bot/.flue/skills/verify ~/.claude/skills/verify"
installs_to: ~/.claude/skills/verify
source_path: infra/emdash-bot/.flue/skills/verify/SKILL.md
collection_size: 25
category_size: 1354
collection_url: "https://dirskills.com/collections/emdash-cms/emdash"
added: 2026-08-12T04:42:41.866Z
last_synced: 2026-08-12T04:42:41.866Z
canonical_url: "https://dirskills.com/skills/verify-2"
---

# Verify

Verify decides whether diagnosed behavior is a real bug or expected by design. Use it when you need to compare code against docs and tests before allowing a fix.

**Install:**

```bash
npx degit https://github.com/emdash-cms/emdash/tree/main/infra/emdash-bot/.flue/skills/verify ~/.claude/skills/verify
```

## README

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

## Output

Return:

- Verdict: `bug`, `intended-behavior`, or `unclear`.
- Reasoning: prose supporting the verdict, with paths to the comments, docs, or tests you relied on. A verdict without a citation is confident noise -- cite or downgrade.

The workflow uses your verdict as a gate. `bug` triggers fix only when diagnose also pinned the cause (confidence not `low`), rated the fix `mechanical` or `clear-best-option`, _and_ the maintainer directive is a fix directive. A `bug` needing a design decision, an `unclear`, or `intended-behavior` all stop here and produce a comment-only outcome.