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:
- 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.
- 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:
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:
- Line number - approximate location in the file.
- Category - Voice/Tone, Terminology, Formatting, Content Type, Page metadata, or Workflow.
- Issue - what is wrong.
- 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.
1---2name: style-review3description: 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.4---56# Style review78## When to use910- You want to check existing content for style, terminology, formatting, or content-type issues.11- You are preparing to submit a PR and want a structured editorial pass.1213## Inputs1415The user provides a file path or directory to review. If not provided, ask what to review.1617## Step 1: Identify the product and content type1819Read the file path to determine:20211. **Product area** - which product folder the file lives in (for example, `metamask-connect/`,22 `snaps/`, `agent-wallet/`). Load the corresponding product rule from `.cursor/rules/product-*.mdc`.23 For Infura content, use `.cursor/rules/product-infura.mdc` and link to Infura documentation.242. **Content type** - which folder determines the expected structure (for example, `concepts/`,25 `how-to/`, `reference/`). Use `.cursor/rules/content-types.mdc` for the mapping.2627## Step 2: Run Vale (if available)2829Try running Vale on the target file:3031```bash32vale <file-or-directory>33```3435If Vale is not installed, skip this step and note it in the report. Continue with the manual review.3637## Step 3: Review against editorial rules3839Read the file fully. The following points are quick reminders; use the linked `.mdc` files as the40source of truth for full criteria, examples, and edge cases.4142### Voice and tone (editorial-voice.mdc)4344- Active voice and present tense used throughout.45- Second person ("you"), not "the developer" or "users."46- Contractions used where appropriate.47- No marketing language, superlatives, or promotional tone.48- No em dashes or en dashes; use commas, parentheses, or semicolons.49- First sentence of each section gets to the point.50- No slang, figures of speech, or culturally specific idioms.5152### Terminology (terminology.mdc)5354- Product names match the required forms (dapp, MetaMask, smart account, web3, etc.).55- Standards spelled out on first use with identifier in parentheses (for example,56 "Chain Agnostic Improvement Proposal 25 (CAIP-25)"), short form on subsequent references.57- Product-specific terminology matches the corresponding `product-*.mdc` rule file.5859### Markdown formatting (`markdown-formatting.mdc`)6061- Lines wrapped at about 100 columns.62- Each sentence on its own line.63- Code blocks have a language tag.64- Links use relative paths within the product, absolute paths across products.65- Descriptive link text; no "click here" or bare URLs.66- Admonitions use Docusaurus syntax and are not nested.67- Tables are aligned in source Markdown.68- No duplicate H1 if page metadata contains a `title` field.6970### Content type compliance (content-types.mdc)7172- Page structure matches the expected content type for its folder.73- Concept pages: no step-by-step instructions, ends with "Next steps."74- How-to pages: goal stated first, prerequisites listed, numbered steps.75- Reference pages: parameter format matches surrounding pages in the same product section.76- Quickstart pages: complete, copy-paste-and-run code.77- Troubleshooting pages: symptom/error first, then fix.7879### Page metadata8081- `description` field present (one sentence for SEO).82- `sidebar_label` only when needed (default nav label would be too long or wordy); otherwise omit.83- No duplicate H1 if `title` is set in page metadata.8485### Contributor workflow (contributor-workflow.mdc)8687- If the file is new, verify it has been added to the correct sidebar file.88- If the file was moved or renamed, verify a redirect exists in `vercel.json`.89- Cross-product links use absolute URL paths.9091## Step 4: Generate the report9293Present findings as a structured report grouped by category. For each issue:94951. **Line number** - approximate location in the file.962. **Category** - Voice/Tone, Terminology, Formatting, Content Type, Page metadata, or Workflow.973. **Issue** - what is wrong.984. **Suggestion** - how to fix it.99100### Report format101102```103## Style review: <file>104105### Product: <product name> | Content type: <type>106107### Summary108- X issues found (Y from Vale, Z from manual review)109- Severity: A critical, B suggestions110111### Voice and tone112- Line 12: Passive voice - "The block number can be specified..." → "Specify the block number..."113114### Terminology115- Line 8: "smart contract account" → Use "smart account" per terminology.mdc.116117### Formatting118- Line 45: Code block missing language tag.119- Line 22: Em dash found - replace with comma or period.120121### Content type122- Page is in `concepts/` but contains numbered step-by-step instructions. Move steps to a123 how-to page and link to it.124125### Page metadata126- Missing `description` field.127```128129If reviewing a directory, produce one report per file, then a summary at the end showing totals130across all files.131132If no issues are found, say so explicitly.