markdown-doc-style
Skill0 starsChanged 17 days agoMITView on GitHub
Apply when creating, editing, or reviewing Markdown and similar document source text; keep prose paragraphs on one physical line while preserving Markdown- and format-required line breaks. Do not use for rendered layout, project writing policy, or code formatting alone.
In this repository12 other files it gives its agents.
- AGENTS.mdAGENTS.md
- buzzer-audio-previewSkill
- cvm-imagegenSkill
- docs-no-revision-markersSkill
- dst-dedicated-serverSkill
- firmware-display-previewSkill
- git-remote-troubleshootSkill
- git-syncSkill
- linux-server-initSkill
- step-stl-print-repairSkill
- tavily-hikari-infraSkill
- xp-infraSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Keep each ordinary prose paragraph on one physical line.
- Very specific: line 16
Do not insert mechanical line breaks inside a semantic unit.
- Distinctive: line 31
Do not use an exception to justify arbitrary wrapping.
- Distinctive: line 66
Leave headings, lists, tables, quotes, code, frontmatter, definitions, and intentional hard breaks structurally intact.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill 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
Markdown document style
Purpose and scope
Use this Skill for Markdown documents, document fragments, README files, specifications, guides, Skill files, and similar source-text artifacts. It governs source layout only: keep semantic units easy to diff and preserve the syntax needed to render them correctly. It does not decide what the document should say, which project conventions apply, how a renderer lays out a page, or how code should be formatted.
Core contract
- Keep each ordinary prose paragraph on one physical line.
- Separate adjacent prose paragraphs with one blank line.
- Do not insert mechanical line breaks inside a semantic unit. Do not wrap to a fixed column or to a formatter's
lineWidthsetting. - Preserve line breaks that express Markdown structure, syntax, or an intentional rendered break.
- Reflow only the affected prose paragraph when editing; do not reformat unrelated blocks just because they are nearby.
What counts as an exception
The one-line rule applies to ordinary prose paragraphs. Keep these structures on the lines their syntax requires:
- Headings, list items, nested list structure, and continuation lines whose indentation carries meaning.
- Tables, where each row and delimiter must remain a separate line.
- Block quotes, where each quoted line needs its quote marker or introduces another block. Within a quoted prose paragraph, do not add width-based wrapping.
- Fenced code blocks, indented code blocks, YAML frontmatter, directives, raw HTML, and other structured blocks whose grammar is line-oriented.
- Reference definitions, footnotes, task-list markers, and deliberate hard breaks such as two trailing spaces or
<br>when the break is part of the intended output. - A repository or document-format contract that explicitly requires wrapped prose. Follow that contract and treat the required wrapping as a local exception rather than inventing a second style.
Do not use an exception to justify arbitrary wrapping. A line break is allowed because it carries syntax or meaning, not because the line looks long.
Examples
Good
This is one ordinary paragraph even when its source line is longer than a typical editor guide would recommend.
This is a second paragraph, separated from the first by a blank line.
- Each list item starts on its own line.
- A long list item may continue on an indented line when the list structure requires it.
| Name | Meaning |
| --- | --- |
| `one-line` | A prose paragraph stays on one physical line. |Bad
This paragraph is wrapped only because the source line reached a preferred
column width, so the semantic unit is split across mechanical line breaks.
This paragraph is also wrapped by a formatter even though Markdown does not
require the break.The bad example should be reflowed into one physical line per paragraph. Do not apply that rewrite to a list, table, quote, code block, frontmatter block, or another structure listed as an exception.
Editing workflow
- Identify ordinary prose paragraphs and syntax-bearing blocks before changing line breaks.
- Join mechanically wrapped lines within each affected prose paragraph, keeping one blank line between paragraphs.
- Leave headings, lists, tables, quotes, code, frontmatter, definitions, and intentional hard breaks structurally intact.
- Inspect the diff for accidental content changes, lost blank lines, broken indentation, altered links, or newly introduced hard breaks.
Review checklist
- Every ordinary prose paragraph is one physical line.
- Adjacent paragraphs remain separated by a blank line.
- No mechanical wrapping follows a fixed column or
lineWidthvalue. - Headings, lists, tables, block quotes, code blocks, frontmatter, and other syntax-bearing blocks retain required line breaks.
- Intentional hard breaks remain intentional and are not introduced for visual width.
- Links, reference definitions, footnotes, indentation, and content meaning are unchanged unless the request requires them to change.
- The change does not add project engineering, technical-selection, CI, release, architecture, or business-copy rules to this source-layout Skill.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.

