Menu
Add JSDoc to code entities. TRIGGER when: user asks to add/write/improve JSDoc (e.g., "add jsdoc to Foo", "jsdoc for Bar").
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Orchestrate the review skills (review-dog, regression-dog) into one deduplicated, adjudicated report. TRIGGER when: the user wants a combined/full/aggregated review of a branch or commit (e.g., "run the full review", "review this branch with everything", "give me the aggregated review").
Review code changes for bugs, style, best practices, and adherence to project conventions.
Review new/changed code for bugs. TRIGGER when: checking for bugs, auditing new logic, or validating correctness (e.g., "any bugs here?", "check this for bugs", "is this correct?").
Review code for regressions. TRIGGER when: reviewing changes, checking for breakage, or auditing commits (e.g., "did I break anything", "review last commit").
| name | jsdoc-writer |
| description | Add JSDoc to code entities. TRIGGER when: user asks to add/write/improve JSDoc (e.g., "add jsdoc to Foo", "jsdoc for Bar"). |
Add precise yet tight JSDoc for the entities specified by the user. Avoid slop. Make it the JSDoc that engineers will love to read, not the JSDoc that PMs will love to show off.
Important:
@param/@returns descriptions only when the type and name don't tell the full story. A bare @param {string} name beats @param {string} name - The name.Scope (pass as arguments):