RE

repo-source-code-document

Generates JSDoc comments and inline documentation for the Valibot library source code.

Install

mkdir -p .claude/skills/repo-source-code-document && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/7070" && unzip -o skill.zip -d .claude/skills/repo-source-code-document && rm skill.zip

Installs to .claude/skills/repo-source-code-document

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Write JSDoc comments and inline documentation for Valibot library source code in /library/src/. Use when documenting schemas, actions, methods, or utilities. Covers interface documentation, function overloads, purity annotations, inline comment patterns, and terminology consistency.
283 chars✓ has a “when” triggerlonger than Claude Code's old 250-char listing cap (fine on current versions)
Intermediate

Key capabilities

  • Document schemas, actions, and utilities
  • Apply JSDoc interface patterns
  • Add purity annotations to functions
  • Standardize inline comment patterns
  • Maintain terminology consistency

How it works

It applies specific JSDoc and inline comment patterns to library source code to ensure consistent documentation and tree-shaking support.

Inputs & outputs

You give it
Source code file
You get back
Documented source code

When to use repo-source-code-document

  • Documenting new schema
  • Adding JSDoc to library methods
  • Updating inline library documentation

About this skill

Valibot Source Code Documentation

Documentation patterns for library source code in /library/src/.

JSDoc Patterns

Interface Documentation

/**
 * String issue interface.
 */
export interface StringIssue extends BaseIssue<unknown> {
  /**
   * The issue kind.
   */
  readonly kind: 'schema';
  /**
   * The issue type.
   */
  readonly type: 'string';
}

Rules:

  • First line: [Name] [category] interface. (e.g., "String issue interface.")
  • Property comments: The [description]. (always start with "The", end with period)
  • All properties use readonly
  • No blank lines between property and its comment

Function Overloads

Each overload gets its own complete JSDoc:

/**
 * Creates a string schema.
 *
 * @returns A string schema.
 */
export function string(): StringSchema<undefined>;

/**
 * Creates a string schema.
 *
 * @param message The error message.
 *
 * @returns A string schema.
 */
export function string<
  const TMessage extends ErrorMessage<StringIssue> | undefined,
>(message: TMessage): StringSchema<TMessage>;

Rules:

  • First line: Creates a [name] [category]. (use "a" vs "an" correctly)
  • Blank line after description
  • @param name The [description]. (start with "The", end with period)
  • Blank line after params
  • @returns A [name] [category]. or @returns The [description].

Hints

Add hints after the main description, before @param:

/**
 * Creates an object schema.
 *
 * Hint: This schema removes unknown entries. To include unknown entries, use
 * `looseObject`. To reject unknown entries, use `strictObject`.
 *
 * @param entries The entries schema.
 *
 * @returns An object schema.
 */

Links

Link to external resources when relevant using markdown format:

/**
 * Creates an [email](https://en.wikipedia.org/wiki/Email_address) validation action.
 */

Implementation Function

The implementation has NO JSDoc but uses // @__NO_SIDE_EFFECTS__:

// @__NO_SIDE_EFFECTS__
export function string(
  message?: ErrorMessage<StringIssue>
): StringSchema<ErrorMessage<StringIssue> | undefined> {
  return {
    /* ... */
  };
}

// @__NO_SIDE_EFFECTS__ rules:

  • Add for pure functions (no external state mutation, no I/O)
  • Most schema/action/method factories are pure
  • Do NOT add for functions that mutate arguments (like _addIssue)
  • Used by bundlers for tree-shaking

Utility Functions

/**
 * Stringifies an unknown input to a literal or type string.
 *
 * @param input The unknown input.
 *
 * @returns A literal or type string.
 *
 * @internal
 */
// @__NO_SIDE_EFFECTS__
export function _stringify(input: unknown): string {
  // ...
}

Rules:

  • Use @internal tag for internal utilities
  • Prefix internal functions with _
  • Only add // @__NO_SIDE_EFFECTS__ if function is pure

Inline Comment Patterns

Section Headers

'~run'(dataset, config) {
  // Get input value from dataset
  const input = dataset.value;

  // If root type is valid, check nested types
  if (Array.isArray(input)) {
    // Set typed to true and value to empty array
    dataset.typed = true;
    dataset.value = [];

    // Parse schema of each array item
    for (let key = 0; key < input.length; key++) {
      // ...
    }
  }
}

Rules:

  • Describe WHAT the next code block does
  • Present tense verbs: "Get", "Parse", "Check", "Set", "Add", "Create"
  • Omit articles ("the", "a", "an"): "Get input value" not "Get the input value"
  • No period at end
  • Blank line before comment, no blank line after

Conditional Logic

// If root type is valid, check nested types
if (input && typeof input === 'object') {
  // ...
}

// Otherwise, add issue
else {
  _addIssue(this, 'type', dataset, config);
}

Rules:

  • Use "If [condition], [action]"
  • Use "Otherwise, [action]" for else branches
  • Omit articles

Hint Comments (Exception)

// Hint: The issue is deliberately not constructed with the spread operator
// for performance reasons
const issue: BaseIssue<unknown> = {
  /* ... */
};

Rules:

  • Start with "Hint:"
  • Explain WHY, not just what
  • CAN use articles (unlike other inline comments)
  • Document performance decisions, non-obvious logic

TODO Comments

// TODO: Should we add "n" suffix to bigints?
if (type === 'bigint') {
  /* ... */
}

@ts-expect-error

Used for internal dataset mutations TypeScript can't track:

// @ts-expect-error
dataset.typed = true;

File Type Patterns

Schema Files (string.ts, object.ts, etc.)

  1. Issue interface with JSDoc
  2. Schema interface with JSDoc
  3. Function overloads with full JSDoc each
  4. Implementation with // @__NO_SIDE_EFFECTS__
  5. Return object with '~run' method containing inline comments

Action Files (email.ts, minLength.ts, etc.)

  1. Issue interface (for validation actions)
  2. Action interface with JSDoc
  3. Function overloads with JSDoc
  4. Implementation with // @__NO_SIDE_EFFECTS__

Method Files (parse.ts, pipe.ts, etc.)

More complex logic, require more inline comments.

Utility Files (_addIssue.ts, _stringify.ts)

  1. Single function with JSDoc including @internal
  2. // @__NO_SIDE_EFFECTS__ only if pure

Terminology Consistency

JSDoc descriptions must match the kind property if present:

kind PropertyJSDoc Wording
'schema'"Creates a ... schema."
'validation'"Creates a ... validation action."
'transformation'"Creates a ... transformation action."

Quick Reference

JSDoc First Lines

TypePattern
Interface[Name] [category] interface.
Type[Name] [category] type.
FunctionCreates a [name] [category].
Utility[Verb]s [description].

Inline Comment Starters

PatternExample
// Get [what]// Get input value from dataset
// If [condition], [action]// If root type is valid, check nested types
// Otherwise, [action]// Otherwise, add issue
// Create [what]// Create object path item
// Add [what] to [where]// Add issues to dataset
// Parse [what]// Parse schema of each array item
// Set [property] to [value]// Set typed to true
// Hint: [explanation]// Hint: This is for performance
// TODO: [task]// TODO: Add bigint suffix

Terminology

Use consistently:

  • Schema (not "validator")
  • Action (not "validation" for the object)
  • Issue (not "error" in type names)
  • Dataset (internal data structure)
  • Config/Configuration (not "options")

Checklist

  • Interfaces: [Name] [category] interface.
  • Properties: The [description].
  • Overloads: Complete JSDoc each
  • Implementation: NO JSDoc
  • Pure functions: // @__NO_SIDE_EFFECTS__
  • Impure functions (mutate args): NO @__NO_SIDE_EFFECTS__
  • Internal utilities: @internal tag
  • Inline comments: No articles (except Hint), no periods
  • JSDoc comments: End with periods

When not to use it

  • When documenting non-Valibot code
  • When functions mutate arguments

Prerequisites

TypeScript

Limitations

  • Strict adherence to Valibot-specific patterns
  • Requires manual verification of purity

How it compares

It enforces strict documentation rules and purity annotations tailored specifically for the Valibot library architecture.

Compared to similar skills

repo-source-code-document side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
repo-source-code-document (this skill)15moNo flagsIntermediate
vscode-ext-commands27moNo flagsBeginner
agent-implementer-sparc-coder16moReviewIntermediate
ai-sdk-model-manager14moReviewIntermediate

Try saying

Example prompts that trigger this skill in your AI assistant.

More by open-circle

View all by open-circle

repo-website-api-create

open-circle

Create new API reference pages for the Valibot website at website/src/routes/api/. Use when adding documentation for new schemas, actions, methods, or types. Covers reading source code, creating properties.ts and index.mdx files, updating menu.md, and cross-referencing related APIs.

26

repo-prepare-release

open-circle

Prepare releases by analyzing changelogs, determining version bumps, and updating package.json and changelog files.

12

repo-source-code-review

open-circle

Review pull requests and source code changes in /library/src/. Use when reviewing PRs, validating implementation patterns, or checking code quality before merging. Covers code quality checks, type safety, documentation review, test coverage, and common issues to watch for.

12

repo-structure-navigate

open-circle

Navigate the Valibot repository structure. Use when looking for files, understanding the codebase layout, finding schema/action/method implementations, locating tests, API docs, or guide pages. Covers monorepo layout, library architecture, file naming conventions, and quick lookups.

16

repo-website-api-update

open-circle

Update existing API documentation pages after source code changes. Use when syncing docs with library changes like new parameters, type constraint changes, interface updates, or function renames. Covers common change patterns and verification steps.

13

repo-website-guide-create

open-circle

Create conceptual documentation and tutorial pages for the Valibot website at website/src/routes/guides/. Use when adding guides about schemas, pipelines, async validation, migration, or other topics. Covers directory structure, MDX templates, frontmatter, and content guidelines.

16

Search skills

Search the agent skills registry