Markdown formatting mastery
Skill meyverick/agy-skills/skills/markdown-formatting-mastery
Enforces strict, standardized Markdown formatting. Use when writing documentation, generating reports, formatting code blocks, or creating wikis.From its SKILL.md
npx -y skills add meyverick/agy-skills --skill markdown-formatting-masteryAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.3 KB, 503 tokens by cl100k_base, as published. Nobody here has run it
Markdown Formatting Mastery
This skill strictly enforces standard GitHub Flavored Markdown (GFM) formatting rules. It guarantees consistency across all generated artifacts, wikis, and system documentation.
When to Use
- Use when authoring or modifying
.mdfiles. - Use when generating reports, readmes, or artifact summaries.
- Use when structuring complex tables or technical data.
Core Process
Phase 1: Document Structure & Hierarchy
- Maintain a strict heading hierarchy. Never skip heading levels (e.g., don't jump from
H1toH3). - Only use a single
# H1at the very top of the document.
Phase 2: Lists & Syntax
- Use the hyphen
-for unordered lists. Do not use*. - Ensure standard spacing: One blank line above and below all lists, code blocks, and blockquotes.
Phase 3: Code Formatting
- Always specify the language identifier for fenced code blocks (e.g.,
```typescriptor```bash). - Do not use
>blockquotes for code. Use fenced backticks. - Link to specific files using valid markdown URI schema
[name](file:///path).
Phase 4: Tabular Data
- Use standard GFM tables to present multi-dimensional data.
- Ensure columns are aligned logically to improve raw-text readability.
Common Rationalizations
| Rationalization | Reality |
|---|---|
| "I'll just paste this code as raw text." | Code without fenced syntax highlighting is difficult for humans to read. Language identifiers are mandatory. |
"I'll use * for lists because it's easier." | * can conflict with bolding syntax or cause inconsistent rendering in some parsers. Always standardize on -. |
Red Flags
- Fenced code blocks lacking language tags (e.g., just
```instead of```json). - Skipped heading levels or multiple
H1tags in a single document. - Dense walls of text instead of chunked, easily scannable sections.
Verification
Before saving the markdown document, verify:
- The document strictly adheres to heading hierarchy.
- All lists use hyphens (
-). - Every code block possesses a correct language identifier.
- Links and URIs are correctly formatted without breaking backticks.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.