diff --git a/.vale.ini b/.vale.ini
new file mode 100644
index 0000000..8c31f37
--- /dev/null
+++ b/.vale.ini
@@ -0,0 +1,26 @@
+StylesPath = styles
+MinAlertLevel = suggestion
+Vocab = PaperMoon
+
+# To also lint against Google's style, run `vale sync` after adding:
+#   Packages = Google
+# then add `Google` to the BasedOnStyles list below. Off by default to keep
+# this config offline-runnable.
+
+[*.md]
+BasedOnStyles = Vale, PaperMoon
+
+TokenIgnores = (?:dApp|TestNet|MainNet|ERC-\d+|JSON-RPC)
+BlockIgnores = (?s) *(```.*?```)
+
+# Rule-source files describe the rules and intentionally contain examples of
+# banned content. Exclude them from style checks; subjecting them to their
+# own rules is circular.
+[AGENTS.md]
+BasedOnStyles =
+
+[style-guide.md]
+BasedOnStyles =
+
+[checklist.md]
+BasedOnStyles =
diff --git a/AGENTS.md b/AGENTS.md
new file mode 100644
index 0000000..e8f4b43
--- /dev/null
+++ b/AGENTS.md
@@ -0,0 +1,353 @@
+# AGENTS.md — PaperMoon Documentation Rules for Coding Agents
+
+This file is the **machine-readable** PaperMoon style guide. Coding agents (Claude Code, Cursor, Codex, etc.) load `AGENTS.md` automatically from a repo root. Downstream PaperMoon docs repos should reference this file from their own `AGENTS.md` so these rules apply on every authoring session.
+
+The full prose version lives in [`style-guide.md`](./style-guide.md). If the two ever disagree, **the prose guide wins** — open a PR to reconcile.
+
+---
+
+## How to use this file
+
+If you are an authoring agent generating or editing documentation in a PaperMoon docs repo:
+
+1. Read the rules below **before** producing prose or markdown.
+2. Re-check the output against the **Pre-output checklist** at the bottom before returning it to the user.
+3. When a rule below is silent on a case, default to the [Google developer documentation style guide](https://developers.google.com/style).
+
+---
+
+## High-friction rules (the ones that get missed)
+
+These are the rules that authoring tools (and humans) violate most often. Treat them as hard constraints.
+
+### 1. List item punctuation
+
+Follow the [Google developer documentation style guide list rules](https://developers.google.com/style/lists). Summary:
+
+- Start each list item with a capital letter, unless case is part of the information (e.g., a glossary of `kebab-case` identifiers).
+- End each list item with a period or other sentence-ending punctuation, **except**:
+  - The item is a single word.
+  - The item does not contain a verb.
+  - The item is entirely in code font.
+  - The item is entirely link text or a document title.
+- A numbered step label ending in a colon (e.g., `1. Configure the node:`) already counts as punctuated — do not add a trailing period after the colon.
+- If a list ends up inconsistently punctuated, either rewrite for [parallel construction](https://developers.google.com/style/lists#parallel) or add end punctuation to every item for consistency. **Never mix punctuated and unpunctuated items in the same list.**
+
+For description-list items (`**Term**: Description.`): capitalize the term, capitalize the first letter of the description, and end the description with a period.
+
+Do:
+
+```markdown
+You can do any of the following by using the API:
+
+- Create an item.
+- Replace one item with another.
+- Update an item.
+- Delete an item.
+```
+
+```markdown
+The API supports the following actions:
+
+- Create
+- Replace
+- Update
+- Delete
+```
+
+Do not:
+
+```markdown
+- Create an item
+- Replace one item with another.
+- Update.
+- Delete an item
+```
+
+### 2. Bold
+
+Use bold **only** for:
+
+- UI element names (button labels, menu items, field names).
+- The term in a description list: `**Term**: Description.`
+
+Do not bold for emphasis in prose. Do not bold whole sentences. For emphasis on a specific word or phrase, use italics (single underscores: `_word_`) — see `style-guide.md` for the italics rule. For a stronger callout, use an admonition (`!!! note`, `!!! warning`).
+
+Do:
+
+```markdown
+Click **Deploy** to publish the contract.
+
+- **Endpoint**: The URL of the JSON-RPC node.
+- **Network**: The chain ID of the target network.
+
+Use _italics_ when you need to draw attention to a single word.
+```
+
+Do not:
+
+```markdown
+This is **really important** — you **must** save your key.
+
+The contract address is **0xabc...123**.
+```
+
+### 3. Headings — Chicago title case
+
+Capitalize the first word and all other significant words. Articles, coordinating conjunctions, and short prepositions stay lowercase unless they're the first word.
+
+Do:
+
+- `## Deploy a Contract to the Network`
+- `### Connect Your Wallet`
+
+Do not:
+
+- `## Deploy a contract to the network` (sentence case)
+- `## Deploying a Contract to the Network` (`-ing` form for a task heading — use the imperative)
+
+For task-based headings, use the imperative: **Create an Instance**, not **Creating an Instance**.
+For conceptual headings, use a noun phrase: **Blockchain Consensus Mechanisms**, not **Understanding Blockchain Consensus**.
+
+### 4. Numbers
+
+Spell out zero through nine. Use digits for 10 and above.
+
+Exceptions — always use digits:
+
+- Version numbers: `Node.js 18`, `Python 3`.
+- Measurements and units: `4 GB`, `8 cores`, `2 ms`.
+- Code and CLI flags: `--max-count 5`.
+- Inside tables.
+
+Do: `Run the command three times.`
+Do not: `Run the command 3 times.`
+
+### 5. Banned words and phrases (AI tells)
+
+Do not emit these. They are filler, marketing copy, or LLM clichés that PaperMoon documentation does not use.
+
+| Banned | Use instead |
+|---|---|
+| delve into, dive into | (omit, or "explore", "walk through") |
+| leverage | use |
+| utilize | use |
+| seamless, seamlessly | (omit) |
+| robust | (omit, or be specific: "production-tested", "fault-tolerant") |
+| powerful, cutting-edge, state-of-the-art | (omit) |
+| in today's world, in the modern era | (omit) |
+| it's important to note that | (omit — just state the thing) |
+| it's worth noting that | (omit) |
+| in summary, in conclusion | (omit — let the structure carry it) |
+| let's, we'll, our | (avoid first-person plural; address the reader as *you*) |
+| currently, at the time of writing, as of today | (omit — write timeless docs) |
+| etc. | "and more" or "and so on" |
+| simply, just, easily, obviously | (omit — never describe steps as easy) |
+| feel free to | (omit) |
+| under the hood | (omit, or "internally") |
+
+### 6. Em dash and en dash
+
+- **Em dash (`—`, U+2014)**: use sparingly to set off a parenthetical aside. Surround with spaces: `text — aside — more text`. Do not chain em dashes; one per sentence at most.
+- **En dash (`–`, U+2013)**: only for numeric ranges: `2024–2025`, `pages 10–14`.
+- **Hyphen (`-`)**: compound words and identifiers (`ERC-20`, `kebab-case`).
+
+Do not substitute two hyphens (`--`) for an em dash. Use the actual `—` character.
+
+LLM output tends to over-use em dashes. If your output has more than one em dash per paragraph, rewrite with periods or commas.
+
+### 7. Contractions
+
+Use contractions sparingly. Default to the expanded form (`do not`, `cannot`, `it is`) in reference and conceptual documentation. Contractions are acceptable in informal tutorials.
+
+### 8. Links
+
+- Use descriptive link text. Never use `here`, `this`, `click here`, `read more`, `learn more`.
+- Do not bold, italicize, or underline links.
+
+Do: `See the [project's faucet](https://example.com/faucet/) for test tokens.`
+
+Do not: `Get test tokens [here](https://example.com/faucet/).`
+
+### 9. Symbols and emojis
+
+- No emojis in documentation prose, headings, or bullet markers. This includes ✅, ❌, 🟢, 🔴, ⚠️, 🚀, and decorative symbols.
+- Even outside documentation prose (HTML templates, banners, UI elements where an emoji is intentional), never use the rocket emoji (🚀) for blockchain projects — it reads as speculative hype. Prefer a neutral alternative (📣, 📢) or text only.
+- Use `Do:` / `Do not:` text labels for DO/DON'T comparisons.
+- No ampersands (`&`) unless they are in a UI element label or code.
+- No exclamation marks.
+
+### 10. Voice and address
+
+- Address the reader as **you**.
+- Avoid first-person plural: no `we`, `our`, `let's`.
+- Tutorials and guides: active voice (`Deploy the contract.`).
+- Conceptual reference: passive is allowed (`The contract is deployed by the runtime.`).
+- Do not use unnecessarily gendered language.
+
+### 11. Terminology (PaperMoon-specific)
+
+Always use these spellings:
+
+| Use | Not |
+|---|---|
+| ERC-20, ERC-721, ERC-1155 | ERC20, ERC 20 |
+| JSON-RPC | JSON RPC, JSONRPC |
+| dApp | dapp, DApp (DApp is acceptable only at sentence start or in a Chicago title-case heading) |
+| TestNet | testnet, test net |
+| MainNet | mainnet, main net |
+| smart contract | smart-contract (unless used as an adjective: `smart-contract platform`) |
+| supermajority | super majority, super-majority |
+| and more / and so on | etc. |
+
+- Define every acronym on first use in each article.
+- When referring to a hyphenated identifier (a config flag, release profile, CLI option, package name) **as an identifier**, wrap it in backticks and keep its canonical casing on every mention. Never capitalize only the first letter because the identifier starts a sentence — rephrase so it is not sentence-initial.
+- When referring to the same thing by its prose name (not as an identifier), use the project's official title-case form without backticks.
+
+### 12. Variable placeholders in code examples
+
+Placeholders must:
+
+- Start with `INSERT_`.
+- Be `UPPER_SNAKE_CASE`.
+- Describe the value (`INSERT_CONTRACT_ADDRESS`, not `INSERT_VALUE`).
+- Not end with `HERE` or other generic words.
+- Be wrapped in quotes when the value type requires quotes.
+
+Do: `const address = 'INSERT_CONTRACT_ADDRESS';`
+Do not: `const address = 'YOUR_ADDRESS_HERE';`
+Do not: `const address = '<your-address>';`
+
+### 13. Code blocks
+
+- Every fenced code block declares a language: ` ```js `, ` ```py `, ` ```solidity `, ` ```bash `, ` ```json `.
+- Use inline code (single backticks) for filenames, variable names, function names, CLI flags, and single-line code references that are not meant to be copied.
+- Use fenced code blocks for anything multi-line or meant to be copied.
+
+### 14. Quotes
+
+- Double quotes in prose.
+- Periods and commas go **inside** the closing quote: `He said "yes."`
+- Single quotes only inside code, when the language's style guide specifies them (JavaScript: single; JSON/Python: double).
+
+### 15. Punctuation
+
+- Oxford comma, always: `red, white, and blue`.
+- Use colons (not dashes) to introduce lists.
+- No exclamation marks.
+
+### 16. Code identifiers in prose must be in backticks
+
+Every reference to a function name, method, type, module, pallet, variable, parameter, or file path in prose must be wrapped in backticks.
+
+Do: `` The handler invokes `auth.getUserId` to resolve the caller. ``
+Do not: `The handler invokes auth.getUserId to resolve the caller.`
+
+This is a recurring reviewer correction — on the second or third mention of an identifier, AI-generated prose often drops the backticks.
+
+### 17. Identifier and term consistency within a document
+
+Once you introduce an identifier or term on a page, use the same form throughout that page:
+
+- Pick one casing for an identifier and keep it (e.g., `getUserId` everywhere, not `getUserId` then `get_user_id`).
+- Pick one term for a role and keep it ("author" everywhere, not "author" then "editor" then "writer" unless those roles are distinct on this page).
+- Match what's in the source code or schema. If the code says `getUserId`, the docs say `getUserId`.
+
+### 18. Image file naming
+
+Image files use the pattern `<filename>-<number>.webp`:
+
+- `dashboard-overview-01.webp`, `dashboard-overview-02.webp`
+- Sequence-numbered so reorganizing a page does not break filename meaning.
+- Lowercase kebab-case. Lowercase `.webp` extension.
+
+Do not: `screenshot.webp`, `image1.webp`, descriptive-but-unnumbered names like `dashboard-overview-final.webp`.
+
+**Alt text**: provide non-empty alt text that describes the image for informative images. For purely decorative images (UI screenshots whose information is already in surrounding text, icons, visual-appeal-only images), use empty `alt=""` so assistive technologies skip them. See [Google's alt text guidance](https://developers.google.com/style/images#alt-text).
+
+### 19. Do not insert subheadings above lead-in-sentence lists
+
+If a list is introduced by a sentence ending in `:` ("The following extrinsics are supported:"), do not add an extra heading above it. AI-generated content tends to insert a subheading per list; reviewers strip them.
+
+Do:
+
+```markdown
+### Supported Extrinsics
+
+The pallet supports the following extrinsics:
+
+- `store`
+- `renew`
+```
+
+Do not:
+
+```markdown
+### Supported Extrinsics
+
+The pallet supports the following extrinsics:
+
+#### Extrinsics
+
+- `store`
+- `renew`
+```
+
+### 20. Do not mix description-list and free-form bullets
+
+If one bullet in a list uses `**Term**: Description.`, every bullet in that list must. If you can't write all of them in that form, drop the description-list format entirely and use plain bullets.
+
+---
+
+## Pre-output checklist (run before returning prose to the user)
+
+Mentally scan the draft for each item. Fix any miss.
+
+- [ ] Every list has consistent end-punctuation (all periods or none).
+- [ ] No bold used for emphasis in prose — only UI elements and description-list terms.
+- [ ] Every heading is Chicago title case; task headings use imperative form.
+- [ ] No banned phrases ("delve", "leverage", "seamless", "it's important to note", "let's", "currently", "simply", "etc.").
+- [ ] Single-digit numbers (0–9) spelled out in prose; digits used for versions, units, and code.
+- [ ] At most one em dash per paragraph; en dash used only for ranges.
+- [ ] Address the reader as "you"; no "we" / "our" / "let's".
+- [ ] Link text is descriptive (no "here", "this", "click here").
+- [ ] No emojis anywhere — including ✅ / ❌ / 🟢 / 🔴.
+- [ ] Every code block has a language tag.
+- [ ] Placeholders are `INSERT_UPPER_SNAKE_CASE` and describe the value.
+- [ ] Terminology: `ERC-20`, `JSON-RPC`, `dApp`, `TestNet`, `MainNet`.
+- [ ] Oxford commas present.
+- [ ] Every code identifier in prose is in backticks — including the second and third mention.
+- [ ] Identifiers and role terms are spelled the same on every mention in the page.
+- [ ] Image files follow `<filename>-<number>.webp`; alt text is non-empty for informative images (empty `alt=""` is allowed for purely decorative ones).
+- [ ] No subheading sits directly above a list that already has a lead-in sentence.
+- [ ] Description-list bullets are not mixed with free-form bullets in the same list.
+
+---
+
+## Linting
+
+This repo ships a starter [Vale](https://vale.sh) configuration in [`.vale.ini`](./.vale.ini) and [`styles/PaperMoon/`](./styles/PaperMoon/). Downstream repos should adopt it so the banned-phrase, terminology, and emoji rules are enforced mechanically rather than in prose review.
+
+Run locally:
+
+```bash
+vale .
+```
+
+---
+
+## How a downstream docs repo wires this in
+
+Add an `AGENTS.md` at the root of the downstream repo containing at least:
+
+```markdown
+# AGENTS.md
+
+This repo follows the [PaperMoon Documentation Style Guide](https://github.com/papermoonio/documentation-style-guide/blob/main/AGENTS.md). Read it before generating or editing any documentation in this repository.
+
+Project-specific overrides:
+
+- (list any deviations here, with rationale)
+```
+
+Coding agents that respect the `AGENTS.md` convention will load both files automatically.
diff --git a/README.md b/README.md
index 151051d..7109eb0 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,26 @@
 # PaperMoon Developer Documentation Style Guide
 
-This repository contains the PaperMoon style guide that sets forth the standards and best practices for crafting high-quality technical documentation. It is intended to help you produce clear, consistent, and accessible content. It covers various topics, from writing style and formatting to code examples, images, and more.
+This repository contains the PaperMoon style guide, which sets forth the standards and best practices for crafting high-quality technical documentation. It is intended to help you produce clear, consistent, and accessible content. It covers writing style and formatting, code examples, images, and more.
+
+## Files
+
+- **[`style-guide.md`](./style-guide.md)**: The prose style guide. This is the source of truth.
+- **[`AGENTS.md`](./AGENTS.md)**: The machine-readable companion that coding agents (Claude Code, Cursor, Codex, etc.) load automatically when the repo is opened. Front-loads the rules that AI-generated documentation most often violates.
+- **[`checklist.md`](./checklist.md)**: A human-reviewer checklist for use before requesting a PR review.
+- **[`.vale.ini`](./.vale.ini) and [`styles/PaperMoon/`](./styles/PaperMoon/)**: A starter [Vale](https://vale.sh) configuration that mechanically enforces the highest-friction rules (banned phrases, terminology, emoji, link text, placeholders). Run `vale .` locally and wire into CI.
+
+## Using this guide in a downstream docs repo
+
+Add an `AGENTS.md` at the root of your docs repo containing:
+
+```markdown
+# AGENTS.md
+
+This repo follows the [PaperMoon Documentation Style Guide](https://github.com/papermoonio/documentation-style-guide/blob/main/AGENTS.md). Read it before generating or editing documentation.
+
+Project-specific overrides:
+
+- (list any deviations here, with rationale)
+```
+
+Adopt `.vale.ini` and the `styles/PaperMoon/` directory to lint with the PaperMoon rules.
diff --git a/checklist.md b/checklist.md
index f97b961..c71e1dc 100644
--- a/checklist.md
+++ b/checklist.md
@@ -1,8 +1,10 @@
 # Documentation Checklist
 
-Before requesting a PR review, please check your work against this list of commonly missed items from the style guide. 
+Before requesting a PR review, please check your work against this list of commonly missed items from the style guide.
 
-Guidance for Grammarly, screenshots, and diagrams can be found on the internal Docs Standards page in the Wiki. 
+If you authored this content with an AI coding agent (Claude Code, Cursor, Codex, etc.), the [`AGENTS.md`](./AGENTS.md) rule set should already be loaded by the agent. Even so, _always_ run through this checklist before requesting review — these are the items reviewers most frequently flag.
+
+Guidance for Grammarly, screenshots, and diagrams can be found on the internal Docs Standards page in the Wiki.
 
 - [ ] Check your lists:
     - [ ] Ensure lists requiring a specific order (step-by-step instructions, etc.) are numbered.
@@ -14,11 +16,9 @@ Guidance for Grammarly, screenshots, and diagrams can be found on the internal D
 		    - [ ] The description starts with a lowercase letter.
 		    - [ ] Punctuation at the end of the description.
 - [ ] Check your links:
-	- [ ] Ensure all external links are followed by `{target=\_blank}` so they will open in a new tab when selected. For internal links, use your best judgment (i.e., links at the end of the page where we direct users to the next page do not need to open in a new tab).
-		- **Example**: `[Link text](link url){target=\_blank}`
 	- [ ] Use descriptive and meaningful link text:
-		- **Recommended**: "You can get DEV tokens for testing on Moonbase Alpha once every 24 hours from the [Moonbase Alpha Faucet](https://faucet.moonbeam.network/){target=\_blank}." 
-		- **Not recommended**: "You can get DEV tokens for testing on Moonbase Alpha [here](url){target=\_blank}."
+		- **Recommended**: "You can get test tokens once every 24 hours from the [project's faucet](https://example.com/faucet/)." 
+		- **Not recommended**: "You can get test tokens from the project's faucet [here](url)."
 - [ ] Check your images:
   - [ ] All browser screenshots should have the browser window in them, showing the URL.
   - [ ] For full page screenshots, they should have a minimum width of 1510px.
@@ -40,4 +40,19 @@ Guidance for Grammarly, screenshots, and diagrams can be found on the internal D
 	- [ ] Use dApp instead of dapp. DApp is ok at the beginning of a sentence or when capitalizing for a title or heading.
 	- [ ] Use TestNet instead of testnet or test net, unless otherwise specified per brand-specific guidelines.
 - [ ] Check for bold formatting on UI elements:
-	- [ ] **Example**: "Click `**Deploy**` to deploy your smart contract"
+	- [ ] Example: "Click `**Deploy**` to deploy your smart contract"
+	- [ ] Bold is not used for emphasis in prose. For emphasis on a specific word or phrase, use italics (`_word_`). For a stronger callout, use an admonition (`!!! note`, `!!! warning`).
+- [ ] Check for code identifiers in backticks:
+	- [ ] Every function, method, type, pallet, module, variable, parameter, and file path reference in prose is wrapped in backticks — on the first mention AND every subsequent mention.
+- [ ] Check identifier and term consistency within the page:
+	- [ ] An identifier is spelled the same on every mention (e.g., `getUserId` everywhere, not switching to `get_user_id`).
+	- [ ] A role or term is named the same on every mention (e.g., "author" everywhere, not switching between "author", "editor", and "writer" unless those roles are distinct on this page).
+- [ ] Check image filenames:
+	- [ ] Image files follow `<filename>-<number>.webp` (lowercase kebab-case, sequence-numbered).
+- [ ] Check structure for AI-generated redundancy:
+	- [ ] No subheading sits directly above a list that's already introduced by a lead-in sentence ending in `:`.
+	- [ ] No mixed description-list and free-form bullets in the same list.
+- [ ] Check for AI-generated tells:
+	- [ ] No banned phrases ("delve", "leverage", "seamless", "robust", "it's important to note", "in summary", "feel free to", "currently", "etc.", "simply", "just", "easily").
+	- [ ] At most one em dash per paragraph.
+	- [ ] Address the reader as "you" — no "we", "our", "let's" (except in informal tutorials).
diff --git a/style-guide.md b/style-guide.md
index 26ad4d9..6eb9c65 100644
--- a/style-guide.md
+++ b/style-guide.md
@@ -4,14 +4,18 @@ This document sets forth the standards and best practices for crafting high-qual
 
 The guidelines listed in this document aren't all-inclusive but strive to cover the basics. If this guide does not provide explicit guidance on a particular subject, please default to the [Google developer documentation style guide](https://developers.google.com/style).
 
+> **Authoring with an AI coding agent?** Read [`AGENTS.md`](./AGENTS.md) first. It is the machine-readable companion to this guide and front-loads the rules that LLM-generated output most often violates (list punctuation, bold misuse, em dashes, banned phrases, terminology). The prose guide below remains the source of truth.
+
 ## Table of Contents
 
 - [Content Guidelines](#content-guidelines)
   - [Best Practices](#best-practices)
+    - [Banned Phrases](#banned-phrases)
   - [Language](#language)
   - [Accessibility](#accessibility)
   - [Terminology](#terminology)
   - [Punctuation](#punctuation)
+    - [Em Dash and En Dash](#em-dash-and-en-dash)
   - [Text Formatting](#text-formatting)
     - [Bold](#bold)
     - [Italics](#italics)
@@ -22,11 +26,15 @@ The guidelines listed in this document aren't all-inclusive but strive to cover
     - [Capitalization](#capitalization)
   - [Table Formatting](#table-formatting)
   - [List Formatting](#list-formatting)
+    - [List Item Punctuation](#list-item-punctuation)
+    - [Description Lists](#description-lists)
   - [Links](#links)
 
 - [Code Guidelines](#code-guidelines)
   - [Code Formatting](#code-formatting)
     - [Code Formatting by Language](#code-formatting-by-language)
+    - [Code Identifiers in Prose](#code-identifiers-in-prose)
+    - [Identifier Consistency Within a Document](#identifier-consistency-within-a-document)
   - [Variable Conventions](#variable-conventions)
   - [Capturing Terminal Output](#capturing-terminal-output)
 
@@ -38,6 +46,7 @@ The guidelines listed in this document aren't all-inclusive but strive to cover
     - [Introductions](#introductions)
 
 - [Visual Aid Guidelines](#visual-aid-guidelines)
+  - [Image File Naming](#image-file-naming)
   - [Icons](#icons)
   - [Diagrams](#diagrams)
   - [Screenshots](#screenshots)
@@ -54,18 +63,41 @@ This section of the document provides guidelines on best practices, language usa
 - Keep sentences short and to the point. Avoid unnecessary jargon and ambiguity.
 - Maintain a neutral and objective tone. Avoid biases, opinions, or emotional language.
 - Provide context. Avoid assuming the reader already knows what you're talking about.
-- Stick to the facts. Avoid sounding like a sales pitch.
-- Write timeless documentation that doesn't anchor the content to a specific point in time. Avoid using "at the time of writing," "currently," etc.
+- Stick to the facts. Avoid sales-pitch language and filler phrases. See [Banned Phrases](#banned-phrases) for the explicit list.
+- Write timeless documentation that doesn't anchor the content to a specific point in time. Avoid using "at the time of writing," "currently," "as of today," and similar.
 - Use bulleted lists for key points and complex information and to break up walls of text (general readability).
 - Use numbered lists for step-by-step instructions and sequential items.
 
+#### Banned Phrases
+
+The following phrases are not used in PaperMoon documentation. They are filler, marketing copy, or AI-generated cliché. Rewrite or omit when they appear.
+
+| Banned | Use instead |
+|---|---|
+| delve into, dive into | (omit, or "explore", "walk through") |
+| leverage | use |
+| utilize | use |
+| seamless, seamlessly | (omit) |
+| robust | (omit, or be specific: "production-tested", "fault-tolerant") |
+| powerful, cutting-edge, state-of-the-art | (omit) |
+| simply, just, easily, obviously | (omit — never describe a step as easy) |
+| it's important to note that | (omit — state the thing) |
+| it's worth noting that | (omit) |
+| in summary, in conclusion | (omit — structure carries it) |
+| feel free to | (omit) |
+| under the hood | (omit, or "internally") |
+| in today's world, in the modern era | (omit) |
+| currently, at the time of writing | (omit — write timeless docs) |
+| etc. | "and more" or "and so on" |
+
 ### Language
 
-- Avoid possessive language, such as "our," "we," etc., unless writing an informal tutorial.
+- Avoid possessive and first-person plural language, such as "our," "we," and "let's," unless writing an informal tutorial.
 - Address the reader as _you_.
 - In tutorials and guides, where you're instructing a user to act, use an active voice.
 - In conceptual documentation, where you're not instructing a user to act, using a passive voice is permitted.
 - Be mindful of pronouns. Avoid unnecessarily gendered language.
+- Use contractions sparingly. Default to the expanded form (`do not`, `cannot`, `it is`) in reference and conceptual documentation. Contractions are acceptable in informal tutorials.
 
 ### Accessibility
 
@@ -76,27 +108,68 @@ This section of the document provides guidelines on best practices, language usa
 
 ### Terminology
 
-- For token standards, put a dash (`-`) between the standard prefix and the unique identifier for the standard. For example, ERC-20 instead of ERC20.
-- Use JSON-RPC instead of JSON RPC.
-- Use dApp instead of dapp or DApp (except at the beginning of a sentence).
-- Use "and more" or "and so on" instead of "etc."
+| Use | Not |
+|---|---|
+| ERC-20, ERC-721, ERC-1155 | ERC20, ERC 20 |
+| JSON-RPC | JSON RPC, JSONRPC |
+| dApp | dapp, DApp (DApp is acceptable only at the start of a sentence or in a Chicago title-case heading) |
+| TestNet | testnet, test net (unless overridden by a brand-specific guide) |
+| MainNet | mainnet, main net |
+| smart contract | smart-contract (unless used as a compound adjective: `smart-contract platform`) |
+| supermajority | super majority, super-majority |
+| and more / and so on | etc. |
+
+For token standards generally, put a dash (`-`) between the standard prefix and the unique identifier.
+
+- Define every acronym on first use in each article.
+- Hyphenated identifiers (config flags, release profiles, CLI options, package names) keep their canonical casing on every mention. Do not capitalize only the first letter because the identifier starts a sentence — rephrase the sentence so it is not sentence-initial.
 
 ### Punctuation
 
 - Use Oxford commas.
 - Use colons in lists (instead of dashes).
-- Use periods at the end of a list item. See [List Formatting](#list-formatting) for an example.
+- For list item punctuation, see [List Formatting](#list-formatting).
 - Do not use exclamation marks in formal writing.
 
+#### Em Dash and En Dash
+
+- **Em dash (`—`, U+2014)**: use sparingly to set off a parenthetical aside. Surround with spaces: `text — aside — more text`. At most one em dash per sentence. If a paragraph contains more than one em dash, rewrite using periods or commas.
+- **En dash (`–`, U+2013)**: only for numeric ranges (`2024–2025`, `pages 10–14`).
+- **Hyphen (`-`)**: compound words and identifiers (`ERC-20`, `kebab-case`).
+- Do not substitute two hyphens (`--`) for an em dash. Use the actual `—` character.
+
+Em-dash over-use is a common pattern in AI-generated prose. The pre-publish check is: count the em dashes per paragraph; if more than one, rewrite.
+
 ### Text Formatting
 
 #### Bold
 
 - Put bold elements between double asterisks (`**`).
-- Use bold formatting for:
-  - When referencing UI elements.
-  - List items where we're listing out terms with a description. The term will be in bold. See [List Formatting](#list-formatting) for an example.
-  - Sparingly can be used to highlight can't-miss, important things.
+- Use bold **only** for:
+  - UI element names (button labels, menu items, field names).
+  - The term in a description list: `**Term**: Description.` See [List Formatting](#list-formatting).
+- Do not bold for emphasis in prose. Do not bold whole sentences. For emphasis on a specific word or phrase, use italics (see the [Italics](#italics) section). For a stronger callout, use an admonition (`!!! note`, `!!! warning`).
+
+Do:
+
+```markdown
+Click **Deploy** to publish the contract.
+
+- **Endpoint**: The URL of the JSON-RPC node.
+- **Network**: The chain ID of the target network.
+
+Use _italics_ when you need to draw attention to a single word.
+```
+
+Do not:
+
+```markdown
+This is **really important** — you **must** save your key.
+
+The contract address is **0xabc...123**.
+```
+
+Bold misuse — peppering prose with `**emphasis**` — is a common pattern in AI-generated content. When reviewing, strip bold that isn't either a UI element or a description-list term.
 
 #### Italics
 
@@ -109,12 +182,19 @@ This section of the document provides guidelines on best practices, language usa
 
 #### Symbols
 
-- Do not use emojis.
+- Do not use emojis anywhere in documentation — including in headings, prose, bullet markers, callouts, or DO/DON'T markers. This includes ✅, ❌, 🟢, 🔴, ⚠️, 🚀, and similar decorative glyphs.
+- Even outside documentation prose (HTML templates, banners, intentional UI elements), never use the rocket emoji (🚀) for blockchain projects — it reads as speculative hype. Prefer a neutral alternative (📣, 📢) or text only.
+- For DO/DON'T comparisons, use the text labels `Do:` and `Do not:` instead of colored emoji.
 - Do not use ampersands (`&`) unless referring to a UI element that uses them.
 
 #### Numbers
 
-- Spell out numbers as words for numbers zero through nine.
+- Spell out numbers zero through nine in prose. Use digits for 10 and above.
+- Exceptions — always use digits:
+  - Version numbers (`Node.js 18`, `Python 3`).
+  - Measurements and units (`4 GB`, `8 cores`, `2 ms`).
+  - Code and CLI flags (`--max-count 5`).
+  - Inside tables.
 
 #### Quotes
 
@@ -138,35 +218,89 @@ This section of the document provides guidelines on best practices, language usa
 
 - Use ordered (numbered) lists for a sequence of steps.
 - Use unordered (bulleted) lists for items that are non-sequential and can be read or completed in any order.
-- For description lists, use the following formatting: `**Term**: Description.`
-  - Put the term in bold.
-  - Capitalize the term.
-  - Use a colon (`:`) between the term and the description.
-  - Use sentence case.
-  - If the description introduces a nested list, restructure the sentence so that only one colon is present at the end.
-- Add punctuation at the end of each list item if the item is a full sentence or a complete idea.  
-  Example:  
-  _You can do any of the following by using the API:_
-  - Create an item.
-  - Replace one item with another.
-  - Update an item.
-  - Delete an item.
-- Do not add punctuation at the end of list items if the item consists of a single word or a short piece of code.  
-  Example:  
-  _The API supports the following actions:_
-  - Create  
-  - Replace  
-  - Update  
-  - Delete
-- Maintain consistent grammar structure across all items in a list (e.g., all items should start with a verb, or all should be noun phrases).
-- This section provides only a subset of list formatting guidelines adapted for our documentation. For a complete and detailed reference, see the [Google Developer Style Guide on Lists](https://developers.google.com/style/lists#types-of-lists).
+- Maintain consistent grammatical structure across items in a list — all items should start with a verb, or all should be noun phrases.
+
+#### List Item Punctuation
+
+Follow the [Google developer documentation style guide list rules](https://developers.google.com/style/lists). Summary:
+
+- Start each list item with a capital letter, unless case is part of the information conveyed (e.g., a list of `kebab-case` identifiers).
+- End each list item with a period or other sentence-ending punctuation, **except**:
+  - The item is a single word.
+  - The item does not contain a verb.
+  - The item is entirely in code font.
+  - The item is entirely link text or a document title.
+- A numbered step label ending in a colon (e.g., `1. Configure the node:`) already counts as punctuated; do not add a trailing period after the colon.
+- If a list ends up inconsistently punctuated, either rewrite for [parallel construction](https://developers.google.com/style/lists#parallel) or add end punctuation to every item for consistency. **Never mix punctuated and unpunctuated items in the same list.**
+
+Do:
+
+_You can do any of the following by using the API:_
+
+- Create an item.
+- Replace one item with another.
+- Update an item.
+- Delete an item.
+
+Do:
+
+_The API supports the following actions:_
+
+- Create
+- Replace
+- Update
+- Delete
+
+Do not (mixed forms in one list):
+
+- Create an item
+- Replace one item with another.
+- Update.
+- Delete an item
+
+#### Description Lists
+
+For description lists, use the format `**Term**: Description.`
+
+- Put the term in bold.
+- Capitalize the term.
+- Use a colon (`:`) between the term and the description.
+- Capitalize the first letter of the description.
+- End the description with a period.
+- If the description introduces a nested list, restructure the sentence so that only one colon is present at the end.
+
+Example:
+
+- **Endpoint**: The URL of the JSON-RPC node.
+- **Network**: The chain ID of the target network.
+
+Do not mix description-list bullets with free-form bullets in the same list. If one item uses `**Term**: Description.`, every item in that list must.
+
+Do not (one item is a description-list bullet; the rest are free-form):
+
+- **Endpoint**: The URL of the JSON-RPC node.
+- The chain ID of the target network
+- Provide an API key in the header
+
+This section provides only a subset of list formatting guidelines adapted for our documentation. For a complete reference, see the [Google Developer Style Guide on Lists](https://developers.google.com/style/lists#types-of-lists).
 
 ### Links
 
-- Add `{target=\_blank}` to all links, except links to other sections on the same page.
-- Use descriptive link text; avoid using "this", "here", and other generic words in the link text.
+- Use descriptive link text. Avoid `this`, `here`, `click here`, `read more`, and `learn more`. If the link points to a specific article, use the title of that article as the link text.
 - Links do not require any in-line formatting, such as bold, italics, or underlining. Depending on the project and the design, links might be underlined, but that will be managed using CSS.
 
+Do:
+
+```markdown
+See the [project's faucet](https://example.com/faucet/) for test tokens.
+```
+
+Do not:
+
+```markdown
+Get test tokens [here](https://example.com/faucet/).
+```
+
 ## Code Guidelines
 
 This section of the document outlines guidelines for code formatting and conventions to adhere to.
@@ -184,6 +318,27 @@ This section of the document outlines guidelines for code formatting and convent
   ```solidity
   ```
 
+#### Code Identifiers in Prose
+
+Any reference to a code identifier in prose must be wrapped in backticks. This includes:
+
+- Function and method names: `getUserId`, `get_user_id`.
+- Module, type, and class names: `RoleManager`, `tokenStorage`.
+- Variable and parameter names: `userId`, `payload`.
+- File paths: `src/lib/auth.ts`.
+
+Do: `The handler invokes auth.getUserId to resolve the caller.` → write as `` The handler invokes `auth.getUserId` to resolve the caller. ``
+
+Do not: leave identifiers as plain words. AI-generated prose often drops backticks on the second or third mention of an identifier — reviewers flag this consistently.
+
+#### Identifier Consistency Within a Document
+
+When you introduce an identifier or term, use the same form everywhere in the same page:
+
+- If you write `getUserId` once, do not switch to `get_user_id` later — pick the form used in the source code and keep it.
+- If you describe the role as "author", do not switch to "editor" or "writer" in the next paragraph unless those roles are distinct on this page.
+- Spelling, capitalization, and casing of an identifier or term must be identical on every mention.
+
 #### Code Formatting by Language
 
 |    Language     |      JavaScript/TypeScript       |               JSON               |                      Python                      |                                                        Solidity                                                         |
@@ -203,9 +358,9 @@ This section of the document outlines guidelines for code formatting and convent
 - Root-level variables should be declared at the top of the code example (after any imports but before any functions).
 - Do not use all uppercase letters for variable names unless they are exported constants.
 
-  - 🟢 `export const PRIVATE_KEY = 'INSERT_PRIVATE_KEY';`
-  - 🔴 `const PRIVATE_KEY = 'INSERT_PRIVATE_KEY';`
-  - 🔴 `export const privateKey = 'INSERT_PRIVATE_KEY';`
+  - Do: `export const PRIVATE_KEY = 'INSERT_PRIVATE_KEY';`
+  - Do not: `const PRIVATE_KEY = 'INSERT_PRIVATE_KEY';`
+  - Do not: `export const privateKey = 'INSERT_PRIVATE_KEY';`
 
 - When users need to input personalized information, establish a variable to serve as a placeholder. Ensure that placeholder text adheres to the following conventions:
   - It should describe the variable.
@@ -217,18 +372,18 @@ This section of the document outlines guidelines for code formatting and convent
  
   See the following examples:
 
-    - 🟢 `const address = 'INSERT_CONTRACT_ADDRESS';`
-    - 🟢 `const addresses = ['INSERT_X_ADDRESS', 'INSERT_Y_ADDRESS', 'INSERT_Z_ADDRESS'];`
-    - 🟢 `const amount = INSERT_AMOUNT_TO_SEND;`
-    - 🔴 `const address = 'INSERT-CONTRACT-ADDRESS';`
-    - 🔴 `const address = 'INSERT_CONTRACT_ADDRESS_HERE';`
-    - 🔴 `const privateKey = 'insert_privte_key';`
+    - Do: `const address = 'INSERT_CONTRACT_ADDRESS';`
+    - Do: `const addresses = ['INSERT_X_ADDRESS', 'INSERT_Y_ADDRESS', 'INSERT_Z_ADDRESS'];`
+    - Do: `const amount = INSERT_AMOUNT_TO_SEND;`
+    - Do not: `const address = 'INSERT-CONTRACT-ADDRESS';`
+    - Do not: `const address = 'INSERT_CONTRACT_ADDRESS_HERE';`
+    - Do not: `const privateKey = 'insert_privte_key';`
 
 - If you're creating variables for arguments that need to be passed into a function, use the parameter name as the argument variable name. For example, if you have the following function:
 
   `execute(dest, weight)`
 
-  🟢 You should name the variables after the parameters. For this example, you would use dest and weight:
+  Do — name the variables after the parameters. For this example, use `dest` and `weight`:
   
     ```js
     const dest = 'INSERT_DEST';
@@ -236,12 +391,12 @@ This section of the document outlines guidelines for code formatting and convent
     execute(dest, weight);
     ```
 
-  🔴 This is as opposed to doing something like this:
+  Do not — invent new variable names that do not match the parameters:
   
     ```js
     const xcmDest = 'INSERT_DEST';
     const xcmWeight = 'INSERT_WEIGHT';
-    execute(xcmDest, xcmWeight);    
+    execute(xcmDest, xcmWeight);
     ```
 
 ### Capturing Terminal Output
@@ -284,6 +439,31 @@ This section of the document outlines guidelines for repository structure and pa
 - Use descriptive headings based on the purpose of the section:
    - For task-based content, use a task-based heading (i.e., use "Create an Instance" instead of "Creating an Instance")
    - For a conceptual or non-task-based heading, use a noun phrase that doesn't start with an "-ing" verb (i.e., use "Blockchain Consensus Mechanisms" instead of "Understanding Blockchain Consensus")
+- Do not insert a subheading immediately above a list that is already introduced by a lead-in sentence. If the lead-in is "These are the supported extrinsics:", do not add an extra `###` above the list. Replace the would-be subheading with a single sentence, or drop it entirely.
+
+Do not:
+
+```markdown
+### Supported Extrinsics
+
+The pallet supports the following extrinsics:
+
+#### Extrinsics
+
+- `store`
+- `renew`
+```
+
+Do:
+
+```markdown
+### Supported Extrinsics
+
+The pallet supports the following extrinsics:
+
+- `store`
+- `renew`
+```
 
 #### Introductions
 
@@ -298,6 +478,25 @@ When applicable, introductions should follow this recipe:
 
 This section of the document outlines guidelines for visual aids, such as images and diagrams. It is recommended to create templates for visual aids, such as diagrams and icons, to help promote consistency in style and size.
 
+### Image File Naming
+
+Image files must be named `<filename>-<number>.webp`, where `<filename>` matches the page or section the image belongs to and `<number>` is a zero-padded sequence reflecting the image's order on the page. This convention keeps images stable when pages are reorganized.
+
+Do:
+
+- `dashboard-overview-01.webp`
+- `dashboard-overview-02.webp`
+- `user-permissions-01.webp`
+
+Do not:
+
+- `screenshot.webp`
+- `image1.webp`
+- `dashboard-overview-final.webp` (no sequence number)
+- `Dashboard-Overview-01.WEBP` (use kebab-case, lowercase extension)
+
+Image alt text should describe the image in a complete phrase for informative images. For purely decorative images — UI screenshots whose information is already in surrounding text, icons used for visual interest, or images that are not informative on their own — use empty `alt=""` so assistive technologies skip them. See [Google's alt text guidance](https://developers.google.com/style/images#alt-text).
+
 ### Icons
 
 - Use icons from the same design system or library.
diff --git a/styles/PaperMoon/BannedPhrases.yml b/styles/PaperMoon/BannedPhrases.yml
new file mode 100644
index 0000000..e6507b2
--- /dev/null
+++ b/styles/PaperMoon/BannedPhrases.yml
@@ -0,0 +1,19 @@
+extends: existence
+message: "Don't use '%s'. See the Banned Phrases list in style-guide.md."
+level: error
+ignorecase: true
+tokens:
+  - "\\betc\\."
+  - "in today's world"
+  - "in the modern era"
+  - "it's important to note"
+  - "it is important to note"
+  - "it's worth noting"
+  - "it is worth noting"
+  - "in summary"
+  - "in conclusion"
+  - "feel free to"
+  - "at the time of writing"
+  - "as of today"
+  - "delve into"
+  - "dive into"
diff --git a/styles/PaperMoon/DiscouragedPhrases.yml b/styles/PaperMoon/DiscouragedPhrases.yml
new file mode 100644
index 0000000..7d93fa5
--- /dev/null
+++ b/styles/PaperMoon/DiscouragedPhrases.yml
@@ -0,0 +1,19 @@
+extends: existence
+message: "Consider rewriting without '%s' — often filler or LLM cliché."
+level: warning
+ignorecase: true
+tokens:
+  - "\\bleverage\\b"
+  - "\\butilize\\b"
+  - "\\bseamless\\b"
+  - "\\bseamlessly\\b"
+  - "\\brobust\\b"
+  - "\\bpowerful\\b"
+  - "\\bcutting-edge\\b"
+  - "\\bstate-of-the-art\\b"
+  - "\\bunder the hood\\b"
+  - "\\bcurrently\\b"
+  - "\\bsimply\\b"
+  - "\\bjust\\b"
+  - "\\beasily\\b"
+  - "\\bobviously\\b"
diff --git a/styles/PaperMoon/FirstPersonPlural.yml b/styles/PaperMoon/FirstPersonPlural.yml
new file mode 100644
index 0000000..700822a
--- /dev/null
+++ b/styles/PaperMoon/FirstPersonPlural.yml
@@ -0,0 +1,9 @@
+extends: existence
+message: "Avoid first-person plural ('%s'). Address the reader as 'you'."
+level: warning
+ignorecase: true
+tokens:
+  - "\\bwe\\b"
+  - "\\bour\\b"
+  - "\\bus\\b"
+  - "\\blet's\\b"
diff --git a/styles/PaperMoon/LinkText.yml b/styles/PaperMoon/LinkText.yml
new file mode 100644
index 0000000..c660657
--- /dev/null
+++ b/styles/PaperMoon/LinkText.yml
@@ -0,0 +1,10 @@
+extends: existence
+message: "Use descriptive link text. Avoid generic words like '%s' inside link text."
+level: error
+scope: text
+tokens:
+  - '\[here\]\('
+  - '\[click here\]\('
+  - '\[this\]\('
+  - '\[read more\]\('
+  - '\[learn more\]\('
diff --git a/styles/PaperMoon/NoEmoji.yml b/styles/PaperMoon/NoEmoji.yml
new file mode 100644
index 0000000..fc44755
--- /dev/null
+++ b/styles/PaperMoon/NoEmoji.yml
@@ -0,0 +1,15 @@
+extends: existence
+message: "Do not use emojis in documentation. Use 'Do:' / 'Don't:' labels instead of colored markers."
+level: error
+nonword: true
+tokens:
+  - '[\x{1F300}-\x{1F6FF}]'
+  - '[\x{1F900}-\x{1F9FF}]'
+  - '[\x{2600}-\x{26FF}]'
+  - '[\x{2700}-\x{27BF}]'
+  - '[\x{1F000}-\x{1F02F}]'
+  - '✅'
+  - '❌'
+  - '🟢'
+  - '🔴'
+  - '⚠️'
diff --git a/styles/PaperMoon/NoExclamation.yml b/styles/PaperMoon/NoExclamation.yml
new file mode 100644
index 0000000..48a6048
--- /dev/null
+++ b/styles/PaperMoon/NoExclamation.yml
@@ -0,0 +1,6 @@
+extends: existence
+message: "Avoid exclamation marks in formal writing."
+level: warning
+nonword: true
+tokens:
+  - '\w+!(?!\[)'
diff --git a/styles/PaperMoon/Placeholders.yml b/styles/PaperMoon/Placeholders.yml
new file mode 100644
index 0000000..7d20e9a
--- /dev/null
+++ b/styles/PaperMoon/Placeholders.yml
@@ -0,0 +1,8 @@
+extends: existence
+message: "Use INSERT_UPPER_SNAKE_CASE placeholders that describe the value. Avoid '%s'."
+level: warning
+ignorecase: false
+tokens:
+  - "YOUR_[A-Z_]+_HERE"
+  - "INSERT_[A-Z_]+_HERE"
+  - "<your-[a-z-]+>"
diff --git a/styles/PaperMoon/Terminology.yml b/styles/PaperMoon/Terminology.yml
new file mode 100644
index 0000000..01da20f
--- /dev/null
+++ b/styles/PaperMoon/Terminology.yml
@@ -0,0 +1,15 @@
+extends: substitution
+message: "Use '%s' instead of '%s'."
+level: error
+ignorecase: false
+swap:
+  '\betc\.': "and more"
+  '\bdapp\b': dApp
+  '\bDApp\b': dApp
+  '\btestnet\b': TestNet
+  '\btest net\b': TestNet
+  '\bmainnet\b': MainNet
+  '\bmain net\b': MainNet
+  '\bERC(\d+)\b': "ERC-$1"
+  '\bJSON RPC\b': JSON-RPC
+  '\bJSONRPC\b': JSON-RPC
diff --git a/styles/config/vocabularies/PaperMoon/accept.txt b/styles/config/vocabularies/PaperMoon/accept.txt
new file mode 100644
index 0000000..18a4349
--- /dev/null
+++ b/styles/config/vocabularies/PaperMoon/accept.txt
@@ -0,0 +1,28 @@
+dApp
+dApps
+TestNet
+TestNets
+MainNet
+MainNets
+PaperMoon
+JSON-RPC
+Web3
+EVM
+WASM
+testnet
+mainnet
+repo
+repos
+repository
+repositories
+markdownlint
+MkDocs
+mkdocs
+devcontainer
+runnable
+hyperlink
+hyperlinks
+backslash
+kebab
+linter
+lintable