with one click
documentation
Use when creating docs, updating guides, writing API references, or reviewing documentation for Particle-Viewer.
Menu
Use when creating docs, updating guides, writing API references, or reviewing documentation for Particle-Viewer.
Use when adding new classes, refactoring code, or reviewing PRs for Particle-Viewer.
Use when a task needs design exploration before any implementation begins. Required for any task with unclear approach, significant architecture impact, or multiple valid solutions.
Use when building, adding dependencies, configuring CMake options, troubleshooting build failures, or managing Flatpak packaging for Particle-Viewer.
Use when writing or reviewing C++ code, running pre-commit checks, or addressing formatting, naming, or static analysis violations.
Use when writing tests for any interface, abstract base class, or type with multiple implementations.
Use when implementing C++ code for Particle-Viewer, handling GL resources, working with SDL3, or applying DRY/deprecation/docs-commit patterns.
| name | documentation |
| license | MIT |
| description | Use when creating docs, updating guides, writing API references, or reviewing documentation for Particle-Viewer. |
EVERY DOC IS SMALL, TAGGED, AND LINKED -- ONE CONCEPT PER FILE
YOU MUST keep every doc file under 600 words, include YAML frontmatter on every doc, and add a Related section at the bottom. No exceptions.
Violating the letter of this rule is violating the spirit of this rule.
Announce at start: "I am using the documentation skill to [write/update/review] [description]."
Before writing any documentation:
references/DOCUMENTATION_EXAMPLES.mddocs/<domain>/<subdomain>/ (not a flat root file unless it's a cross-cutting standard)[+] All 3 met -> proceed to write [-] Any unmet -> resolve before writing a single line
| Type | Location |
|---|---|
| API/class reference | Header file comments (<=5 lines inline; longer -> docs/) |
| Domain guides | docs/<domain>/<subdomain>/ -- one concept per file, <=600 words |
| Cross-cutting standards | docs/UPPERCASE.md |
| Agent skills | .github/skills/<name>/SKILL.md |
| Skill reference content | .github/skills/<name>/references/*.md |
| Agent onboarding | AGENTS.md -- summarize only |
Every docs/ file MUST begin with YAML frontmatter -- schema in references/DOCUMENTATION_EXAMPLES.md.
Required fields: title, description, domain, subdomain, tags, related.
description MUST be one concrete sentence that answers: what exactly does this file cover?tags MUST include domain and subdomain as the first two entriesrelated uses relative paths from the file's own directoryEvery doc file MUST end with a ## Related section with at least one annotated link.
All files in docs/ MUST be Document Mode -- readable independently, with no assumed conversational context. Thread Mode writing (responses that only make sense inside a conversation) belongs in chat, not in documentation. If a paragraph requires "as discussed above" or "in the previous message," it is Thread Mode. Rewrite it or cut it.
Update all 4 locations:
Skipping any location makes the skill effectively invisible. For templates and code examples for each update location, see references/DOCUMENTATION_EXAMPLES.md.
Before presenting documentation, verify:
## Related section is present at the bottom[+] All pass -> documentation is ready to present [-] Any unmet -> resolve all failing items before presenting
| Excuse | Reality |
|---|---|
| "I'll add frontmatter later" | Without frontmatter the doc is invisible to search. |
| "One big file is easier to navigate" | Large files produce poor retrieval chunks. Split at concepts. |
| "The related section is optional" | Without it, the retrieval graph has no edges. Link or the doc is isolated. |
| "I'll document it after it's working" | Documentation written separately from code drifts immediately. Write with the code. |
| "A long comment will do for now" | Comments >5 lines belong in docs/. Move it. |
| "I'll update the docs in a follow-up" | Follow-up docs never match the implementation. Update alongside the change. |
| "The skill already covers this" | Check for duplication -- if both a skill and a doc cover it, consolidate. |
## Related section -- STOP. Add at least one annotated link.writing-skills -- skill authoring standards, anatomy gate, and skill-reviewer dispatch pattern for validating completed skillsFor the domain taxonomy, frontmatter schema, and guide template, see references/DOCUMENTATION_EXAMPLES.md.
Documentation principles (Doc1-Doc5, SelfDocumentingCode, LiterateProgramming): references/DOCUMENTATION_PRINCIPLES.md