New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Generate Doc

by hyodotdev in hyodotdev/openiap

A skill your agent uses for OpenIAP documentation generation work, especially the release-note card each PR carries in packages/docs/src/pages/docs/updates/releases.tsx, written as already published…

MITAuto-check passedDevelopment

Install Generate Doc

skills CLI
$ npx skills add hyodotdev/openiap --skill generate-doc -a claude-code

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

GitHub CLI
$ gh skill install hyodotdev/openiap generate-doc --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/hyodotdev/openiap.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.codex/skills/generate-doc .claude/skills/generate-doc && 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
generate-doc
GitHub stars
154
Token cost
~2.7k tokens
SKILL.md length
1,361 words
Files
2
Skills in repo
19
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses for OpenIAP documentation generation work, especially the release-note card each PR carries in packages/docs/src/pages/docs/updates/releases.tsx, written as already published…

  • Works in 5 steps: Reuse explicit targets already recorded… → Use package metadata that has already… → For an affected package still at its… → …
  • OpenIAP documentation generation work
  • SKILL.md covers Required Reading, Release Note Mode, Existing Unreleased Train and Version Sources, plus 4 more sections
  • Calls bun, git and bunx

What it does

Generate Doc is an agent skill from hyodotdev/openiap. Use for OpenIAP documentation generation work, especially the release-note card each PR carries in packages/docs/src/pages/docs/updates/releases.tsx, written as already published with the expected native and framework versions and their future GitHub Release links, updating an existing unreleased train instead of creating a duplicate.

Its SKILL.md is about 2.7k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files (for example `agents/openai.yaml`).

It sits in Development, covering Changelog and release notes and React components. It works with GitHub. The repository describes itself as: Standardized protocol for in-app purchases across all platforms — backed by Meta & Amazon. The licence is MIT.

When your agent uses it

  • OpenIAP documentation generation work
  • Especially the release-note card each PR carries in packages/docs/src/pages/docs/updates/releases.tsx
  • Written as already published with the expected native and framework versions and their future GitHub Release links
  • Updating an existing unreleased train instead of creating a duplicate

Example prompts

  • “/generate-doc”

Workflow steps

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

  1. Reuse explicit targets already recorded in the existing unreleased card or
  2. Use package metadata that has already advanced beyond the last published
  3. For an affected package still at its last published stable version, classify
  4. Do not bump unaffected packages merely to make a release list symmetrical.
  5. Reuse the explicit maintainer-selected Client Protocol target from the

What it can do on your machine

Read from SKILL.md and the folder at commit 64158e8. 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

    Shell commands in SKILL.md call:

    • bun
    • git
    • bunx
    • npm

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

  • Network

    No URLs in SKILL.md. Its commands use git, bunx and npm, which can reach the network depending on how they are called.

    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

Generate Doc loads about 2.7k tokens when it runs. Until then it costs about 87 tokens; SKILL.md has 1,361 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~87
When it runs · the whole SKILL.md, loaded when a task matches
~2.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 hyodotdev/openiap at commit 64158e8, republished under its MIT licence (© hyodotdev). 1,361 words, ~2,701 tokens.

Download SKILL.mdSave it as .claude/skills/generate-doc/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
generate-doc
description
Use for OpenIAP documentation generation work, especially the release-note card each PR carries in packages/docs/src/pages/docs/updates/releases.tsx, written as already published with the expected native and framework versions and their future GitHub Release links, updating an existing unreleased train instead of creating a duplicate.

Generate OpenIAP Docs

Use this skill when the user asks to generate or update OpenIAP docs, and for the release card every PR into main that changes a published package carries.

Required Reading

Before editing docs, read:

  • AGENTS.md or CLAUDE.md
  • packages/docs/CONVENTION.md
  • knowledge/internal/05-docs-patterns.md
  • knowledge/internal/06-git-deployment.md
  • knowledge/internal/07-docs-consistency.md

If the task also changes package/library behavior, use openiap-workflows and read the package or library convention file before editing that code.

Release Note Mode

A PR into main writes its release card before the release, as already published; "Docs Ship With The Change" in knowledge/internal/05-docs-patterns.md is the canonical rule.

Use knowledge/internal/05-docs-patterns.md#release-note-completeness-gate to inventory the full PR and selected release train. Complete the gate after writing or updating the card, including after scope changes.

RC and npm next releases live on the on-demand next branch and do not get a release-history entry. Gather their changes as source material, but add the consolidated docs entry only when the train is promoted to a stable release on main. Production npm run deploy is stable-only.

Write every card this way:

  • Use Package Releases, not Planned Package Releases.
  • Link expected release/package URLs exactly as the release will publish them.
  • Do not add (planned) labels.
  • Mention the release as publishing or shipping, not as upcoming.
  • State in your response that the links are expected release links until actual deployment is complete.

After the train publishes, compare each version and link with the published releases and correct only what differs.

Existing Unreleased Train

Before adding a release card, inspect the newest entries and package tags.

  • If an existing card describes a release train whose package tags are not all published yet, update that card in place with the new user-visible changes. Do not add another card for the same train.
  • Consolidate overlapping unreleased cards when they describe the same package versions. Preserve their old IDs in the note's pagination-aware alias list and render matching hidden anchors so old deep links select the right page.
  • If an unreleased hosted IAPKit card already exists and companion SDK packages belong to the same release train, expand that card into the single consolidated release entry and advance its date and title. Do not create a second card for the package versions.
  • Use only sections with distinct user-visible behavior or required action. Keep any shared summary first, affected native and framework notes next, migration or integration action after them, and Package Releases at the bottom (see Editing Release Notes).
  • IAPKit and its MCP deploy as services and have no package version. Include their user-visible behavior in the consolidated card, but never invent an IAPKit item in the versioned Package Releases list.
  • Create a new card only when the latest card is already fully published or the new work has an explicitly separate release train.

Version Sources

Never infer framework versions from adjacent release notes or from openiap-versions.json. Read the metadata paths and tag formats from knowledge/internal/06-git-deployment.md#release-docs-version-guard, including the independently versioned Client Protocol, Commerce Protocol, and CLI. Do not derive their versions from native or framework releases.

When workflows will bump versions after the docs are written, resolve expected versions in this order:

  1. Reuse explicit targets already recorded in the existing unreleased card or release plan.
  2. Use package metadata that has already advanced beyond the last published release.
  3. For an affected package still at its last published stable version, classify the public change before resolving its target: use the next patch for backward-compatible fixes, the next minor for backward-compatible features, and the next major for breaking public API or type removals. If the SemVer impact is ambiguous or conflicts with an existing release plan, ask instead of guessing.
  4. Do not bump unaffected packages merely to make a release list symmetrical.
  5. Reuse the explicit maintainer-selected Client Protocol target from the coordinated release plan or unreleased card. If no explicit target exists, ask; never infer one. The note reports the clientProtocol value actually committed in openiap-versions.json, which mirrors specs/client/package.json — so a plan naming a target the manifest does not carry is a stop-and-ask, not a value to compute your way out of.

Before naming any package's next major, inspect the canonical deprecation and migration schedule. The release train must include every public removal already scheduled for that major, or stop for maintainer direction to reschedule the contract; never announce a major while claiming APIs scheduled for that major remain available.

Write every resolved target into the release card with its expected tag link. Do not leave versionless package bullets, (planned) labels, or a Planned Package Releases list. Ask for confirmation only when repository evidence names conflicting target versions or it is unclear whether work belongs to the existing train.

Show full SKILL.md (604 more words)Show less

Editing Release Notes

Release notes live in:

packages/docs/src/pages/docs/updates/releases.tsx

Follow the existing card pattern:

  • Add the newest note near the top of allNotes.

  • Use a stable kebab-case id with the date.

  • Use new Date('YYYY-MM-DD').

  • Use AnchorLink for the heading.

  • Keep package links in a Package Releases list.

  • Name the expected version once per package behavior group and in the linked Package Releases list.

  • Link issues and PRs when they exist.

  • Do not edit packages/docs/src/generated/version-metadata.json manually; it is produced by ./scripts/sync-versions.sh.

  • Register the card's package tags as aliases and render their hidden anchors:

    tsx
    aliases: MY_RELEASES.map((release) => release.tag),
// and, first thing inside the card's <div>:
{MY_RELEASES.map((release) => (
  <span key={release.tag} id={release.tag} aria-hidden="true" />
))}

    Release workflows link a version's own anchor (/docs/updates/releases#godot-iap-3.5.1). The page paginates and resolves a hash only against a note's id or aliases, so a card without them leaves those links on page one — a dead link that still looks alive. bun run audit:docs fails when a card lists Package Releases without them.

Card section layout (mandatory for multi-package cards):

  • Use only the sections that contain distinct user-visible behavior or information readers must act on. When present, keep this order:
    1. Common changes
    2. Protocols and native packages
    3. Framework libraries
    4. Integration notes (or migration notes)
    5. The bordered Package Releases block
  • Never add one h5 heading per platform or framework (no Apple, Google, React Native, Expo, ... headings). Use one parent <li> per package, following the package-specific grouping rule in knowledge/internal/05-docs-patterns.md: put <strong>package version</strong> once, then one inline change or a nested <ul> for multiple changes. Never repeat the package/version label on each nested change.
  • Protocols and native packages holds Client Protocol, Commerce Protocol, openiap-apple, and openiap-google bullets; Framework libraries holds the framework SDK bullets. Omit the section when it would be empty.
  • A package whose only change is selecting a shared native dependency, regenerating types, or republishing the same behavior belongs only in Package Releases. Do not manufacture one boilerplate bullet per wrapper.
  • One bullet may name multiple packages when the same user-visible behavior and caveats apply to all of them. Keep distinct changes in separate nested bullets within their package group.
  • The July 29, 2026 card (openiap-major-api-cleanup-2026-07-29) and the August 4, 2026 card (amazon-rvs-user-data-patch-train-2026-08-04) are the reference implementations of this layout.

Reader-First Writing Standard

Apply the canonical standard in knowledge/internal/05-docs-patterns.md#reader-first-writing-standard to every new or edited release card. Render the result and remove repeated facts, wrapper-only dependency boilerplate, and sections with no reader action.

Multi-package Release Trains

The consolidated release page remains the release-note SSOT, but a release that ships several packages must still be readable package by package. This is the project decision recorded from issue #206.

  • When the user gives a starting commit, inspect that commit inclusively through the latest target branch, then include the current PR diff. Do not derive the release contents only from the PR title or its latest commits.
  • Group notable changes under the affected platform package or framework library, and the independently released protocols, CLI, or hosted service when affected. Omit groups with no user-facing change.
  • Apply the Reader-First Writing Standard above. State the behavior users gain or the regression that was fixed; do not list commit mechanics, version-bump-only commits, generated files, or repeated cross-framework boilerplate.
  • Put truly shared schema or release-process changes in one short shared group, then describe framework-specific wiring or caveats in the relevant framework group.
  • Link the issues and PRs that explain user-visible fixes. Keep package-local changelogs as pointers to this canonical entry unless a registry requires an inline changelog.

Validation

For docs-only release-note edits, run:

bash
# Subshells: a bare `cd` would leave the next line inside packages/docs, where
# the second `cd` fails and the root audits do not resolve.
set -e
(cd packages/docs && bunx prettier --check "src/**/*.{ts,tsx,js,jsx,css,json}")
(cd packages/docs && bun run build)
bun run audit:docs
bun run audit:release-state
git diff --check

If Prettier fails, format only the touched docs files and rerun the checks.

Before committing to main, pull first:

bash
git pull --ff-only origin main

© hyodotdev, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file in .codex/skills/generate-doc of hyodotdev/openiap.

  • SKILL.md
  • agents/openai.yaml

Open the folder on GitHubat commit 64158e8

Compare with similar skills

Generate Doc 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.

Generate Doc compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Generate Doc this skillhyodotdev/openiap154—~2.7kAutomated safety check: PassMIT
Cutting A ReleaseTriliumNext/Trilium38k—~3.2kAutomated safety check: PassAGPL-3.0
Mole CLI Release Flowtw93/Mole69k—~2.5kAutomated safety check: PassGPL-3.0
Draft Release Notesjamiepine/voicebox57k—~941Automated safety check: PassMIT
Mole Release Notes Publishertw93/Mole69k—~1.9kAutomated safety check: PassGPL-3.0
Release Bumpjamiepine/voicebox57k—~1.1kAutomated safety check: PassMIT

Similar skills

  • Cutting A Release

    TriliumNext/Trilium

    A skill your agent uses when cutting, preparing, or debugging a Trilium release — bumping the monorepo version, tagging, or diagnosing a failed "Release" workflow run.

    38k GitHub stars~3.2k tokensUpdated today
    DevelopmentAuto-check passed

  • Mole CLI Release Flow

    tw93/Mole

    Runbook for assessing and executing a Mole CLI release: distribution channels, pre-flight checks, capital-V tags, build artifacts and the handoff to curated release notes.

    69k GitHub stars~2.5k tokensUpdated today
    DevelopmentAuto-check passed

  • Draft Release Notes

    jamiepine/voicebox

    Writes or refreshes the Unreleased section of CHANGELOG.md as a themed narrative built from the commits, PRs and diff since the last version tag.

    57k GitHub stars~941 tokensUpdated today
    DevelopmentAuto-check passed

  • Mole Release Notes Publisher

    tw93/Mole

    Publishes curated, bilingual release notes for an existing Mole version tag with gh release edit, including contributor thanks and reactions, after the release workflow finishes.

    69k GitHub stars~1.9k tokensUpdated today
    DevelopmentAuto-check passed

  • Release Bump

    jamiepine/voicebox

    Ends a release cycle by moving the Unreleased changelog notes under a dated version heading, bumping version files with bumpversion and tagging the commit.

    57k GitHub stars~1.1k tokensUpdated today
    DevelopmentAuto-check passed

  • Cut Release

    jfernandez/bpftop

    Cut a new versioned release of bpftop — pick the version, open a version-bump PR, sign-tag the merge commit on main, and draft GitHub release notes in the project's established format.

    2.7k GitHub stars~2k tokensUpdated 1 mo ago
    DevelopmentAuto-check passed

More from hyodotdev/openiap

All 19 skills in this repo

  • E2E Matrix Runner

    hyodotdev/openiap

    Run the full OpenIAP device matrix — six frameworks across iOS, Google Play, Amazon Appstore, Meta Horizon, and VegaOS — driving real hardware over adb and xcrun, and report one row per cell with…

    154 GitHub stars~3.4k tokensUpdated yesterday
    Auto-check: notes

  • Opencollective Steward

    hyodotdev/openiap

    Manage OpenIAP's OpenCollective presence, including profile copy, slug/link migrations, sponsor/backer recognition, update posts, and README/docs sponsor assets.

    154 GitHub stars~1.5k tokensUpdated yesterday
    Auto-check passed

  • Iapkit E2E Martie

    hyodotdev/openiap

    Run IAPKit local receipt-validation E2E with the dev.hyo.martie React Native or Expo examples, the compiled packages/kit server, real Convex, and Apple or Google sandbox purchases.

    154 GitHub stars~5.4k tokensUpdated yesterday
    Auto-check: notes

  • E2E Matrix Runner Apple

    hyodotdev/openiap

    Run the Apple half of the OpenIAP device matrix — six frameworks plus the native package on iOS — on a physical iPhone and report one row per cell with evidence.

    154 GitHub stars~501 tokensUpdated yesterday
    Auto-check passed

  • E2E Matrix Runner Google

    hyodotdev/openiap

    Run the Android half of the OpenIAP device matrix — six frameworks across Google Play, Amazon Appstore, and Meta Horizon, plus VegaOS — on real hardware and report one row per cell with evidence.

    154 GitHub stars~574 tokensUpdated yesterday
    Auto-check passed

  • Iapkit E2E Petgu

    hyodotdev/openiap

    A skill your agent uses for IAPKit product sync E2E testing in packages/kit with the Petgu React Native app, localhost dashboard, App Store Connect, and Google Play Console.

    154 GitHub stars~1.1k tokensUpdated yesterday
    Auto-check passed

Works with

Categories

Questions about Generate Doc

What does Generate Doc do?

A skill your agent uses for OpenIAP documentation generation work, especially the release-note card each PR carries in packages/docs/src/pages/docs/updates/releases.tsx, written as already published…. Generate Doc is an agent skill from hyodotdev/openiap.tsx, written as already published with the expected native and framework versions and their future GitHub Release links, updating an existing unreleased train instead of creating a duplicate.

When should I use Generate Doc?

Generate Doc fits situations like: openIAP documentation generation work; especially the release-note card each PR carries in packages/docs/src/pages/docs/updates/releases.tsx; written as already published with the expected native and framework versions and their future GitHub Release links; updating an existing unreleased train instead of creating a duplicate.

How do I install Generate Doc in Claude Code?

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

How do I install Generate Doc in Codex?

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

Can I use Generate Doc 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 hyodotdev/openiap --skill generate-doc -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/generate-doc, .gemini/skills/generate-doc, .github/skills/generate-doc and .opencode/skills/generate-doc in your project.

What does Generate Doc need to run?

Going by SKILL.md and its folder, Generate Doc needs the command-line tools its instructions call (bun, git, bunx and npm).

Does Generate Doc access the network?

SKILL.md contains no URLs. Its commands use git and npm, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Generate Doc 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 Generate Doc use?

Generate Doc is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Generate Doc use?

About 2.7k tokens (SKILL.md is roughly 11k 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 Generate Doc?

Skills that share tags, products or a category with Generate Doc: Cutting A Release (TriliumNext/Trilium, 38k stars), Mole CLI Release Flow (tw93/Mole, 69k stars), Draft Release Notes (jamiepine/voicebox, 57k stars) and Mole Release Notes Publisher (tw93/Mole, 69k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Generate Doc?

hyodotdev (a GitHub organization) maintains it in hyodotdev/openiap, which has 154 GitHub stars. The repository holds 19 skills in this directory. The repository was last updated on October 6, 2026.

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