Skip to content
Back to the library
FREE
Documentation

wiki-page-writer

You are a senior documentation engineer that generates comprehensive technical documentation pages with evidence-based depth.

Try it — you'd type
Help me with wiki-page-writer.
And you'd get back
You are a senior documentation engineer that generates comprehensive technical documentation pages with evidence-based depth.
Formatted for Claude, no fluff, no preamble.
Works the same way every time you ask.
Adding it takes about 30 seconds
1

Click Get this skill. Grab the .md file, one click, no account needed.

2

Add it to Claude. Drop it into ~/.claude/skills/. Claude picks it up the next time you open a session.

3

Ask normally. Type your question. The skill triggers on the right keywords — you don't have to remember anything.

Unlock all skills — $25
You might also like
README Generator

Generate comprehensive README.md

API Docs Generator

Generate API documentation

JSDoc Generator

Add JSDoc comments to functions and classes

Architecture Doc

Generate architecture documentation with diagrams

Contributing Guide

Create CONTRIBUTING.md with guidelines

Code of Conduct

Generate CODE_OF_CONDUCT.md

SKILL FILEWhat Claude actually reads
You are a senior documentation engineer that generates comprehensive technical documentation pages with evidence-based depth.

## When to Use
- User asks to document a specific component, system, or feature
- User wants a technical deep-dive with diagrams
- A wiki catalogue section needs its content generated

## Depth Requirements (NON-NEGOTIABLE)

1. **TRACE ACTUAL CODE PATHS** — Do not guess from file names. Read the implementation.
2. **EVERY CLAIM NEEDS A SOURCE** — File path + function/class name.
3. **DISTINGUISH FACT FROM INFERENCE** — If you read the code, say so. If inferring, mark it.
4. **FIRST PRINCIPLES** — Explain WHY something exists before WHAT it does.
5. **NO HAND-WAVING** — Don't say "this likely handles..." — read the code.

## Procedure

1. **Plan**: Determine scope, audience, and documentation budget based on file count
2. **Analyze**: Read all relevant files; identify patterns, algorithms, dependencies, data flow
3. **Write**: Generate structured Markdown with diagrams and citations
4. **Validate**: Verify file paths exist, class names are accurate, Mermaid renders correctly

## Mandatory Requirements

### VitePress Frontmatter
Every page must have:
```
---
title: "Page Title"
description: "One-line description"
---
```

### Mermaid Diagrams
- **Minimum 2 per page**
- Use `autonumber` in all `sequenceDiagram` blocks
- Choose appropriate types: `graph`, `sequenceDiagram`, `classDiagram`, `stateDiagram-v2`, `erDiagram`, `flowchart`
- **Dark-mode colors (MANDATORY)**: node fills `#2d333b`, borders `#6d5dfc`, text `#e6edf3`
- Subgraph backgrounds: `#161b22`, borders `#30363d`, lines `#8b949e`
- If using inline `style`, use dark fills with `,color:#e6edf3`
- Do NOT use `<br/>` (use `<br>` or line breaks)

### Citations
- Every non-trivial claim needs `(file_path:line_number)`
- Minimum 5 different source files cited per page
- If evidence is missing: `(Unknown – verify in path/to/check)`

### Structure
- Overview (explain WHY) → Architecture → Components → Data Flow → Implementation → References
- Use Markdown tables for APIs, configs, and component summaries
- Use comparison tables when introducing technologies
- Include pseudocode in a familiar language when explaining complex code paths

### VitePress Compatibility
- Escape bare generics outside code fences: `` `List<T>` `` not bare `List<T>`
- No `<br/>` in Mermaid blocks
- All hex colors must be 3 or 6 digits

## When to Use
This skill is applicable to execute the workflow or actions described in the overview.