| name | author-doc-page |
| description | Scaffold or draft a new docs.linea.build page to editorial standards. Use when creating a new page, writing a first draft, or helping a contributor who isn't a professional writer produce content that meets the documentation team's expectations. |
| metadata | {"short-description":"Scaffold and draft new docs.linea.build pages"} |
Author a docs.linea.build page
Help create a new documentation page that follows docs.linea.build's editorial standards
from the start.
When to use
- You need to scaffold a new page or write a first draft.
- You're helping a contributor who isn't a professional writer produce content that meets
the documentation team's expectations (for example, an ecosystem partner documenting
their integration).
Inputs
Ask the user for anything they haven't already provided:
- Tab: which tab is this for? (Linea Mainnet, Lineth Stack, Protocol, Reference,
Changelog)
- Content type: concept/explanation, how-to guide, reference, or tutorial?
- Topic: what is the page about?
- File path: where should the file live? Suggest one based on the tab and topic if
the user doesn't specify (see the directory table in
README.mdx).
- Source material: what code, spec, PR, or other reference verifies the content?
Step 1: Confirm an issue exists, then load the relevant rules
Per .cursor/rules/contributor-workflow.mdc, an issue should exist for this change
before work starts. Ask the user whether one's already open; if not, point them to
CONTRIBUTING.md and the templates in .github/ISSUE_TEMPLATE/
so they can open one before you invest time scaffolding and drafting. This matters most
for ecosystem/partner contributors.
Then read these rule files before scaffolding, and apply them by reference rather than
restating them in the draft:
.cursor/rules/contributor-workflow.mdc: issue-first workflow, redirects, PR hygiene..cursor/rules/content-structure.mdc: tab, audience, tone, and page-structure
conventions..cursor/rules/editorial-voice.mdc: voice, heading style, and the [VERIFY] marker
convention..cursor/rules/terminology.mdc: casing, Linea vs. Lineth naming, and component
capitalization..cursor/rules/markdown-formatting.mdc: frontmatter, links, and file conventions.
Also check how existing pages in the same folder are structured, and match their
conventions for headings, frontmatter fields, and intro style.
Step 2: Scaffold the page
Create the file with frontmatter (title, description; no image, see
markdown-formatting.mdc) and the structure from content-structure.mdc for the content
type: an opening (no heading), then content sections, then
verified code samples, then a resources section for links. How-to and tutorial pages use
numbered steps with prerequisites listed first instead.
Step 3: Write the content
Fill in the scaffold with content based on what the user provides:
- Identify the audience for this tab (
content-structure.mdc) and write for it.
- Define jargon on first use (
editorial-voice.mdc).
- Use the correct casing for Linea/Lineth, components, and roles
(
terminology.mdc). Check /protocol/linea-vs-lineth if you're unsure which product a
claim belongs to.
- Mark anything you can't verify with
[VERIFY] rather than guessing.
- No marketing language or superlatives ("best-in-class", "powerful", "seamless").
Step 4: Verify the page is complete
Before finishing, check:
Step 5: Remind the contributor
After creating the page, remind the user to:
- Add an entry to
redirects.json if any page was moved, renamed, or removed.
- Preview locally with
npm run start.
- Run
npm run lint and npm run typecheck before opening a PR.
- Link the issue from Step 1 in the pull request description (see
CONTRIBUTING.md).
