agent writing skill risk: low

Technical Wiki Documentation Page Writer

Instructs the model to generate VitePress-compatible Markdown wiki pages for software components by tracing actual code paths, creating at least two dark-mode Mermaid diagrams per…

SKILL 1 file

SKILL.md

Download

---
name: antigravity-awesome-skills-wiki-page-writer
description: "You are a senior documentation engineer that generates comprehensive technical documentation pages with evidence-based depth."
---
# Wiki Page Writer

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 ` ` (use ` ` 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 ` ` 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.

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

REQUIRED CONTEXT

source code files or component/system to document

OPTIONAL CONTEXT

audience
documentation budget
file count

ROLES & RULES

Role assignments

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

TRACE ACTUAL CODE PATHS — Do not guess from file names. Read the implementation.
EVERY CLAIM NEEDS A SOURCE — File path + function/class name.
DISTINGUISH FACT FROM INFERENCE — If you read the code, say so. If inferring, mark it.
FIRST PRINCIPLES — Explain WHY something exists before WHAT it does.
NO HAND-WAVING — Don't say "this likely handles..." — read the code.
Every page must have VitePress Frontmatter with title and description.
Include minimum 2 Mermaid diagrams per page.
Use autonumber in all sequenceDiagram blocks.
Use dark-mode colors for Mermaid: node fills #2d333b, borders #6d5dfc, text #e6edf3.
Use subgraph backgrounds #161b22, borders #30363d, lines #8b949e.
Do NOT use in Mermaid blocks.
Every non-trivial claim needs (file_path:line_number) citation.
Cite minimum 5 different source files per page.
Follow structure: Overview (explain WHY) → Architecture → Components → Data Flow → Implementation → References.
Use Markdown tables for APIs, configs, and component summaries.
Escape bare generics outside code fences.
All hex colors must be 3 or 6 digits.
Use this skill only when the task clearly matches the scope described above.
Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

EXPECTED OUTPUT

Format

markdown

Schema

markdown_with_frontmatter · VitePress Frontmatter, Overview, Architecture, Components, Data Flow, Implementation, References, Mermaid diagrams, Citations

Constraints

include VitePress frontmatter with title and description
minimum 2 Mermaid diagrams per page with dark-mode colors and autonumber on sequenceDiagrams
minimum 5 source file citations with line numbers
follow exact section structure: Overview, Architecture, Components, Data Flow, Implementation, References
use Markdown tables for APIs/configs/summaries
escape generics and avoid in Mermaid

SUCCESS CRITERIA

Generate comprehensive technical documentation pages with evidence-based depth.
Read actual implementation and cite sources.
Include required frontmatter, diagrams, and citations.
Follow mandatory structure and VitePress compatibility rules.

FAILURE MODES

Guessing from file names instead of reading code.
Missing required citations or source files.
Invalid Mermaid syntax or colors.
Omitting WHY explanation or using hand-waving language.

CAVEATS

Dependencies

Requires relevant source code files to read and analyze.

Missing context

Target audience level (e.g., junior vs senior engineers)
Preferred output length or page count guidance
Language or framework assumptions for pseudocode

Ambiguities

Duplicate 'When to Use' section with conflicting content
'documentation budget' is undefined
Second 'When to Use' bullet is circular/vague

QUALITY

OVERALL: 0.81
CLARITY: 0.82
SPECIFICITY: 0.88
REUSABILITY: 0.78
COMPLETENESS: 0.75

IMPROVEMENT SUGGESTIONS

Remove the duplicate 'When to Use' section and keep only the first bullet list
Define or remove the term 'documentation budget' in the Plan step
Add a short 'Example Output' section showing frontmatter + one diagram + one citation

USAGE

Copy the prompt above and paste it into your AI of choice — Claude, ChatGPT, Gemini, or anywhere else you're working. Replace any placeholder sections with your own context, then ask for the output.