metamask-docs / rules
Cursor rule865 starsChanged 16 days agoApache-2.0View on GitHub
Markdown formatting conventions for the MetaMask documentation site (Docusaurus).
- Reads credentials
- Installs packages
We split this markdown-formatting.mdc into the rules it gives an agent
18 rules. About 0 are common, 5 are distinctive, and 13 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
13
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 9
Follow the Consensys Markdown formatting guide for full details.
- Distinctive: line 15
Start each new sentence on a new line, even if the previous line is short.
- Very specific: line 20
Use relative file paths for links within the same product (for example, ./concepts/scopes.md).
- Very specific: line 21
Use absolute URL paths for cross-product links (for example, /snaps/learn/about-snaps).
- Distinctive: line 22
Use descriptive link text.
- Very specific: line 23
Use absolute links on CardList components.
- Very specific: line 27
Always specify the language on fenced code blocks (
javascript ,bash , etc.). - Very specific: line 33
After editing documentation, run npm run format so Prettier applies these rules to fenced code in Markdown/MDX (see .prettierrc).
- Very specific: line 36
Write code samples that can be copied, pasted, and run as-is.
- Very specific: line 38
Use angle-bracket placeholders for values the reader must supply (for example, <YOUR_INFURA_API_KEY>).
- Very specific: line 43
Use Docusaurus <Tabs> and <TabItem> components to display parallel content such as code samples in different languages or package-manager …
- Very specific: line 45
Import Tabs and TabItem from @theme/Tabs and @theme/TabItem at the top of the file.
- Very specific: line 49
Use Docusaurus admonitions: :::note, :::tip, :::caution, :::info, :::danger.
- Very specific: line 50
Add a custom title on the same line only when it helps scanning (for example, :::caution important).
- Distinctive: line 51
Do not nest admonitions.
- Distinctive: line 56
Use a tool like Markdown Table Formatter if needed.
- Very specific: line 64
If the frontmatter contains a title field, do not add a separate top-level # Heading to avoid a duplicate H1.
- Very specific: line 69
Use lowercase letters and dashes only (for example, send-transactions.md, not sendTransactions.md).
≈ “Common” is an estimate: at least 1 in 5 of the 6,350 Cursor rule files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
--- description: Markdown formatting conventions for the MetaMask documentation site (Docusaurus). globs: **/*.md,**/*.mdx alwaysApply: false --- # Markdown formatting Follow the [Consensys Markdown formatting guide](https://docs-template.consensys.net/contribute/format-markdown) for full details. The rules below cover the most common conventions. ## Line length and sentence breaks - Wrap lines at roughly 100 columns. - Start each new sentence on a new line, even if the previous line is short. This makes diffs easier to review. ## Links - Use relative file paths for links within the same product (for example, `./concepts/scopes.md`). - Use absolute URL paths for cross-product links (for example, `/snaps/learn/about-snaps`). - Use descriptive link text. Do not use "click here" or bare URLs. - Use absolute links on `CardList` components. ## Code blocks - Always specify the language on fenced code blocks (` ```javascript `, ` ```bash `, etc.). - Indent code with two spaces, not four. - In JavaScript, TypeScript, JSX, and TSX samples, use single-quoted string literals. - In JSON samples, keep double-quoted keys and strings (required by JSON syntax). - In any other language (for example, Swift, Kotlin, Dart, Solidity, Python, shell), follow that language's normal conventions for string quotes. - After editing documentation, run `npm run format` so Prettier applies these rules to fenced code in Markdown/MDX (see `.prettierrc`). - For npm install commands, use ` ```bash npm2yarn ` fences to produce automatic npm/yarn tabs. - Write code samples that can be copied, pasted, and run as-is. Do not include shell prompts (for example, `user@host $`) or trailing comments that break execution. - Use angle-bracket placeholders for values the reader must supply (for example, `<YOUR_INFURA_API_KEY>`). ## Tabs - Use Docusaurus `<Tabs>` and `<TabItem>` components to display parallel content such as code samples in different languages or package-manager commands. - Import `Tabs` and `TabItem` from `@theme/Tabs` and `@theme/TabItem` at the top of the file. ## Admonitions - Use Docusaurus admonitions: `:::note`, `:::tip`, `:::caution`, `:::info`, `:::danger`. - Add a custom title on the same line only when it helps scanning (for example, `:::caution important`). - Do not nest admonitions. ## Tables - Align table columns in the source Markdown for readability. - Use a tool like [Markdown Table Formatter](https://markdowntable.com/) if needed. ## Frontmatter - Required: `description` (one sentence for SEO and previews). - Recommended: `keywords` (array). - `sidebar_label`: optional. Use sparingly; only when the default sidebar text (usually from the page title) would be too long or wordy for the navigation. Omit when the default is fine. - If the frontmatter contains a `title` field, do not add a separate top-level `# Heading` to avoid a duplicate H1. ## File and folder names - Use lowercase letters and dashes only (for example, `send-transactions.md`, not `sendTransactions.md`).
Where files are headingNew Cursor rule files have more rules about planning and tracking tasks, and fewer about code style.
Of the Cursor rule files we read, the 3,978 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository15 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .cursor/rules/content-types.mdcCursor rule
- .cursor/rules/contributor-workflow.mdcCursor rule
- .cursor/rules/editorial-voice.mdcCursor rule
- .cursor/rules/product-agent-wallet.mdcCursor rule
- .cursor/rules/product-embedded-wallets.mdcCursor rule
- .cursor/rules/product-infura.mdcCursor rule
- .cursor/rules/product-metamask-connect.mdcCursor rule
- .cursor/rules/product-smart-accounts-kit.mdcCursor rule
- .cursor/rules/product-snaps.mdcCursor rule
- .cursor/rules/terminology.mdcCursor rule
- .cursor/rules/vercel-redirects.mdcCursor rule
- static/llms.txtllms.txt
- author-pageSkill
- style-reviewSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

