Markdown Writer
When to Load Standards
Before writing or editing any Markdown file, eagerly find and read project-specific sources.
Do not assume generic Markdown rules; project conventions and lint config must drive formatting.
Find and Read Documentation Standards
Look for and read (in order of priority):
- Doc-standards directories:
docs/docs_standards/, docs_standards/, .cursor/ (rules or docs)
- Index files:
docs/docs_standards/README.md, docs/README.md (for links to conventions)
- Convention docs: Any file named like
markdown_conventions.md, MARKDOWN.md, or referenced from the index
- Project meta:
meta.md, ai_files/ai_coding_instructions.md, CONTRIBUTING.md (for doc/lint mentions)
Read the main convention doc(s) so headings, line length, one-sentence-per-line, tables, and heading numbering follow the project.
Find and Read Markdownlint Config
Look for and read the first existing config in the repo root (or current doc tree):
.markdownlint.yml or .markdownlint.yaml
.markdownlint.json or .markdownlint.jsonc
.markdownlint-cli2.jsonc (may extend another file; follow the chain)
Use the config to align with line length (e.g. MD013), list style (e.g. MD004), code block style (e.g. MD046), and any custom rule names (e.g. no-h1-content, one-sentence-per-line).
If a rule is disabled or configured, respect that in the written output.
Apply When Writing or Editing
- Headings: Match required depth, numbering, uniqueness, and title-case rules from the standards and lint.
- Structure: Respect TOC placement (e.g. only under H1, no content between H1 and first H2), no empty headings, no H1 content except TOC where required.
- Prose: One sentence per line if enforced; line length within configured limits.
- Lists/code: List style (dash vs asterisk), fenced vs indented code blocks, and list/code spacing as specified.
- Links: Prefer Markdown links for in-repo paths; follow any anchor or ID patterns from the config (e.g.
allow-custom-anchors).
- Traces To sections (tech specs): "Traces To" subsections MUST be the last subsection under their parent Spec Item heading and MUST contain only a list of requirement links (no prose).
- Tables: Use only if allowed; otherwise use lists or sections per conventions.
After Editing
- If the project uses a lint command (e.g.
just lint-md, npx markdownlint-cli2 --fix), suggest or run it for the changed file(s) and fix reported issues.
Quick Checklist
1---2name: markdown-writer3description: Applies project documentation standards and markdownlint rules when writing or editing Markdown. Use this skill when creating or editing any Markdown file.4---5# Markdown Writer67## When to Load Standards89Before writing or editing any Markdown file, **eagerly** find and read project-specific sources.10Do not assume generic Markdown rules; project conventions and lint config must drive formatting.1112## Find and Read Documentation Standards1314Look for and read (in order of priority):1516- **Doc-standards directories**: `docs/docs_standards/`, `docs_standards/`, `.cursor/` (rules or docs)17- **Index files**: `docs/docs_standards/README.md`, `docs/README.md` (for links to conventions)18- **Convention docs**: Any file named like `markdown_conventions.md`, `MARKDOWN.md`, or referenced from the index19- **Project meta**: `meta.md`, `ai_files/ai_coding_instructions.md`, `CONTRIBUTING.md` (for doc/lint mentions)2021Read the main convention doc(s) so headings, line length, one-sentence-per-line, tables, and heading numbering follow the project.2223## Find and Read Markdownlint Config2425Look for and read the **first existing** config in the repo root (or current doc tree):2627- `.markdownlint.yml` or `.markdownlint.yaml`28- `.markdownlint.json` or `.markdownlint.jsonc`29- `.markdownlint-cli2.jsonc` (may `extend` another file; follow the chain)3031Use the config to align with line length (e.g. MD013), list style (e.g. MD004), code block style (e.g. MD046), and any custom rule names (e.g. `no-h1-content`, `one-sentence-per-line`).32If a rule is disabled or configured, respect that in the written output.3334## Apply When Writing or Editing3536- **Headings**: Match required depth, numbering, uniqueness, and title-case rules from the standards and lint.37- **Structure**: Respect TOC placement (e.g. only under H1, no content between H1 and first H2), no empty headings, no H1 content except TOC where required.38- **Prose**: One sentence per line if enforced; line length within configured limits.39- **Lists/code**: List style (dash vs asterisk), fenced vs indented code blocks, and list/code spacing as specified.40- **Links**: Prefer Markdown links for in-repo paths; follow any anchor or ID patterns from the config (e.g. `allow-custom-anchors`).41- **Traces To sections** (tech specs): "Traces To" subsections MUST be the **last** subsection under their parent Spec Item heading and MUST contain **only** a list of requirement links (no prose).42- **Tables**: Use only if allowed; otherwise use lists or sections per conventions.4344## After Editing4546- If the project uses a lint command (e.g. `just lint-md`, `npx markdownlint-cli2 --fix`), suggest or run it for the changed file(s) and fix reported issues.4748## Quick Checklist4950- [ ] Read doc standards from the repo (docs_standards, README, meta, CONTRIBUTING).51- [ ] Read markdownlint config (.markdownlint.yml or equivalent).52- [ ] Apply conventions and config while writing or editing.53- [ ] Run or suggest project lint command and fix any violations.