How do I install the Write Component Jsdocs skill?

Run npx skillmds@latest add goorm-dev/write-component-jsdocs in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Write Component Jsdocs safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Write Component Jsdocs?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Write Component Jsdocs free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Write Component Jsdocs?

goorm-dev (@goorm-dev) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Write Component Jsdocs by goorm-dev

Name: Write Component Jsdocs
Author: goorm-dev

Write Component Jsdocs

Guide for writing JSDoc comments on vapor-ui components and their props. Use when adding, reviewing, or fixing JSDoc on component tsx files or css.ts variant files. Covers where to place comments based on component pattern — standalone, compound root, compound sub-part — language and format rules, and a checklist for review. Triggers on requests like add jsdocs, write component docs, document props, jsdoc 작성, or when reviewing a component documentation completeness.

goorm-dev 1f7ee9c 2 files · 13.9 KB Updated Sep 17, 2026

File contents

JSDoc Component Guide

JSDoc in vapor-ui is user-facing UI, not internal code comments. Write it for developers who encounter the component for the first time via documentation sites (Storybook Autodocs, etc.).

Core rules

Language: English only. No Korean in JSDoc blocks.
Format: Always leave the first line of every /** ... */ block empty.
Placement: Write the component summary above the component function. Write individual prop descriptions inside the Props interface/type, not on the component function.

Where to write

Placement depends on the component pattern. See references/guide.md for detailed patterns and examples.

Target	File	Location
Component summary	`{component}.tsx`	Above the component function
Individual props	`{component}.tsx`	Inside the `interface` or namespace `Props`
Variant groups	`{component}.css.ts`	On each variant key object inside `componentRecipe()`

Do NOT write JSDoc on:

Individual variant values (sm, md, primary, fill, etc.) — the variant key description is sufficient
export type XxxVariants — tooling derives this from the recipe automatically

Pattern quick-reference

Standalone — no JSDoc on namespace Props itself; write variant group docs in componentRecipe() in .css.ts
Compound Root (custom props via interface) — write on the interface, namespace wraps it
Compound Root with context (Assign<…, Context> pattern) — write only on custom props
Compound sub-part (Omit<…, keyof Context> pattern) — write only on remaining props

Component summary rules

One single line — no line breaks inside the summary
User perspective: what it is → when to use it
No internal terms (memoized, wrapper, token-based, etc.)
End with the rendered HTML element using backticks around the tag: "Renders a <button> element." or "Doesn't render its own HTML element.".

Prop description rules

Don't repeat the prop name or its type
Describe side effects and interactions with other props
For numeric props: include unit and valid range
For event handlers: specify the exact trigger condition, not just "handler"
Use the @default JSDoc tag to indicate default values — never write Default: \value`` inline in the description text

Review checklist

See the full checklist in references/guide.md.

Quick checklist:

All JSDoc in English
First line of every block is empty
Summary is one line, complete sentence, HTML element in backticks (e.g. `<button>`)
No prop name repetition in descriptions
Event handlers describe exact trigger condition
Numeric props include unit and range
No JSDoc on individual variant values (sm, md, fill, primary, etc.)
No JSDoc on export type XxxVariants
Default values use @default tag, not inline Default: \value`` text

---name: write-component-jsdocsdescription: Guide for writing JSDoc comments on vapor-ui components and their props. Use when adding, reviewing, or fixing JSDoc on component tsx files or css.ts variant files. Covers where to place comments based on component pattern — standalone, compound root, compound sub-part — language and format rules, and a checklist for review. Triggers on requests like add jsdocs, write component docs, document props, jsdoc 작성, or when reviewing a component documentation completeness.---# JSDoc Component GuideJSDoc in vapor-ui is **user-facing UI**, not internal code comments. Write it for developers who encounter the component for the first time via documentation sites (Storybook Autodocs, etc.).## Core rules- **Language**: English only. No Korean in JSDoc blocks.- **Format**: Always leave the first line of every `/** ... */` block empty.- **Placement**: Write the component summary above the component function. Write individual prop descriptions inside the Props interface/type, not on the component function.## Where to writePlacement depends on the component pattern. See [references/guide.md](references/guide.md) for detailed patterns and examples.| Target | File | Location || ----------------- | -------------------- | ----------------------------------------------------- || Component summary | `{component}.tsx` | Above the component function || Individual props | `{component}.tsx` | Inside the `interface` or namespace `Props` || Variant groups | `{component}.css.ts` | On each variant key object inside `componentRecipe()` |**Do NOT write JSDoc on:**- Individual variant values (`sm`, `md`, `primary`, `fill`, etc.) — the variant key description is sufficient- `export type XxxVariants` — tooling derives this from the recipe automatically### Pattern quick-reference- **Standalone** — no JSDoc on namespace `Props` itself; write variant group docs in `componentRecipe()` in `.css.ts`- **Compound Root** (custom props via `interface`) — write on the `interface`, namespace wraps it- **Compound Root with context** (`Assign<…, Context>` pattern) — write only on custom props- **Compound sub-part** (`Omit<…, keyof Context>` pattern) — write only on remaining props## Component summary rules1. One single line — no line breaks inside the summary2. User perspective: what it is → when to use it3. No internal terms (`memoized`, `wrapper`, `token-based`, etc.)4. End with the rendered HTML element using backticks around the tag: "Renders a `<button>` element." or "Doesn't render its own HTML element.".## Prop description rules1. Don't repeat the prop name or its type2. Describe side effects and interactions with other props3. For numeric props: include unit and valid range4. For event handlers: specify the exact trigger condition, not just "handler"5. Use the `@default` JSDoc tag to indicate default values — never write `Default: \`value\`` inline in the description text## Review checklistSee the full checklist in [references/guide.md](references/guide.md#checklist).**Quick checklist:**- [ ] All JSDoc in English- [ ] First line of every block is empty- [ ] Summary is one line, complete sentence, HTML element in backticks (e.g. `` `<button>` ``)- [ ] No prop name repetition in descriptions- [ ] Event handlers describe exact trigger condition- [ ] Numeric props include unit and range- [ ] No JSDoc on individual variant values (`sm`, `md`, `fill`, `primary`, etc.)- [ ] No JSDoc on `export type XxxVariants`- [ ] Default values use `@default` tag, not inline `Default: \`value\`` text

Frequently asked questions