Agent skill

Shift JSDoc Contracts

by shift-editor in shift-editor/shift

Guides writing JSDoc for Shift exported APIs as a stable caller contract, covering ownership, lifetime, side effects and nullability that TypeScript types cannot express.

Apache-2.0Auto-check passedDevelopment

Install Shift JSDoc Contracts

skills CLI
$ npx skills add shift-editor/shift --skill jsdoc -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install shift-editor/shift jsdoc --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/shift-editor/shift.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.codex/skills/jsdoc .claude/skills/jsdoc && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
jsdoc
GitHub stars
343
Token cost
~3.7k tokens
SKILL.md length
1,291 words
Files
1
Skills in repo
14
Repo updated
First seen
Licence
Apache-2.0

At a glance

Guides writing JSDoc for Shift exported APIs as a stable caller contract, covering ownership, lifetime, side effects and nullability that TypeScript types cannot express.

  • Works in 7 steps: Identify the audience: caller,… → State the stable contract in one short… → Add details only for ownership,… → …
  • Documenting an exported class or method in the Shift codebase
  • SKILL.md covers Why this matters, Runbook, Hard Style Rules and What To Document, plus 6 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Comments must sit directly before the symbol they document and use the /** */ form so tooling can read them. The first sentence is a one-line contract written as a verb phrase ending in a period, never starting with this function, because VS Code hover shows that line in bold. Longer explanation moves under @remarks. Detail is added only where types fall short: ownership, lifetime, reactivity, mutation, side effects, nullability, performance and call ordering.

For callable APIs, every public parameter gets an @param describing its role, constraint, ownership or valid range, @returns covers values, nullable results, created objects, snapshots and read-only views, and @throws lists each observable failure mode. The skill rules out @returns void, asks for one @see link tag per related symbol, allows @example only when the call flow is not obvious, and ends with a pass that deletes implementation trivia, call-site anecdotes and unstable examples.

When your agent uses it

  • Documenting an exported class or method in the Shift codebase
  • Writing JSDoc for reactive state, render frames or domain data structures
  • Revising comments that describe the implementation instead of the caller's contract
  • Reviewing an API whose ownership, nullability or lifetime is easy to misread

Example prompts

  • “Add JSDoc to the exported classes in the editor package, starting with the public methods.”
  • “Rewrite the comments on the render frame types so each opens with a one-line contract.”
  • “Document the public methods of the reactive signal wrapper, including nullability and side effects.”

Workflow steps

7 steps, taken from the first numbered list in SKILL.md.

  1. Identify the audience: caller, implementer, renderer, tool author, or maintainer.
  2. State the stable contract in one short opening sentence.
  3. Add details only for ownership, lifetime, reactivity, mutation, side effects, nullability, performance, or call ordering. Put long detail…
  4. Use tags for callable APIs
  5. Cross-reference siblings with @see {@link OtherSymbol} (one tag per related symbol).
  6. Add @example only when the intended call flow, ordering, or output is not obvious from the signature.
  7. Re-read the comment and delete implementation trivia, current call-site anecdotes, and unstable examples.

What it can do on your machine

Read from SKILL.md and the folder at commit e7dacfa. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are typescript).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Links to these hosts (documentation or services it may open):

    • jsdoc.app

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Shift JSDoc Contracts loads about 3.7k tokens when it runs. Until then it costs about 82 tokens; SKILL.md has 1,291 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~82
When it runs · the whole SKILL.md, loaded when a task matches
~3.7k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from shift-editor/shift at commit e7dacfa, republished under its Apache-2.0 licence (© shift-editor). 1,291 words, ~3,692 tokens.

Download SKILL.mdSave it as .claude/skills/jsdoc/SKILL.md (or your agent's skills folder).
name
jsdoc
description
Add or revise source-level JSDoc for Shift APIs. Use this skill before writing or editing documentation comments for exported classes, methods, constructors, domain data structures, render frames, reactive state, or any API where caller intent, side effects, lifetime, ownership, or nullability are easy to misunderstand.

/jsdoc — Source API Contracts

Write JSDoc as the stable public contract a caller needs without reading the implementation.

JSDoc comments must sit immediately before the documented symbol and use /** ... */ so tooling can parse them. Follow the standard tag vocabulary from https://jsdoc.app/about-getting-started, adapted for TypeScript source.

Why this matters

  • VS Code hover renders the first line in bold and the rest as body. A one-sentence contract on line 1 is the single highest-leverage thing you can write.
  • TypeScript already encodes shape. JSDoc is for what types can't say: ownership, lifetime, mutation, side effects, side-channel reactivity, nullability semantics, performance class, call ordering.
  • Code review is the second reader. Reviewers should be able to judge a call site against the doc without opening the implementation.

Runbook

  1. Identify the audience: caller, implementer, renderer, tool author, or maintainer.
  2. State the stable contract in one short opening sentence.
  3. Add details only for ownership, lifetime, reactivity, mutation, side effects, nullability, performance, or call ordering. Put long detail under @remarks.
  4. Use tags for callable APIs:
    • Add @param for every public constructor, method, or function parameter, and make the text describe the parameter's role, constraint, ownership, or valid range.
    • Add @returns when a method returns a value, nullable result, created object, snapshot, or read-only view.
    • Add @throws {ErrorType} when … for every observable failure mode (custom error class, semantic Error).
    • Do not add @returns void; describe the side effect in prose instead.
  5. Cross-reference siblings with @see {@link OtherSymbol} (one tag per related symbol).
  6. Add @example only when the intended call flow, ordering, or output is not obvious from the signature.
  7. Re-read the comment and delete implementation trivia, current call-site anecdotes, and unstable examples.

Hard Style Rules

  • One-line contract. First sentence is a verb phrase (Returns…, Applies…, Triggers…), ending with a period. No "This function…".
  • @remarks for the long explanation. If you need more than one sentence of context, demote it under @remarks so the hover summary stays clean.
  • @param name - description documents meaning, not type. For public callable APIs, include the tag and make it earn its place by describing role, constraint, ownership, valid range, or call-order semantics.
  • @returns documents meaning, never "void". Drop the tag entirely for void returns; describe the side effect in the summary instead. Use @returns to clarify ownership ("a fresh array; caller owns it"), nullability semantics ("null when the glyph has no contours, not when it's missing"), or that the result is a snapshot vs a live reactive view.
  • Document side effects, lifetime, and reactivity. TypeScript can't encode "runs after render", "mutates the Glyph signal", "JS-only — does not call NAPI", "transfers ownership of the buffer". That is exactly what JSDoc is for.
  • Stable terms over current implementation names. Document the concept, not today's wiring.
  • No warnings, no scolding. State the contract directly.
  • Do not document private helpers unless they encode a non-obvious invariant.
  • Do not name current callers ("used by FooManager") — rots fast.
  • Never use JSDoc as a TODO list. That belongs in commits, issues, or // TODO comments.

What To Document

Document where the type signature is silent. If the type fully encodes the contract, write nothing. Otherwise, prioritize these dimensions:

  • Effects — purity, mutation of arguments, mutation of shared state, I/O.
  • Ownership — who owns the return value, who may mutate it, aliasing with internal state.
  • Identity vs value — handles/refs/IDs that look like the loaded object but aren't; snapshots vs live views.
  • Nullability semantics — what null / undefined / empty actually means (absent, error, not-yet-loaded, end-of-stream).
  • Resolution semantics — strict vs fallback, find vs find-or-create, exact vs nearest.
  • Lifetime and ordering — preconditions, disposal, idempotence, what makes the result go stale.
  • Failure modes — which errors, under which conditions; whether failure is observable or swallowed.
  • Concurrency and context — thread, render phase, re-entrancy, async cancellation behavior.
  • Performance class — Big-O, hot-path safety, sync-vs-async cost, when a convenient method is wrong.

Pick only the dimensions that apply. Do not force every doc to address all of them.

Tag Reference Card (TS-first)

TagUse it whenExample
@param name - descEvery public param. Document the constraint, not the type.@param glyph - must be loaded (not a GlyphRef)
@returns descNullable / created / snapshot / read-only / non-obvious return.@returns null when no source is active; never throws.
@throws {Err} when …Every observable failure mode. Always type + condition.@throws {GlyphNotLoadedError} when called on a ref-only glyph.
@exampleCall order, setup, or output carries the lesson.See below — fenced ts, imports, // Output: line.
@remarksLong explanation that would bloat the summary.One short paragraph; not multi-paragraph essays.
@see {@link Foo}One tag per related sibling API.@see {@link createDraft}
@deprecated <migration>Always with replacement or removal reason.@deprecated Use draft.setPositions instead — avoids NAPI per frame.
@template T - descGeneric with a semantic constraint that isn't obvious from the signature.@template T - coordinate-space tag; controls bound interpretation.
Show full SKILL.md (498 more words)Show less
Avoid in TypeScript

These re-encode information TS already owns. Including them is noise and risks drift.

  • @type, @typedef, @property — TS variable annotations, type, and interface are the source of truth.
  • @class, @constructor, @extends, @implements, @function, @method — the declaration shape says this.
  • {Type} annotations inside @param / @returns — never write @param {string} name. Document meaning; TS owns the type.
Skip in app code

These are doc-generator ceremony for published packages. Shift is not a published package; do not write these in app code.

  • @since, @public, @beta, @alpha, @experimental, @category
  • @author, @version, @copyright
  • date-fns-style @name/@summary/@description triples

Tag Format

In TypeScript files, omit JSDoc type annotations. Let TypeScript own the type; let JSDoc own meaning.

ts
/**
 * Snapshot of state required to redraw the scene layer.
 *
 * Building this frame establishes the reactive dependencies for the scene
 * output. Drawing code consumes the frame as plain data.
 *
 * @param dependencies - Values that invalidate or describe one scene redraw.
 */
constructor(dependencies: SceneFrameDependencies) {}

For functions with multiple parameters, document each parameter by role:

ts
/**
 * Converts a screen-space pointer into editor coordinate spaces.
 *
 * @param screen - Pointer position in canvas pixels.
 * @param drawOffset - Glyph-local offset applied by the current editor view.
 * @returns Coordinates in screen, scene, and glyph-local space.
 */
function resolveCoordinates(
  screen: Point2D,
  drawOffset: Point2D,
): Coordinates {}

When failure paths are observable, document them with @throws:

ts
/**
 * Loads a glyph by handle. Resolves once the source is hydrated.
 *
 * @param handle - identity returned by {@link glyphHandleForUnicode}.
 * @returns the loaded glyph; never a {@link GlyphRef}.
 * @throws {GlyphNotFoundError} when the handle does not resolve in the active font.
 * @see {@link glyphHandleForUnicode}
 */
async function loadGlyph(handle: GlyphHandle): Promise<Glyph> {}

When deprecating, name the replacement:

ts
/**
 * @deprecated Use {@link draft.setPositions} — `bridge.setNodePositions` sends
 *   one NAPI call per point and causes ~450ms frames on dense glyphs.
 */
function setNodePositions(updates: NodePositionUpdate[]): void {}

Examples — the rules

Examples must be runnable assertions, not decoration.

  • Always fenced and language-tagged with ```ts. VS Code highlights inside fences.
  • Self-contained. Include imports. The reader should be able to paste the snippet and have it compile.
  • Show expected output with a // Output: or // => comment when the value carries the lesson.
  • Short. 8–12 lines is the typical good length; 25 is the ceiling. If it doesn't fit, the example is the wrong shape.
  • One concept per @example. Multiple @example blocks are fine and better than one mega-block.

A good example for a Shift API:

ts
/**
 * Begins a JS-only edit of the active glyph. Pair with {@link GlyphDraft.finish}
 * to persist, or {@link GlyphDraft.discard} to revert.
 *
 * @returns a draft scoped to the active glyph; `null` when no glyph is loaded.
 *
 * @example
 * ```ts
 * const draft = editor.createDraft();
 * if (!draft) return;
 *
 * for (const update of dragFrame) {
 *   draft.setPositions(update); // JS-only; no NAPI
 * }
 *
 * draft.finish("translate");    // syncs once, records undo
 * ```
 */
createDraft(): GlyphDraft | null {}

When TS inference is non-obvious, annotate the type position inline (Effect pattern):

ts
/**
 * @example
 * ```ts
 * //      ┌─── Option<Glyph>
 * //      ▼
 * const result = font.glyphForUnicode(0x41);
 * ```
 */

Avoid examples that depend on hidden setup, test fixtures, or implicit globals.

Overloads

  • Per-overload JSDoc when parameter meanings differ. (This is the TS standard-library convention.) Copy the contract on each signature; do not put one block on the implementation signature.
  • Top-overload JSDoc only when the contract is identical and only the type shape differs. The implementation signature stays bare.
ts
/**
 * Resolves a glyph from its Unicode codepoint.
 * @param codepoint - the Unicode scalar value.
 */
function glyphFor(codepoint: number): Glyph | null;
/**
 * Resolves a glyph from its handle.
 * @param handle - identity from a prior lookup; cheaper than codepoint resolution.
 */
function glyphFor(handle: GlyphHandle): Glyph | null;
function glyphFor(arg: number | GlyphHandle): Glyph | null {
  /* impl */
}

Anti-Patterns (bad → good)

@returns void
ts
// ❌
/** @returns void */
clear(): void {}

// ✅ describe the side effect; drop @returns entirely
/** Clears all queued render frames. Idempotent. */
clear(): void {}
Re-stating the signature in prose
ts
// ❌
/**
 * @param glyph - the glyph
 * @param index - the index
 */

// ✅ document the constraint
/**
 * @param glyph - must be loaded (not a {@link GlyphRef}).
 * @param index - zero-based contour index; -1 selects the outer hull.
 */
Multi-paragraph summary
ts
// ❌ VS Code hover becomes a wall of text
/**
 * This function is used to set positions. It is part of the GlyphDraft API and
 * is used during drag operations. It does not call NAPI. It must be paired
 * with either finish() or discard().
 */

// ✅ one-line contract + @remarks
/**
 * Updates JS-side glyph positions; pair with {@link finish} or {@link discard}.
 *
 * @remarks
 * JS-only — does not call NAPI. Use during drag hot path; call `finish()` once
 * at gesture end to sync to Rust, or `discard()` to revert.
 */
Naming current callers
ts
// ❌ rots fast
/** Called by GlyphSidebar and TransformPanel. */

// ✅ describe what it produces
/** Returns the active glyph's tight bounds, accounting for sidebearings. */
Bare @deprecated
ts
// ❌
/** @deprecated */
function oldThing() {}

// ✅ name the replacement or the reason
/** @deprecated Use {@link newThing} — removes the legacy 2D-only path. */
function oldThing() {}
@example for trivial calls
ts
// ❌ noise
/**
 * @example
 * ```ts
 * const id = glyph.id;
 * ```
 */
get id(): string {}

// ✅ no @example; the name is the whole story
get id(): string {}
Examples that depend on hidden setup
ts
// ❌ what is `editor`?
/** @example editor.commit(); */

// ✅ self-contained
/**
 * @example
 * ```ts
 * const editor = createTestEditor();
 * await editor.loadGlyph("A");
 * editor.commit();
 * ```
 */
General "do not" list
  • API dumps covering every accessor.
  • Long examples that obscure the method being documented.
  • Compat wrappers or aliases that hide which API should be used.
  • Rewriting behavior while documenting unless the user requested the API fix too.
  • Describing bugs, migrations, or "currently used by X" in API docs.
  • Listing concrete state variants as examples when the actual contract is broader.
  • Documenting private helpers with full @param/@returns/@example blocks — a one-line summary is enough.
  • Mixing {Type}-style JSDoc with TSDoc tags in the same module; pick one (in TS, drop {Type}).

Quick Checklist

Before saving, scan your doc against this list:

  • First line is one sentence, verb-phrase, ends with a period.
  • No @type, @typedef, or {Type} annotations.
  • No @returns void. Side effect described in summary.
  • Every observable failure has @throws {Type} when ….
  • @example (if present) has imports, is fenced ```ts, and shows output when it carries the lesson.
  • No current-caller name-drops, no migration notes, no TODOs.
  • No ceremony tags (@since, @public, @category, @author).
  • If deprecated, the replacement or reason is named.

© shift-editor, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .codex/skills/jsdoc of shift-editor/shift.

Open the folder on GitHubat commit e7dacfa

Compare with similar skills

Shift JSDoc Contracts next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Shift JSDoc Contracts compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Shift JSDoc Contracts this skillshift-editor/shift343—~3.7kAutomated safety check: PassApache-2.0
Install Anti-Slop Oxlint Rulesdmmulroy/anti-slop5.2k—~2.2kAutomated safety check: PassMIT
Add Packageremix-run/remix33k—~2kAutomated safety check: PassMIT
Code Reviewerjewbetcha/opentrace1162 repos~1.1kAutomated safety check: NotesMIT
Coding Standardskurealnum/dotfiles29017 repos~2.9kAutomated safety check: PassNone
Code Qualityredis/RedisInsight8.9k—~1.2kAutomated safety check: PassCustom licence

Similar skills

  • Installs, updates or migrates the vendored anti-slop Oxlint plugin in a repository, keeping local rule changes and the plugin's license and provenance files.

    5.2k GitHub stars~2.2k tokensUpdated 27 days ago
    DevelopmentAuto-check passed
  • Add Package

    remix-run/remix

    Create or align a package in the Remix monorepo to match existing package conventions.

    33k GitHub stars~2k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Code Reviewer

    jewbetcha/opentrace

    Comprehensive code review skill for TypeScript, JavaScript, Python, Swift, Kotlin, Go.

    116 GitHub starsUsed in 2 repos~1.1k tokens
    DevelopmentAuto-check: notes
  • Coding Standards

    kurealnum/dotfiles

    Universal coding standards, best practices, and patterns for TypeScript, JavaScript, React, and Node.js development.

    290 GitHub starsUsed in 17 repos~2.9k tokens
    DevelopmentAuto-check passed
  • Code Quality

    redis/RedisInsight

    Official

    Code-quality standards for RedisInsight: TypeScript strictness, naming conventions (camelCase, PascalCase, UPPERSNAKECASE), linting rules, no any without reason, no !important in styles, and…

    8.9k GitHub stars~1.2k tokensUpdated 2 days ago
    DevelopmentAuto-check passed
  • Scratchpad

    Effect-TS/effect-smol

    Extract the JSDoc example nearest the active source selection or cursor into ./scratchpad as a TypeScript file.

    782 GitHub stars~459 tokensUpdated 2 mo ago
    DevelopmentAuto-check passed

More from shift-editor/shift

All 14 skills in this repo
  • Shift Commit Rules

    shift-editor/shift

    Rules for writing git commits in the Shift font editor repo: Conventional Commits subjects, user-facing changelog wording, concise subjects and logical commit boundaries.

    343 GitHub stars~1.4k tokensUpdated yesterday
    Auto-check: notes
  • Dead Code Removal with Knip

    shift-editor/shift

    Finds unused files, exports and class members with Knip, then verifies each candidate through reference tracing before removing anything, never using knip --fix.

    343 GitHub stars~1.8k tokensUpdated yesterday
    Auto-check passed
  • Shift Subsystem Docs

    shift-editor/shift

    Updates or creates DOCS.md files for Shift subsystems, recording the architecture invariants and constraints that cannot be learned from reading the source.

    343 GitHub stars~1.9k tokensUpdated yesterday
    Auto-check passed
  • Adversarial Docs Audit

    shift-editor/shift

    Fact-checks DOCS.md files against the source code, testing each concrete claim and sorting it as true, false, stale or unverifiable.

    343 GitHub stars~818 tokensUpdated yesterday
    Auto-check passed
  • Shift Issue Writer

    shift-editor/shift

    Sets the rules for finding, writing and updating Shift GitHub issues: search for duplicates first, use outcome-focused titles and testable acceptance criteria.

    343 GitHub stars~1.4k tokensUpdated yesterday
    Auto-check passed
  • Shift Pull Request Rules

    shift-editor/shift

    Rules for preparing, opening and updating pull requests in the Shift repository: Conventional Commit titles, Release Please effects, evidence-based bodies and UI screenshots.

    343 GitHub stars~2.1k tokensUpdated yesterday
    Auto-check: notes

Works with

Categories

Questions about Shift JSDoc Contracts

What does Shift JSDoc Contracts do?

Guides writing JSDoc for Shift exported APIs as a stable caller contract, covering ownership, lifetime, side effects and nullability that TypeScript types cannot express. Comments must sit directly before the symbol they document and use the /** */ form so tooling can read them. The first sentence is a one-line contract written as a verb phrase ending in a period, never starting with this function, because VS Code hover shows that line in bold.

When should I use Shift JSDoc Contracts?

Shift JSDoc Contracts fits situations like: documenting an exported class or method in the Shift codebase; writing JSDoc for reactive state, render frames or domain data structures; revising comments that describe the implementation instead of the caller's contract; reviewing an API whose ownership, nullability or lifetime is easy to misread.

How do I install Shift JSDoc Contracts in Claude Code?

Run `npx skills add shift-editor/shift --skill jsdoc -a claude-code`. Or copy the skill folder (.codex/skills/jsdoc in shift-editor/shift) into .claude/skills/jsdoc in your project. Claude Code loads it when a task matches its description.

How do I install Shift JSDoc Contracts in Codex?

Run `npx skills add shift-editor/shift --skill jsdoc -a codex`. Or copy the skill folder (.codex/skills/jsdoc in shift-editor/shift) into .agents/skills/jsdoc in your project. Codex loads it when a task matches its description.

Can I use Shift JSDoc Contracts in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add shift-editor/shift --skill jsdoc -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/jsdoc, .gemini/skills/jsdoc, .github/skills/jsdoc and .opencode/skills/jsdoc in your project.

What does Shift JSDoc Contracts need to run?

SKILL.md names no scripts, command-line tools or credentials: Shift JSDoc Contracts is instructions for the agent only.

Does Shift JSDoc Contracts access the network?

SKILL.md names 1 domain. As links in the text: jsdoc.app. This is read from the text; nothing was executed.

Is Shift JSDoc Contracts safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Shift JSDoc Contracts use?

Shift JSDoc Contracts is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Shift JSDoc Contracts use?

About 3.7k tokens (SKILL.md is roughly 15k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Shift JSDoc Contracts?

Skills that share tags, products or a category with Shift JSDoc Contracts: Install Anti-Slop Oxlint Rules (dmmulroy/anti-slop, 5.2k stars), Add Package (remix-run/remix, 33k stars), Code Reviewer (jewbetcha/opentrace, 116 stars) and Coding Standards (kurealnum/dotfiles, 290 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Shift JSDoc Contracts?

shift-editor (a GitHub organization) maintains it in shift-editor/shift, which has 343 GitHub stars. The repository holds 14 skills in this directory. The repository was last updated on October 6, 2026.

Source: shift-editor/shift on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.