agentleFS
yamcodesyamcodes/arkenv/skills/jsdoc/SKILL.md

jsdoc

Skill147 starsChanged 23 days agoMITView on GitHub

Use this skill to automatically write or fix JSDoc comments for JavaScript/TypeScript code. It handles requests to document code at any scope: a single function, all functions in a file, or just the new and changed functions in a pull request.

We split this skill into the rules it gives an agent

9 rules. 0 are common, 4 are distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 3 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Add JSDoc to functions UNLESS the code is entirely self-explanatory or the function is named so clearly that a comment would be redundant.

    line 14
  2. Distinctive:

    If in doubt, lean towards adding JSDoc if the function has complex logic or multiple parameters, but skip it for simple getters/setters or …

    line 15
  3. Distinctive:

    When generating JSDoc comments, you MUST strictly adhere to the following rules:

    line 20
  4. Very specific:

    Follow JSDoc Specification: Use standard block comment format (/ ...

    line 22
  5. Very specific:

    Document all inputs: Use the @param tag for every parameter.

    line 23
  6. Very specific:

    Document the output: Use the @returns tag for the return value (unless the function returns void and it's obvious).

    line 24
  7. Very specific:

    Document errors: If the function explicitly throws an error (e.g., throw new Error(...)), document it using the @throws tag.

    line 25
  8. Distinctive:

    If the user asks to apply JSDoc to all functions in a file, process every function, but remember to skip those that are trivial and …

    line 61
  9. Very specific:

    If the user asks to apply JSDoc to all changed files in a PR, use the GitHub CLI (gh pr diff or similar) to identify which functions were …

    line 62

“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Jsdoc generation skill

This skill guides the agent in adding or updating JSDoc comments for functions in TypeScript codebases.

When to add jsdoc

  • Add JSDoc to functions UNLESS the code is entirely self-explanatory or the function is named so clearly that a comment would be redundant.
  • If in doubt, lean towards adding JSDoc if the function has complex logic or multiple parameters, but skip it for simple getters/setters or obvious utilities.
  • For existing functions that already have JSDoc, ONLY update the JSDoc if there is a typo or if it no longer reflects the code's intent. Do NOT make redundant rephrasings or meaningless sentence shifts.

Jsdoc requirements

When generating JSDoc comments, you MUST strictly adhere to the following rules:

  1. Follow JSDoc Specification: Use standard block comment format (/** ... */).
  2. Document all inputs: Use the @param tag for every parameter.
  3. Document the output: Use the @returns tag for the return value (unless the function returns void and it's obvious).
  4. Document errors: If the function explicitly throws an error (e.g., throw new Error(...)), document it using the @throws tag.
  5. NO Type Tags: The codebase uses TypeScript, so do NOT include types in the JSDoc tags. For example, use @param id The user ID instead of @param {string} id The user ID.
  6. Imperative Verb Form: The description MUST use the imperative verb form. For example, use "Create a user", "Add an item", "Calculate the total" instead of "Creates a user", "Adds an item", "Calculates the total".
  7. No Trailing Periods in Tags: Descriptions inside @param, @returns, and @throws tags must NOT end with a period. The main function description may end with a period, but tag descriptions should remain concise and period-free.

Example

Input:

export function calculateDiscountedPrice(basePrice: number, discountPercentage: number, taxRate?: number): number {
    if (basePrice < 0) throw new Error("Price cannot be negative");
    // ...
}

Output:

/**
 * Calculate the final price after applying a discount and optional tax.
 * 
 * @param basePrice The original price of the item
 * @param discountPercentage The discount to apply as a percentage (e.g., 20 for 20%)
 * @param taxRate The optional tax rate to apply after discount
 * @returns The final calculated price
 * @throws An error if the base price is negative
 */
export function calculateDiscountedPrice(basePrice: number, discountPercentage: number, taxRate?: number): number {
    if (basePrice < 0) throw new Error("Price cannot be negative");
    // ...
}

Applying to multiple functions

  • If the user asks to apply JSDoc to all functions in a file, process every function, but remember to skip those that are trivial and self-explanatory.
  • If the user asks to apply JSDoc to all changed files in a PR, use the GitHub CLI (gh pr diff or similar) to identify which functions were added or modified, and only update those functions.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.