How do I install the Common Documentation skill?

Run npx skillmds@latest add comeonoliver/common-documentation 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 Common Documentation safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Common Documentation?

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 Common Documentation free to use?

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

Who published Common Documentation?

ComeOnOliver (@comeonoliver) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Common Documentation by comeonoliver

Name: Common Documentation
Rating: 4.2 (5 reviews)
Author: ComeOnOliver

Common Documentation

Essential rules for code comments, READMEs, and technical docs. Use when adding comments, writing docstrings, creating READMEs, or updating any documentation. (triggers: comment, docstring, readme, documentation)

ComeOnOliver Updated Sep 8, 2026 61 repo stars

File contents

Documentation Standards

Priority: P2 (MAINTENANCE)

📝 Code Comments (Inline Docs)

"Why" over "What": Comments should explain non-obvious intent. Code should describe the logic.
Docstrings: Use triple-slash (Dart/Swift) or standard JSDoc (TS/JS) for all public functions and classes.
Maintenance: Delete "commented-out" code immediately; use Git history for retrieval.
TODOs: Use TODO(username): description or FIXME to track technical debt with ownership.
Workarounds: Document hacks and removal conditions (e.g., backend bug, version target).
Performance Notes: Explain trade-offs only when performance-driven changes are made.

📖 README Essentials

Mission: Clear one-sentence summary of the project purpose.
Onboarding: Provide exact Prerequisites (runtimes), Installation steps, and Usage examples.
Maintainability: Document inputs/outputs, known quirks, and troubleshooting tips.
Up-to-Date: Documentation is part of the feature; keep it synchronized with code changes.

🏛 Architectural & API Docs

ADRs: Document significant architectural changes and the "Why" in docs/adr/.
Docstrings: Document Classes and Functions with clear descriptions of Args, Returns, and usage Examples (>>>).
Diagrams: Use Mermaid.js inside Markdown to provide high-level system overviews.

🚀 API Documentation

Self-Documenting: Use Swagger/OpenAPI for REST or specialized doc generators for your language.
Examples: Provide copy-pasteable examples for every major endpoint or utility.
Contract First: Define the interface before the implementation.

Anti-Patterns

No "what" comments: Explain intent, not mechanics. Refactor instead.
No orphan TODOs: Every TODO needs (owner) and a linked ticket.
No out-of-date docs: Documentation ships with the feature, not after.

---name: common-documentationdescription: Essential rules for code comments, READMEs, and technical docs. Use when adding comments, writing docstrings, creating READMEs, or updating any documentation. (triggers: comment, docstring, readme, documentation)---# Documentation Standards## **Priority: P2 (MAINTENANCE)**## 📝 Code Comments (Inline Docs)- **"Why" over "What"**: Comments should explain non-obvious intent. Code should describe the logic.- **Docstrings**: Use triple-slash (Dart/Swift) or standard JSDoc (TS/JS) for all public functions and classes.- **Maintenance**: Delete "commented-out" code immediately; use Git history for retrieval.- **TODOs**: Use `TODO(username): description` or `FIXME` to track technical debt with ownership.- **Workarounds**: Document hacks and removal conditions (e.g., backend bug, version target).- **Performance Notes**: Explain trade-offs only when performance-driven changes are made.## 📖 README Essentials- **Mission**: Clear one-sentence summary of the project purpose.- **Onboarding**: Provide exact Prerequisites (runtimes), Installation steps, and Usage examples.- **Maintainability**: Document inputs/outputs, known quirks, and troubleshooting tips.- **Up-to-Date**: Documentation is part of the feature; keep it synchronized with code changes.## 🏛 Architectural & API Docs- **ADRs**: Document significant architectural changes and the "Why" in `docs/adr/`.- **Docstrings**: Document Classes and Functions with clear descriptions of Args, Returns, and usage Examples (`>>>`).- **Diagrams**: Use Mermaid.js inside Markdown to provide high-level system overviews.## 🚀 API Documentation- **Self-Documenting**: Use Swagger/OpenAPI for REST or specialized doc generators for your language.- **Examples**: Provide copy-pasteable examples for every major endpoint or utility.- **Contract First**: Define the interface before the implementation.## Anti-Patterns- **No "what" comments**: Explain intent, not mechanics. Refactor instead.- **No orphan TODOs**: Every TODO needs `(owner)` and a linked ticket.- **No out-of-date docs**: Documentation ships with the feature, not after.

Frequently asked questions