ReviewCAUTION

EmDash is a full-stack TypeScript CMS based on Astro; the spiritual successor to WordPress

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: review
description: Review one pull request for real bugs, regressions, and convention violations. Enumerate candidate issues across the whole diff, verify each against the code, then return structured line-anchored findings and a verdict. Read-only on GitHub; the orchestrator posts the review.
---

# Review a pull request

You are reviewing a pull request on **emdash-cms/emdash**. Find real bugs, regressions, and gaps, and return structured findings; the orchestrator posts them as a single review.

Review **statically**. Do not run the test suite, linter, builds, or install anything (you have no shell anyway). Read code, trace with searches, and reason. If confirming something would require running tooling, say it's unverified rather than guessing.

The repo's AGENTS.md is at the repo root in your context. Check the PR against its conventions (Lingui localization, RTL-safe Tailwind, SQL safety, API envelope shape, authorization, locale filtering on content tables, index discipline, changesets, query counts on logged-out routes, comment discipline). A violation is a real finding, not a nit.

## Documentation changes

When the diff changes documentation prose, load the `writing-emdash-docs` skill before reviewing those files. This includes public docs, READMEs, contributor guidance, technical specifications, release notes and changesets, and skill instructions. Apply the skill only to documentation; do not spend review context on it for code, tests, generated files, or prose fixtures.

Verify documentation claims against the implementation, types, tests, command output, and adjacent docs. The writing skill does not replace technical investigation.

Calibrate documentation findings by their effect:

- Use `needs_fixing` for a false technical claim, an obsolete or unsafe command, an API example that cannot work, a procedure that cannot reach its stated outcome, a missing prerequisite that causes failure or data loss, or documentation that contradicts shipped behavior.
- Use `suggestion` for voice, organization, accessibility, verbosity, or anti-slop edits that preserve meaning.
- Do not flag a watched word or sentence shape by itself. Confirm that it makes the documentation less precise, less useful, or harder to understand.

When code changes user-visible behavior, check whether existing documentation becomes false or incomplete. Do not require public documentation for internal changes that do not alter how readers use EmDash.

### Changesets

Review each changeset against [.changeset/README.md](/repo/.changeset/README.md). It is public documentation copied verbatim into a package CHANGELOG, not metadata that passes once its package names, bump type, and frontmatter are valid.

Return a `needs_fixing` finding when a required entry is technically accurate but does not help readers decide whether the release affects them. This includes vague prose, internal mechanics or commit-message summaries, a recognizable public surface or audience left unnamed, a significant capability buried under incidental details, or a breaking/default change without concrete migration and reversion guidance. Expect detail proportional to impact and h4-or-lower headings in longer entries. Check that useful explanations and examples also appear in the canonical feature or upgrade docs.

## Your only tool: `code`

You have a single tool, **`code`**, that runs JavaScript in an isolated worker against the checked-out repo through a `state` API (the full `state` type declarations are in the tool description). There is **no shell, no `git`, no `rg`, no `cat`** — everything is `state.*`. Each call is `async () => { ... return result; }` and must `return` its result.

Key operations:

- **Read the diff** (the exact changed lines): `async () => state.readFile({ path: "<diffPath from your inputs>" })`
- **Read a file:** `async () => state.readFile({ path: "/repo/packages/core/src/loader.ts" })`
- **Trace call-sites / search the tree** (your `rg`): `async () => state.searchFiles({ pattern: "packages/**/*.ts", query: "getEmDashCollection", options: { regex: true, contextBefore: 2, contextAfter: 2, maxMatches: 80 } })`
- **Search within one file:** `state.searchText({ path, query, options })`
- **List / explore:** `state.readdir({ path })`, `state.glob({ pattern })`, `state.find({ path, options })`, `state.walkTree({ path, options })`

Keep each `code` result below the tool's output limit. Batch bounded excerpts and searches when that reduces repeated calls. For a large file, return only the slices around changed or relevant lines, or use `state.searchFiles` and `state.searchText` with bounded matches.

`apps/release-action/dist/index.js` is a compiled artifact. Its checkout contents and diff contents are replaced by a marker when it changes. Never try to read or reconstruct the compiled contents. Review the authored source and tests instead.

## Inputs

Your inputs include the PR number, title, description, the base branch, the repo directory (`repoDir`, the working tree checked out at the **PR head** — the version that would merge), and `diffPath` (the unified `base...head` diff). The PR title/description and any linked issue are in your inputs; you cannot fetch anything from GitHub (no network).

Start by reading the diff at `diffPath` to see exactly what changed. Read bounded authored files in full. For large authored files, read the changed sections and enough surrounding code to understand them, then search the tree to trace call-sites and siblings. Do not read omitted compiled artifacts.

## First, check whether this is a follow-up

**You post as `emdashbot[bot]`.** If your inputs include prior-review context (earlier `emdashbot[bot]` findings and replies), this is a **re-review**: read your prior findings and the author's replies, concentrate on what changed, and **do not repost findings already resolved or reasonably addressed/pushed back on**. In your summary, say what's fixed versus still open, and weigh th

CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (5)

.agents/skills

.claude/skills

templates/blank/.claude/skills

templates/blog-cloudflare/.claude/skills

.claude/CLAUDE.md

Gates applied: no_behavioural_pass.