code-documentation
/code-documentation
Guide for writing effective code documentation, including docstrings, JSDoc, dartdoc, and implementation comments. Use this skill when writing new code, adding features, or improving existing documentation in Dart, Python, or TypeScript to ensure clarity and maintainability.
- Author
- flutter ↗
- Repository
- agent-plugins ↗
- Licence
- BSD-3-Clause
- Last repository change
- 21.10.2026
Assessment and security
- Files in this package
- 4
- Scripts
- 0
- HTML comments
- 0
- URLs in SKILL.md
- 0
No signals detected. Repository changed on 21.10.2026, without references to retired models or APIs.
BSD-3-Clause, otwarta.
What it does and when to use it
Guide for writing effective code documentation, including docstrings, JSDoc, dartdoc, and implementation comments. Use this skill when writing new code, adding features, or improving existing documentation in Dart, Python, or TypeScript to ensure clarity and maintainability.
Original author description
Guide for writing effective code documentation, including docstrings, JSDoc, dartdoc, and implementation comments. Use this skill when writing new code, adding features, or improving existing documentation in Dart, Python, or TypeScript to ensure clarity and maintainability.
How it works
- 1. General Philosophy
- 2. General Structure
- 3. Writing Guidelines
- 4. Implementation Comments
- 5. Review Checklist
- 6. Language Specific Instructions
SKILL.md preview
--- name: code-documentation description: Guide for writing effective code documentation, including docstrings, JSDoc, dartdoc, and implementation comments. Use this skill when writing new code, adding features, or improving existing documentation in Dart, Python, or TypeScript to ensure clarity and maintainability. --- # Code Documentation Skill This skill provides comprehensive guidelines for documenting code, prioritizing user-centric writing, clarity, and consistency. ## 1. General Philosophy - **User-Centric**: Write for the person using your API. If you had to look up how to use something, document it so others don't have to. - **Explain "Why"**: Explain _why_ code exists and _how_ to use it effectively, since the code signature already tells _what_ it does. - **Be Concise**: Omit fluff. Avoid merely restating the code name, as it is not helpful. - **Consistency**: Use standard terminology and consistent formatting. - **Public APIs**: Document all public APIs (classes, members, top-level functions) without exception. - **Code Samples**: Strongly consider adding code samples to explain usage. ## 2. General Structure Follow this general structure for documentation comments across languages: 1. **Summary Sentence**: Start with a single-sentence summary on the first line, ending with a period. 2. **Blank Line**: Follow the summary with a blank line. 3. **Details**: Add paragraphs, code samples, or lists as needed to explain parameters, return values, exceptions, and behavior. 4. **Annotations**: Place doc comments **before** any metadata annotations. ## 3. Writing Guidelines ### Brevity & Style - **Avoid Fluff**: Omit "This class...", "This method...", "Is used to...", "Note that...". - _Bad_: "This method is used to calculate the total." - _Good_: "Calculates the total." - **Third-Person Verbs**: Start function/method docs with a third-person singular verb. - _Examples_: "Returns...", "Calculates...", "Updates...", "Creates...". - **Noun Phrases**: Start variable/property docs with a noun phrase. - _Examples_: "The current color.", "A list of active users.". - **Booleans**: Always start with "Whether" (or similar clear indicator). - _Good_: "Whether this widget is enabled." - _Bad_: "If this widget is enabled...", "True if...", "Flag to indicate...". - **Avoid Jargon**: Use plain English unless the term is a widely accepted standard (e.g., "HTTP", "URL"). ### Formatting - **Sparingly**: Use Markdown features (bold, lists) sparingly. - **No HTML**: Avoid HTML unless strictly necessary and supported by the documentation tool. - **Parameters/Returns/Exceptions**: Use prose to describe parameters, return values, and thrown exceptions. Do not rely solely on tags like `@param` unless mandated by the language standard (e.g., Javadoc). ## 4. Implementation Comments Ensure implementation comments (`//`) are accurate, relevant, factual, and provide information that is not readily understandable from the code. Remove or reword comments that do not meet these criteria. If an implementation comment provides information useful to an API consumer that is not already in the documentation comments, move it to the documentation comments. ## 5. Review Checklist Use this checklist to verify your documentation: 1. [ ] **Summary**: Ensure every public member starts with a one-sentence summary ending in a period. 2. [ ] **Brevity**: Remove "This class..." or "This function..." fluff. 3. [ ] **Completeness**: Document strict constraints (e.g., "must not be null") and exceptions. 4. [ ] **Examples**: Consider adding a code sample for complex widgets or methods. ## 6. Language Specific Instructions Refer to the language guides for detailed instructions on structure, linking, and framework-specific patterns: - **Dart / Flutter**: [references/dart.md](references/dart.md) - **TypeScript / JavaScript**: [references/typescript.md](references/typescript.md) - **Python**: [references/python.md](references/python.md)
Files in this package (4)
- SKILL.md 4 KB
- references/dart.md 3 KB
- references/python.md 3 KB
- references/typescript.md 3 KB
Versions
| Repository | Score | Licence |
|---|---|---|
| This page · flutter/agent-plugins | 100 | BSD-3-Clause |
| bytedance/deer-flow | 100 | MIT |
| erikaax08/erikas-skills | 100 | Apache-2.0 |
| hoducvinhh/code-documentation | 100 | MIT |
| MoizIbnYousaf/ai-agent-skills | 100 | MIT |
| Amey-Thakur/AI-SKILLS | 100 | MIT |
| seb1n/awesome-ai-agent-skills | 100 | MIT |
Database snapshot: 13.11.2026 · package version 10dfea8ddde9 (SHA-256 digest of the entire package)
Downloads in the last 30 days: 0 · ranking
Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.
Similar skills
- 100document-code
Apply Google Style documentation standards to Python, Go, TypeScript, and Terraform code. Use when writing or reviewing code that needs docstrings/comments/JSDoc, when asked to "document this code", "add docstrings", "follow Google Style", or when improving code documentation… - 100documentation-generation
Generates project documentation including READMEs, docstrings (JSDoc, JavaDoc, Python docstrings), OpenAPI prose, and CI/CD doc pipelines. Use when asked to generate docs, write docstrings, automate documentation, or create README files. - 100documentation
In-code documentation, folder READMEs, code comments. Use when: "document this", "add JSDoc", "write a README", "explain this code", or writing README.md/JSDoc. - 100jsdoc
JSDoc - documentation generator for JavaScript with type annotations. USE WHEN: user mentions "JSDoc", "JavaScript documentation", asks about "documenting JavaScript", "type hints", "jsdoc comments", "API documentation generation" DO NOT USE FOR: TypeScript - use `jsdoc-tsdoc`… - 100dart-write-documentation
Rules and formatting guidelines for writing Dart /// API documentation and doc comments. Use when documenting Dart code, writing doc comments for any Dart declaration (libraries, classes, methods, variables, etc.), or when instructed to follow the Effective Dart documentation guidelines. - 100documentation
Generate docstrings, JSDoc, API docs, and README updates that reflect current code. Use when: docs, docstring, JSDoc, README, API docs, document this, add documentation.