How do I install the Manage Markdown Docs skill?

Run npx skillmds@latest add tomevault-io/manage-markdown-docs in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Manage Markdown Docs safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Manage Markdown Docs?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Manage Markdown Docs free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Manage Markdown Docs?

tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Manage Markdown Docs by tomevault-io

Name: Manage Markdown Docs
Author: tomevault-io

Manage Markdown Docs

Standardize markdown document creation and updates with proper headers and footers. Use when creating OR updating any markdown file that is NOT a subagent, command, or skill definition. Ensures consistent metadata, classification, and change tracking. Use when this capability is needed.

tomevault-io b6ab5b4 2 files · 7.5 KB Updated Sep 17, 2026

File contents

Diagrams:

All diagrams MUST use Mermaid format
Use fenced code blocks with mermaid language identifier
Supported diagram types: flowchart, sequence, class, state, ER, gantt, pie, mindmap

Example:

flowchart TD
    A[Start] --> B{Decision}
    B -->|Yes| C[Action]
    B -->|No| D[End]

If NO path provided, determine based on document type and project structure.

---
document: [Document Name]
created: [YYYY-MM-DD HH:MM]
classification: [external-research | internal-analysis | contextual | other]
---

**Purpose**: [What this document is for]
**Author**: [Who created it - can be "Claude" or user name]
**Context**: [Why this document was created - what prompted it]

---

---

## Change History

| Date | Change | Author |
|------|--------|--------|
| [YYYY-MM-DD] | Initial creation | [Author] |

Example after updates:

## Change History

| Date | Change | Author |
|------|--------|--------|
| 2024-03-15 | Added section on error handling | Claude |
| 2024-03-14 | Expanded API examples | User |
| 2024-03-14 | Initial creation | Claude |

Purpose: Document the current authentication flow and identify potential improvements Author: Claude Context: User requested security review of login system

[Document content goes here...]

Change History

Date	Change	Author
2024-03-14	Initial creation	Claude

</complete_example>

<success_criteria>
Document is correctly structured when:
- Header contains all required fields (document, created, classification)
- Purpose, Author, and Context are clearly stated
- Classification matches document content
- Footer has Change History table
- Change History is updated after every modification
- Path respects user-provided location or follows classification-based suggestion
- Markdown is lint-free (proper spacing, heading levels, code fences)
- Any diagrams use Mermaid format
</success_criteria>

<anti_patterns>
<avoid>
- Creating documents without headers
- Skipping change history updates
- Overriding user-specified paths
- Applying this to subagents, commands, or skills
- Using vague document names like "Notes" or "Document"
- Leaving Purpose/Author/Context empty
- Producing markdown with lint errors (missing blank lines, skipped heading levels)
- Using ASCII art, PlantUML, or other diagram formats instead of Mermaid
- Code fences without language specifiers
</avoid>
</anti_patterns>

---
> Converted and distributed by [TomeVault](https://tomevault.io/claim/rayk) — claim your Tome and manage your conversions.
<!-- tomevault:4.0:skill_md:2026-04-13 -->

---name: manage-markdown-docsdescription: Standardize markdown document creation and updates with proper headers and footers. Use when creating OR updating any markdown file that is NOT a subagent, command, or skill definition. Ensures consistent metadata, classification, and change tracking. Use when this capability is needed.---<objective>Ensure all markdown documents have consistent structure with proper header metadata and footer change history. Standardizes documentation across projects regardless of type (workspace, monorepo, ontology, etc.).</objective><scope><applies_to>- Research notes and findings- Analysis reports- Context documents- Design documents- Meeting notes- Technical documentation- Any general-purpose markdown file</applies_to><does_not_apply_to>- Subagent definitions (agents/*.md)- Slash commands (commands/*.md)- Skills (SKILL.md files)- README.md files (these have their own conventions)- CLAUDE.md files- CHANGELOG.md files</does_not_apply_to></scope><quick_start><workflow_new_document>When CREATING a new markdown file:1. Check if document type is excluded (subagent, command, skill) → MUST stop if excluded2. If path provided by user, use it; otherwise determine appropriate location3. Classify document type4. Generate header with required metadata5. Write document content6. Add footer with change history (initial creation entry)</workflow_new_document><workflow_update_document>When UPDATING an existing markdown file:1. Check if document type is excluded (subagent, command, skill) → MUST stop if excluded2. If document lacks proper header/footer, add them3. Make the requested content changes4. Update the Change History table in footer with new entry</workflow_update_document><quality_requirements>**Markdown Lint Compliance**:- All produced markdown must be free from lint errors- Use consistent heading levels (no skipping levels)- Blank lines before and after headings, code blocks, and lists- No trailing whitespace- Single blank line at end of file- Properly closed code fences with language specifier**Diagrams**:- All diagrams MUST use Mermaid format- Use fenced code blocks with `mermaid` language identifier- Supported diagram types: flowchart, sequence, class, state, ER, gantt, pie, mindmapExample:```mermaidflowchart TD A[Start] --> B{Decision} B -->|Yes| C[Action] B -->|No| D[End]```</quality_requirements><path_behavior>If user provides a specific file path:- MUST use that path exactly- NEVER suggest alternatives- NEVER question the locationIf NO path provided, determine based on document type and project structure.</path_behavior></quick_start><document_classification>Classify every document into ONE of these categories:<category name="external-research">**External Research Finding**- Information gathered from outside sources- Web research, API documentation, third-party analysis- Competitor analysis, market research- Directory suggestion: `research/` or `docs/research/`</category><category name="internal-analysis">**Internal Analysis Report**- Analysis of internal systems, code, or processes- Performance reports, architecture reviews- Code quality assessments, technical debt analysis- Directory suggestion: `analysis/` or `docs/analysis/`</category><category name="contextual">**Contextual Document**- Background information for ongoing work- Project context, decision rationale- Historical context, migration notes- Directory suggestion: `context/` or `docs/context/`</category><category name="other">**Other**- Documents that don't fit above categories- Meeting notes, scratch documents, miscellaneous- Directory suggestion: `docs/` or project root</category></document_classification><header_template>Every document MUST start with this header structure:```markdown---document: [Document Name]created: [YYYY-MM-DD HH:MM]classification: [external-research | internal-analysis | contextual | other]---**Purpose**: [What this document is for]**Author**: [Who created it - can be "Claude" or user name]**Context**: [Why this document was created - what prompted it]---```<field_guidance>- **document**: Clear, descriptive name (not the filename)- **created**: Current date and time when document is first created- **classification**: One of the four categories above- **Purpose**: 1-2 sentences on what the document achieves- **Author**: Who or what produced this document- **Context**: The triggering event or need that led to creation</field_guidance></header_template><footer_template>Every document MUST end with this footer structure:```markdown---## Change History| Date | Change | Author ||------|--------|--------|| [YYYY-MM-DD] | Initial creation | [Author] |```<update_behavior>After EVERY modification to the document:1. Add a new row to the Change History table2. Include date, brief description of change, and who made it3. Keep entries in reverse chronological order (newest first)Example after updates:```markdown## Change History| Date | Change | Author ||------|--------|--------|| 2024-03-15 | Added section on error handling | Claude || 2024-03-14 | Expanded API examples | User || 2024-03-14 | Initial creation | Claude |```</update_behavior></footer_template><complete_example>```markdown---document: Authentication Flow Analysiscreated: 2024-03-14 09:30classification: internal-analysis---**Purpose**: Document the current authentication flow and identify potential improvements**Author**: Claude**Context**: User requested security review of login system---[Document content goes here...]---## Change History| Date | Change | Author ||------|--------|--------|| 2024-03-14 | Initial creation | Claude |```</complete_example><success_criteria>Document is correctly structured when:- Header contains all required fields (document, created, classification)- Purpose, Author, and Context are clearly stated- Classification matches document content- Footer has Change History table- Change History is updated after every modification- Path respects user-provided location or follows classification-based suggestion- Markdown is lint-free (proper spacing, heading levels, code fences)- Any diagrams use Mermaid format</success_criteria><anti_patterns><avoid>- Creating documents without headers- Skipping change history updates- Overriding user-specified paths- Applying this to subagents, commands, or skills- Using vague document names like "Notes" or "Document"- Leaving Purpose/Author/Context empty- Producing markdown with lint errors (missing blank lines, skipped heading levels)- Using ASCII art, PlantUML, or other diagram formats instead of Mermaid- Code fences without language specifiers</avoid></anti_patterns>---> Converted and distributed by [TomeVault](https://tomevault.io/claim/rayk) — claim your Tome and manage your conversions.

Frequently asked questions