| name | code-commentator |
| description | Code annotation supplementation and standardization expert. Automatically identifies code file types and adds professional bilingual comments for functions, classes, methods, properties, and other code elements. Activate when user mentions "add comments", "supplement comments", "standardize comments", "code comments", "annotate code", "add comments", or needs documentation comments for code. This skill can also be automatically invoked by other skills (such as executing-plans) after code is completed. |
| license | MIT |
| metadata | {"version":"1.2.0"} |
Code Commentator Skill
This skill provides systematic code comment supplementation and standardization capabilities. It automatically identifies code file types, applies corresponding comment standards, and ensures generated comments are accurate, complete, and meet bilingual requirements.
Trigger Conditions
Activate this skill when detecting the following situations:
Direct User Invocation:
- User mentions adding or supplementing comments: "add comments", "supplement comments", "increase comments"
- User mentions standardizing comments: "standardize comments", "unify comment style", "comment standards"
- User mentions code comment needs: "add comments to code", "code lacks comments", "incomplete comments"
- User mentions specific comment types: "function comments", "class comments", "JSDoc", "docstring"
- English triggers: "add comments", "annotate code", "code documentation", "JSDoc"
Automatic Invocation by Other Skills:
executing-plans skill automatically invokes after task completion (if code needs comments)
- In automated workflow after tests pass and before code submission
Invocation by Other Skills
When invoked by executing-plans or other skills:
Received Parameters:
target_files: List of file paths requiring comments (required)
comment_priority: Comment priority (optional: high/medium/low)
focus_areas: Key comment areas (optional: e.g., "public APIs", "core logic")
Execution Mode:
- Skip user confirmation, execute directly
- Use default bilingual comment format
- Automatically identify code complexity, add comments intelligently
- Return processing result summary after completion
Absolute Prohibitions ⚠️
Modifying any code content is strictly prohibited. This skill can only add or modify comments, it must NOT:
- ❌ Modify code logic
- ❌ Modify variable names, function names, class names, or other identifiers
- ❌ Modify code structure (adding, deleting, reordering code lines)
- ❌ Modify code formatting (indentation, line breaks, spaces)
Only Permitted Action: Add comments to code or modify existing comments.
Bilingual Comment Requirements
All comments must include both English and Chinese bilingual explanations, in this format:
- English description first
- Blank line separator
- Chinese description following
Comment Format Reference
Detailed multilingual comment format examples have been moved to the references directory:
Important: Before adding comments, read comment-formats.md to ensure correct language format is used.
Core Comment Principles
Elements That Must Have Multi-line Comments
The following code elements must have multi-line documentation comments:
- ✅ Functions/Methods
- ✅ Classes/Structs/Interfaces
- ✅ Public properties/Fields
- ✅ Enums and their members
- ✅ Type definitions
- ✅ Modules/Namespaces
Elements That Need Evaluation
Add single-line comments only when code logic is not intuitive enough:
- ⚠️ Complex conditional branching logic
- ⚠️ Complex loop structures
- ⚠️ Complex expressions
- ⚠️ Important variable declarations (when purpose is unclear)
Elements That Don't Need Comments
Code is already clear enough, no comments needed:
- ❌ Simple conditionals (e.g.,
if (isValid))
- ❌ Simple loops (e.g.,
for (const item of items))
- ❌ Variable declarations where names clearly express purpose (e.g.,
const userName = user.name)
- ❌ Standard getter/setter methods
- ❌ Obvious assignment statements
Judgment Criteria
Before adding comments, ask yourself:
- Can I quickly understand this code's intent without reading comments?
- Are the code names clear enough?
- Do comments provide information that the code itself cannot express?
If the answers indicate the code is already clear enough, no comments are needed.
Comment Insertion Rules
| Element Type | Insertion Position | Requirements |
|---|
| Function/Method Comments | Immediately above function declaration | No blank line |
| Class Comments | Immediately above class declaration | No blank line |
| Property Comments | Immediately above property declaration | No blank line |
| Single-line Comments | Above code line | Maintain same indentation as code |
Function/Method Comment Requirements
Function/Method comments must include:
- Function Description: Clear description of function's functionality and purpose
- Parameter Description: Type and purpose of each parameter
- Return Value Description: Type and meaning of return value
- Exception Description: Possible exceptions and conditions (if any)
- Usage Examples: At least one basic usage example
Union Type Parameters
When a parameter is a union type, must describe each type in detail:
@param input - The input data to process. Can be:
- `string`: A string value to parse / 要解析的字符串值
- `Buffer`: A buffer containing raw data / 包含原始数据的缓冲区
- `ReadableStream`: A stream to read data from / 要读取数据的流
Multiple Parameter Passing Ways
When supporting multiple parameter passing ways, provide different scenario usage examples:
@example
const user = createUser('John');
const user = createUser({ name: 'John', age: 25, email: 'john@example.com' });
Execution Flow
File Scanning Flow
- Receive user-specified files or directories
- Recursively scan all code files
- Group by language type for processing
- Generate processing plan
Single File Processing Flow
- Read file content
- Parse code structure (AST or regex matching)
- Identify code elements needing comments
- Check completeness of existing comments
- Generate comments conforming to standards
- Insert comments to correct positions
- Write updated file
Progress Report Format
Report progress in real-time during processing:
## Comment Processing Progress
### Completed (3/10)
- ✅ src/utils/helper.ts (added 5 function comments)
- ✅ src/models/user.ts (added 2 class comments, 8 property comments)
- ✅ src/api/client.ts (added 3 function comments)
### Processing
- 🔄 src/services/auth.ts
### Pending (6/10)
- ⏳ src/config/index.ts
- ...
Quick Reference
Comment Format Cheat Sheet
function functionName(paramName: string): Result {}
Quick Notes
- Only add comments: Strictly prohibited from modifying any code content
- Maintain consistency: Comment style must be consistent within the same file
- Accuracy first: Comment content must accurately reflect code functionality
- Avoid over-commenting: If code is clear enough, no comments needed
- Be concise: Comments should have practical value
- Examples must be runnable: All usage examples must be executable code
Reference Documents