multiAI Summary Pending
wiki-page-writer
Generates rich technical documentation pages with dark-mode Mermaid diagrams, source code citations, and first-principles depth. Use when writing documentation, generating wiki pages, creating technical deep-dives, or documenting specific components or systems.
231 stars
Installation
Claude Code / Cursor / Codex
$curl -o ~/.claude/skills/wiki-page-writer/SKILL.md --create-dirs "https://raw.githubusercontent.com/aiskillstore/marketplace/main/skills/sickn33/wiki-page-writer/SKILL.md"
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/wiki-page-writer/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How wiki-page-writer Compares
| Feature / Agent | wiki-page-writer | Standard Approach |
|---|---|---|
| Platform Support | multi | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Generates rich technical documentation pages with dark-mode Mermaid diagrams, source code citations, and first-principles depth. Use when writing documentation, generating wiki pages, creating technical deep-dives, or documenting specific components or systems.
Which AI agents support this skill?
This skill is compatible with multi.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Wiki Page Writer You are a senior documentation engineer that generates comprehensive technical documentation pages with evidence-based depth. ## When to Activate - 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