# Style Review

> Review MetaMask documentation for editorial compliance (voice, terminology, formatting, content type, frontmatter, workflow). Use before submitting a PR or when asked to audit existing pages.

- Skill: `metamask/style-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add metamask/style-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/metamask/style-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: metamask (https://skillmd.com/u/metamask)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/metamask/style-review

---


# Style review

## When to use

- You want to check existing content for style, terminology, formatting, or content-type issues.
- You are preparing to submit a PR and want a structured editorial pass.

## Inputs

The user provides a file path or directory to review. If not provided, ask what to review.

## Step 1: Identify the product and content type

Read the file path to determine:

1. **Product area** - which product folder the file lives in (for example, `metamask-connect/`,
   `snaps/`, `agent-wallet/`). Load the corresponding product rule from `.cursor/rules/product-*.mdc`.
   For Infura content, use `.cursor/rules/product-infura.mdc` and link to Infura documentation.
2. **Content type** - which folder determines the expected structure (for example, `concepts/`,
   `how-to/`, `reference/`). Use `.cursor/rules/content-types.mdc` for the mapping.

## Step 2: Run Vale (if available)

Try running Vale on the target file:

```bash
vale <file-or-directory>
```

If Vale is not installed, skip this step and note it in the report. Continue with the manual review.

## Step 3: Review against editorial rules

Read the file fully. The following points are quick reminders; use the linked `.mdc` files as the
source of truth for full criteria, examples, and edge cases.

### Voice and tone (editorial-voice.mdc)

- Active voice and present tense used throughout.
- Second person ("you"), not "the developer" or "users."
- Contractions used where appropriate.
- No marketing language, superlatives, or promotional tone.
- No em dashes or en dashes; use commas, parentheses, or semicolons.
- First sentence of each section gets to the point.
- No slang, figures of speech, or culturally specific idioms.

### Terminology (terminology.mdc)

- Product names match the required forms (dapp, MetaMask, smart account, web3, etc.).
- Standards spelled out on first use with identifier in parentheses (for example,
  "Chain Agnostic Improvement Proposal 25 (CAIP-25)"), short form on subsequent references.
- Product-specific terminology matches the corresponding `product-*.mdc` rule file.

### Markdown formatting (`markdown-formatting.mdc`)

- Lines wrapped at about 100 columns.
- Each sentence on its own line.
- Code blocks have a language tag.
- Links use relative paths within the product, absolute paths across products.
- Descriptive link text; no "click here" or bare URLs.
- Admonitions use Docusaurus syntax and are not nested.
- Tables are aligned in source Markdown.
- No duplicate H1 if page metadata contains a `title` field.

### Content type compliance (content-types.mdc)

- Page structure matches the expected content type for its folder.
- Concept pages: no step-by-step instructions, ends with "Next steps."
- How-to pages: goal stated first, prerequisites listed, numbered steps.
- Reference pages: parameter format matches surrounding pages in the same product section.
- Quickstart pages: complete, copy-paste-and-run code.
- Troubleshooting pages: symptom/error first, then fix.

### Page metadata

- `description` field present (one sentence for SEO).
- `sidebar_label` only when needed (default nav label would be too long or wordy); otherwise omit.
- No duplicate H1 if `title` is set in page metadata.

### Contributor workflow (contributor-workflow.mdc)

- If the file is new, verify it has been added to the correct sidebar file.
- If the file was moved or renamed, verify a redirect exists in `vercel.json`.
- Cross-product links use absolute URL paths.

## Step 4: Generate the report

Present findings as a structured report grouped by category. For each issue:

1. **Line number** - approximate location in the file.
2. **Category** - Voice/Tone, Terminology, Formatting, Content Type, Page metadata, or Workflow.
3. **Issue** - what is wrong.
4. **Suggestion** - how to fix it.

### Report format

```
## Style review: <file>

### Product: <product name> | Content type: <type>

### Summary
- X issues found (Y from Vale, Z from manual review)
- Severity: A critical, B suggestions

### Voice and tone
- Line 12: Passive voice - "The block number can be specified..." → "Specify the block number..."

### Terminology
- Line 8: "smart contract account" → Use "smart account" per terminology.mdc.

### Formatting
- Line 45: Code block missing language tag.
- Line 22: Em dash found - replace with comma or period.

### Content type
- Page is in `concepts/` but contains numbered step-by-step instructions. Move steps to a
  how-to page and link to it.

### Page metadata
- Missing `description` field.
```

If reviewing a directory, produce one report per file, then a summary at the end showing totals
across all files.

If no issues are found, say so explicitly.