document-touched-code

Adds focused JSDoc and comments to touched Event Hub code while avoiding noisy narration.

Updated Feb 25, 2026
One-click install
npx skills add https://github.com/werlang/event-hub --skill document-touched-code-werlang
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: document-touched-code
Source: https://github.com/werlang/event-hub/tree/main/.agents/skills/document-touched-code
Command: npx skills add https://github.com/werlang/event-hub --skill document-touched-code-werlang

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Codebases accumulate stale, noisy, or missing comments that mislead maintainers. This Skill enforces consistent documentation standards when creating or refactoring functions, classes, helpers, middleware, and tests in the Event Hub project. ## Core Features & Use Cases - JSDoc Standards: Adds JSDoc for named functions, class methods, exported helpers, and reusable local helpers while skipping trivial anonymous callbacks. - Comment Quality Rules: Comments explain why non-obvious blocks exist rather than narrating obvious lines, and stale comments are deleted instead of preserved. - Event Hub Conventions: Covers project-specific guidance for render helpers, MySQL helper methods, frontend model facades, and dashboard collaborators. - Use Case: When refactoring an Express middleware or adding a new MySQL helper, apply this Skill so the touched code gains concise, accurate documentation without comment clutter. ## Quick Start Apply the document-touched-code standards to add JSDoc and concise comments to the functions I just modified in this pull request.

Frequently Asked Questions about document-touched-code

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add JSDoc comments to JavaScript functions consistently?▼

Add JSDoc blocks to named functions, class methods, exported helpers, and reusable local helpers, documenting parameters and return values. Skip short anonymous callbacks that only serve as local wiring, since documenting them adds noise without value.

What should code comments explain in a refactoring workflow?▼

Comments should explain why a non-obvious block of code exists, not narrate what each obvious line does. When refactoring, prefer deleting stale comments over preserving guidance that no longer matches the code.

Should inline Express route handlers be documented?▼

Yes, route or middleware inline handlers that contain real logic should be documented immediately above their registration. Handlers that are only trivial wiring do not need comments.

When should I avoid adding comments to code?▼

Avoid commenting short anonymous callbacks used only as local wiring and obvious statements that restate what the code already says. Excessive narration of self-evident lines creates maintenance burden and visual noise.

Does this apply to project-specific helpers like MySQL or template code?▼

Yes, the standards include Event Hub conventions: MySQL helpers document centralized SQL behavior, render helpers document template-variable safety and falsy handling, and frontend model facades document the endpoint family they own.