القائمة
Write high-value @example blocks in JSDoc. Use when documenting functions, adding API examples, writing library docs, reviewing doc quality, or asked about examples.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | jsdoc-examples |
| version | 1.0.0 |
| description | Write high-value @example blocks in JSDoc. Use when documenting functions, adding API examples, writing library docs, reviewing doc quality, or asked about examples. |
| allowed-tools | ["Read","Write","Edit","Grep"] |
Examples teach what types can't. No net-new value → no example.
@hyperfrontend/lib-require-jsdoc-example enforces examples on exported APIs in publishable libs.
Docs: tools/eslint-rules/docs/lib-require-jsdoc-example.md
| Write | Skip |
|---|---|
| Non-obvious behavior | Type signature says it all |
| Error boundaries / throws | Every param permutation |
| Edge cases that surprise | "Works as typed" demos |
| Composition / integration | Trivial variations |
| Config gotchas / defaults | Uniform behavior across inputs |
| Frequently-used canonical | Simple delegating wrappers |
/* eslint-disable workspace/lib-require-jsdoc-example */ at the top of the file. We cannot inline disable because it would conflict with jsdoc comments themselves which need to be above the code it is for.userId, config) not foo, barFormat — wrap code in triple backticks:
/**
* @example
* ```typescript
* const result = myFunction(input)
* // => expected output
* ```
*/
Multiple — title each @example:
/**
* @example Basic usage
* ```typescript
* fetchUser(123)
* ```
*
* @example With options
* ```typescript
* fetchUser(123, { include: ['posts'] })
* ```
*/
Write conventional commits for the hyperfrontend monorepo — types, scopes (Nx project names), one-line subjects, atomic commits, versioning-harness boundaries. Use when committing, splitting work into commits, choosing a commit scope/type, or asked about commit format.
Register friction found while building hyperfrontend demos into the showcase findings registry. Use when a demo consuming @hyperfrontend/features surfaces an unclear API, confusing error, missing feature, docs gap, packaging snag, or DX papercut — file the finding before writing the workaround.
Write README.md files for hyperfrontend libraries and sub-modules. Use when creating library documentation, writing sub-module READMEs, documenting API tables, adding quick start guides, or reviewing README structure compliance.
Write ARCHITECTURE.md files for hyperfrontend libraries. Use when creating architecture documentation, documenting design decisions, adding system overview diagrams, or explaining module composition and data flow.
Coding conventions for the hyperfrontend Nx monorepo. Use when refactoring, adding features, fixing bugs, or writing any new code across libs/, apps/, tools/, or plugins/.
Achieve 100% code coverage for custom ESLint rules. Use when reviewing ESLint rules for coverage gaps, adding missing tests, or applying istanbul ignore comments.