[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71J3TPFQ1NG2F97B37PXRJY":3,"skill-same:01M71J3TPFQ1NG2F97B37PXRJY":68},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":13,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":47,"install":48,"resources":61},"01M71J3TPFQ1NG2F97B37PXRJY","release",null,"Detects release-please PRs (`gh pr list --author app\u002Frelease-please --state open`), validates them against a fixed checklist (SemVer consistency between version bump and included commit types — feat→minor \u002F fix→patch \u002F `!` or BREAKING CHANGE→major —, CHANGELOG consistency, CI all green), then merges via `gh pr merge --squash` through an approval gate by default (externally visible \u002F effectively irreversible). After merging, it monitors the publish workflow via polling (30s interval, 20-minute cap) and confirms rollout with `npm view \u003Cpkg> version` (npm-distributed repos only). `--auto` skips the gate only when all validations pass (stops if any fail). npm publish assumes OIDC Trusted Publishers (no `NPM_TOKEN` used).","ozzy-labs\u002Fskills","ozzy-labs","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F246109093?v=4","01M6H0M2K2PZXHWNHJJTWY20FY","01M71J2B6FZ5KPEXPR5VS1TX7Z",0,"MIT","https:\u002F\u002Fgithub.com\u002Fozzy-labs\u002Fskills\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease\u002FSKILL.md",[],[5,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"open","change","publish","commit","patch","workflow","rollout","when","auto","only","ci","fix","gh pr","default","bump","green","pr merge","types","app","2026-11-10 10:12:30",false,"---\nname: release\ndescription: Detects release-please PRs (`gh pr list --author app\u002Frelease-please --state open`), validates them against a fixed checklist (SemVer consistency between version bump and included commit types — feat→minor \u002F fix→patch \u002F `!` or BREAKING CHANGE→major —, CHANGELOG consistency, CI all green), then merges via `gh pr merge --squash` through an approval gate by default (externally visible \u002F effectively irreversible). After merging, it monitors the publish workflow via polling (30s interval, 20-minute cap) and confirms rollout with `npm view \u003Cpkg> version` (npm-distributed repos only). `--auto` skips the gate only when all validations pass (stops if any fail). npm publish assumes OIDC Trusted Publishers (no `NPM_TOKEN` used).\n---\n\n# release - Validate release-please PR → gated merge → publish monitoring\n\nThe stage from merged onward to distribution (handling release-please PRs, monitoring npm OIDC publish) had not been turned into a skill, so it reverted to manual work every time at release. There was also no path to close health's draft release `要対応` (area 14). This skill unifies that whole sequence: it detects release-please PRs, validates them against a fixed checklist, merges them through an **approval gate by default**, and monitors the publish workflow through to confirming the npm rollout.\n\nReleases are **externally visible and effectively irreversible** (a published version cannot be withdrawn), so the judgment is confined to a fixed checklist (deterministic) — Claude does not merge on its own just because it \"looks good\". The approval gate follows the central autonomy policy (the `policy` skill's `irreversible` gate).\n\n**Scope**: Validating, merging, and monitoring publish for release-please PRs in a single repository. automation dependency PRs (renovate \u002F dependabot) are the responsibility of `\u002Fdeps`; PRs other than release-please are out of scope. cross-repo is a future consideration.\n\n## Input\n\n```text\nrelease\n  --repo owner\u002Frepo   (resolved from cwd's origin if omitted)\n  --auto              (skips the approval gate only when all validations pass. Even with --auto, stops when validation fails)\n```\n\n- `--auto` is an opt-in for routine \u002F `\u002Floop` \u002F `schedule` integration. Since unattended runs can't be interactive, the **fixed checklist** (below) and the policy gate are the only boundary.\n- Even with `--auto`, **if even one validation fails, it will not merge** (see \"Approval gate\" below). Since releases are irreversible, `--auto` only \"skips human confirmation\" — it does not \"skip validation\".\n\n## Procedure\n\n### 1. Detection\n\n```bash\ngh pr list --author app\u002Frelease-please --state open --json number,title,url,headRefName\n```\n\n- **If 0 results**: present \"No releases pending\" and also **note whether any draft release exists** (equivalent to visualizing health area 14):\n\n  ```bash\n  gh release list --limit 10   # note any entries where the draft column is true\n  ```\n\n  If a draft release remains, report \"There is an unpublished draft release\" (if there's a draft but no release-please PR, this may indicate a manual release or a workflow failure).\n\n- **If 1 or more**: proceed to the validation in step 2 for each PR. Normally there is one release-please PR per repo. If there are multiple, handle them one at a time.\n- **Fallback**: There are also configurations where, with 0 results for `app\u002Frelease-please` as author, `github-actions[bot]` posts on behalf of the release-please-action. In that case, check whether it's a release-please PR by the title (e.g. `chore(main): release \u003Cversion>`) and the `changelog-path` diff.\n\n### 2. Validation checklist (fixed, deterministic)\n\nCheck **every item** in the table below. If even one fails, treat it as \"validation failed\", do not proceed to merge, and present the failing item(s) and stop (stops even with `--auto`).\n\n| # | Item | Pass condition |\n| --- | --- | --- |\n| 1 | **SemVer consistency** | The PR's version bump matches the expected bump derived from the included commit types (see \"SemVer consistency rules\" below) |\n| 2 | **CHANGELOG consistency** | The CHANGELOG entry reflects the included commits without excess or omission (no added commits are missing \u002F no nonexistent entries) |\n| 3 | **CI all green** | All checks on the PR are green (`gh pr checks \u003CN>`. fail \u002F cancel → red, running \u002F queued → pending. Either is treated as a failure) |\n\nHow to obtain the material:\n\n- **Included commits**: `gh pr view \u003CN> --json commits`, or `git log origin\u002Fmain..\u003CheadRefName>`. Extract each commit's Conventional Commits type (`feat` \u002F `fix` \u002F `perf` \u002F …) and any `!` \u002F `BREAKING CHANGE` in the body.\n- **Version bump**: Determine from the PR title (`chore(main): release \u003Cversion>`), the from→to in `.release-please-manifest.json`, and the version diff in `package.json`.\n- **CHANGELOG**: Cross-check the PR's `CHANGELOG.md` diff against the included commits (of types that trigger a release) for excess or omission.\n- **CI**: `gh pr checks \u003CN>`. If even one is not green, it's a failure.\n\n#### SemVer consistency rules (deterministic rules that can be turned into fixtures)\n\nDetermine the **expected bump** from the set of included commit types, in the following priority order (major > minor > patch > none):\n\n| Condition of included commits | Expected bump |\n| --- | --- |\n| Any has `!` (e.g. `feat!:`) or `BREAKING CHANGE` in the body | **major** |\n| (no breaking) any has `feat` | **minor** |\n| (no breaking \u002F feat) any has `fix` or `perf` | **patch** |\n| No type that triggers a release exists at all (only `docs` \u002F `chore` \u002F `refactor` \u002F `test` \u002F `style` \u002F `ci` \u002F `build`) | **none** (no release PR is raised at all) |\n\nThis rule is deterministic, and `tests\u002Frelease.test.mjs` reimplements and pins it with fixtures (commit type list → expected bump, including `!` \u002F BREAKING CHANGE). If the rules are added to or reduced, revise this table and the test together (do not add conditions on Claude's own judgment).\n\n> **Note on pre-1.0 (specific to this repo):** For 0.x packages where `release-please-config.json` sets `bump-minor-pre-major: true` \u002F `bump-patch-for-minor-pre-major: true`, breaking→minor \u002F feat→patch is **downgraded** while at `0.y.z` (the SemVer convention of treating breaking changes as minor before 1.0.0). When validating, check whether the target package's current major is 0, and if so, cross-check against the downgraded expected bump. The standard rules in the table above apply to major ≥ 1.\n\n### 3. Approval gate (follows the central autonomy policy)\n\n`gh pr merge --squash` is an **irreversible action**. Rather than hardcoding an individual gate in prose, it follows the central autonomy policy (the SSOT of the 3 classes \u002F gate vocabulary defined by the `policy` skill). Classification and zero-config default:\n\n| This skill's action | Class | policy reference | Zero-config default gate |\n| --- | --- | --- | --- |\n| release PR merge (`gh pr merge --squash`) | `irreversible` | `--action=merge` | `ask` (maintain the approval gate) |\n\nThe effective gate is looked up via the sibling `policy` skill's `policy-read.mjs` (user-scope: `~\u002F.claude\u002Fskills\u002Fpolicy\u002Fpolicy-read.mjs`, dogfood: `\u003Crepo>\u002F.claude\u002Fskills\u002Fpolicy\u002Fpolicy-read.mjs`, Codex\u002FGemini: `.agents\u002Fskills\u002Fpolicy\u002Fpolicy-read.mjs`):\n\n```bash\nnode \u003Cpolicy skill directory>\u002Fpolicy-read.mjs --action=merge --repo-root=\"$PWD\"\n# => .resolved.gate (default ask)\n```\n\nThe behavior is determined by the combination of the validation result and `--auto`:\n\n- **Validation failed (even one item)**: does not merge. Presents the failing item(s) and stops. Same with `--auto` (since releases are irreversible, validation cannot be skipped).\n- **All validations pass + `--auto` not specified** (default): presents a validation result summary (version \u002F key changes \u002F checklist pass status) and follows the policy gate:\n  - gate=`ask` (zero-config default): requests approval, and only executes `gh pr merge \u003CN> --squash` if approved.\n  - gate=`batch-confirm`: presents the summary once for a single batch confirmation → merge on approval.\n  - gate=`proceed`: merges without confirmation.\n- **All validations pass + `--auto` specified**: **skips the approval gate** and executes `gh pr merge \u003CN> --squash` directly (explicit opt-out of the irreversible gate).\n\n**Does not break even without policy present:** `policy-read.mjs` is fail-safe by design — if it can't be read, or the value is invalid, it defaults to the stricter side (`ask`). In environments where the `policy` skill is not installed, apply the zero-config default gate in the table above directly (`irreversible`=`ask`).\n\n### 4. Monitoring the publish workflow\n\nAfter merging, identify and poll the corresponding release workflow run (**npm-distributed repos only**. For repos without a publish workflow, go to step 6):\n\n```bash\n# Identify the release workflow run triggered after the merge (e.g. name=Release)\ngh run list --workflow release.yaml --branch main --limit 5 --json databaseId,status,conclusion,headSha,createdAt\n\n# Poll the identified run until it's green (success)\ngh run view \u003Crun-id> --json status,conclusion,jobs\n```\n\n- **30-second polling interval, 20-minute cap** (max 40 iterations). If the cap is reached, present it as a \"workflow monitoring timeout\" with the run URL and prompt for a subsequent manual check.\n- Once the workflow becomes `success`, confirm the rollout to npm with `npm view \u003Cpkg> version` (`\u003Cpkg>` is the `name` in `package.json`, e.g. `npm view @ozzylabs\u002Fskills version`). If it matches the PR's version, **distribution is complete**.\n- If the workflow becomes `failure`, proceed to the failure guidance in step 5.\n\nPublishing for this repo is via OIDC Trusted Publishers (the `publish` job in `release.yaml` is gated by `needs: release-please` + `if: release_created`, and issued via `npm publish --provenance --access public`). See the \"Prerequisites\" section for details.\n\n### 5. Guidance on failure\n\nIf the publish workflow is `failure`, summarize the failure log and give guidance on the cause (automatic fixing is out of scope):\n\n```bash\ngh run view \u003Crun-id> --log-failed   # fetch and summarize only the log of the failed step\n```\n\nCommon causes (in the OIDC Trusted Publishers context):\n\n| Symptom | Cause | Guidance |\n| --- | --- | --- |\n| `403 Forbidden — you don't have permission` | **Trusted Publisher not registered** \u002F mismatch of workflow filename \u002F repo name | Check Settings → Publishing on npmjs.com |\n| `OIDC token not available` | **`permissions: id-token: write` missing** on the workflow \u002F job | Add the permissions |\n| provenance is not attached | publish from a private repo \u002F CircleCI (provenance unsupported) | Check for a GitHub-hosted runner + public repo |\n| npm CLI is outdated | npm CLI below v11.5.1 \u002F Node below 22.14 | Check `npm install -g npm@latest` |\n\nAutomatic fixing is out of scope for this skill. If a CI rerun or fix is needed, note that it can be connected to `\u002Fci-fix` etc.\n\n### 6. Branch for repos without a publish workflow\n\nFor repos that don't have a distributed artifact (no npm publish workflow), completion is defined as **merge + confirming the tag \u002F GitHub Release**:\n\n```bash\ngh release list --limit 5     # check the Release \u002F tag created by release-please\n```\n\nIf the tag and GitHub Release were created by the release-please merge, it's complete. Do not perform the npm rollout confirmation (the `npm view` in step 4).\n\n## Prerequisites: npm publish uses OIDC Trusted Publishers\n\n- npm publish uses **OIDC Trusted Publishers** (per the policy in knowledge `standards\u002Fnpm-trusted-publishers`). It **does not use** a long-lived **`NPM_TOKEN`** (due to leak risk and rotation burden).\n- The publish workflow has `permissions: id-token: write` and automatically attaches attestation via `--provenance` (verifiable with `npm view \u003Cpkg> dist.attestations`).\n- Note that **publishing from a private repo does not attach provenance even for a public package** (to keep the source link private).\n\n## Error handling\n\n| Situation | Behavior |\n| --- | --- |\n| `--repo` not specified and no GitHub remote | Present an error and prompt to specify `--repo owner\u002Frepo` explicitly. Does not merge |\n| `gh` not authenticated \u002F rate limit \u002F network | Present an error and abort (does not proceed to merge or publish monitoring) |\n| 0 release-please PRs | End with \"No releases pending\" + noting whether a draft release exists |\n| Validation failed (any of SemVer \u002F CHANGELOG \u002F CI) | Present the failing item(s) and stop (does not merge). Stops even with `--auto` |\n| Merge failure (branch protection, etc.) | Present the failure. Prompt for manual merge |\n| Publish workflow timeout (20 min) | Present the run URL and prompt for manual confirmation |\n| Publish workflow failure | Summary of `gh run view --log-failed` + guidance on common causes |\n\n## Out of scope\n\n| Item | Reason for exclusion |\n| --- | --- |\n| 1. automation dependency PRs (renovate \u002F dependabot) | Responsibility of `\u002Fdeps`. This skill handles only release-please PRs |\n| 2. Loosening the judgment criteria | Validation is only the fixed checklist. Does not decide mergeability by the LLM's free judgment (for reproducibility and the irreversibility of releases) |\n| 3. Automatic fixing of publish failures | Only up through log summary + cause guidance. Fixing is connected to `\u002Fci-fix` etc. |\n| 4. cross-repo release | Currently single-repo only |\n| 5. Generation of the release-please PR itself | Responsibility of release-please-action (CI). This skill only validates, merges, and monitors the generated PR |\n\n## Notes\n\n- Do not read or stage `.env` files.\n- Releases are externally visible and effectively irreversible. Maintain the approval gate by default (`irreversible`=`ask`). `--auto` is an explicit opt-out, but **even with `--auto`, it stops when validation fails**.\n- Validation is judged only by the fixed checklist (SemVer consistency \u002F CHANGELOG \u002F CI green). Claude does not re-judge (when in doubt, stop).\n- npm publish uses OIDC Trusted Publishers (no `NPM_TOKEN` used).\n- Do not add new runtime dependencies (Node stdlib + `gh` \u002F `git` \u002F `npm` only).\n","# release - Validate release-please PR → gated merge → publish monitoring\n\nThe stage from merged onward to distribution (handling release-please PRs, monitoring npm OIDC publish) had not been turned into a skill, so it reverted to manual work every time at release. There was also no path to close health's draft release `要対応` (area 14). This skill unifies that whole sequence: it detects release-please PRs, validates them against a fixed checklist, merges them through an **approval gate by default**, and monitors the publish workflow through to confirming the npm rollout.\n\nReleases are **externally visible and effectively irreversible** (a published version cannot be withdrawn), so the judgment is confined to a fixed checklist (deterministic) — Claude does not merge on its own just because it \"looks good\". The approval gate follows the central autonomy policy (the `policy` skill's `irreversible` gate).\n\n**Scope**: Validating, merging, and monitoring publish for release-please PRs in a single repository. automation dependency PRs (renovate \u002F dependabot) are the responsibility of `\u002Fdeps`; PRs other than release-please are out of scope. cross-repo is a future consideration.\n\n## Input\n\n```text\nrelease\n  --repo owner\u002Frepo   (resolved from cwd's origin if omitted)\n  --auto              (skips the approval gate only when all validations pass. Even with --auto, stops when validation fails)\n```\n\n- `--auto` is an opt-in for routine \u002F `\u002Floop` \u002F `schedule` integration. Since unattended runs can't be interactive, the **fixed checklist** (below) and the policy gate are the only boundary.\n- Even with `--auto`, **if even one validation fails, it will not merge** (see \"Approval gate\" below). Since releases are irreversible, `--auto` only \"skips human confirmation\" — it does not \"skip validation\".\n\n## Procedure\n\n### 1. Detection\n\n```bash\ngh pr list --author app\u002Frelease-please --state open --json number,title,url,headRefName\n```\n\n- **If 0 results**: present \"No releases pending\" and also **note whether any draft release exists** (equivalent to visualizing health area 14):\n\n  ```bash\n  gh release list --limit 10   # note any entries where the draft column is true\n  ```\n\n  If a draft release remains, report \"There is an unpublished draft release\" (if there's a draft but no release-please PR, this may indicate a manual release or a workflow failure).\n\n- **If 1 or more**: proceed to the validation in step 2 for each PR. Normally there is one release-please PR per repo. If there are multiple, handle them one at a time.\n- **Fallback**: There are also configurations where, with 0 results for `app\u002Frelease-please` as author, `github-actions[bot]` posts on behalf of the release-please-action. In that case, check whether it's a release-please PR by the title (e.g. `chore(main): release \u003Cversion>`) and the `changelog-path` diff.\n\n### 2. Validation checklist (fixed, deterministic)\n\nCheck **every item** in the table below. If even one fails, treat it as \"validation failed\", do not proceed to merge, and present the failing item(s) and stop (stops even with `--auto`).\n\n| # | Item | Pass condition |\n| --- | --- | --- |\n| 1 | **SemVer consistency** | The PR's version bump matches the expected bump derived from the included commit types (see \"SemVer consistency rules\" below) |\n| 2 | **CHANGELOG consistency** | The CHANGELOG entry reflects the included commits without excess or omission (no added commits are missing \u002F no nonexistent entries) |\n| 3 | **CI all green** | All checks on the PR are green (`gh pr checks \u003CN>`. fail \u002F cancel → red, running \u002F queued → pending. Either is treated as a failure) |\n\nHow to obtain the material:\n\n- **Included commits**: `gh pr view \u003CN> --json commits`, or `git log origin\u002Fmain..\u003CheadRefName>`. Extract each commit's Conventional Commits type (`feat` \u002F `fix` \u002F `perf` \u002F …) and any `!` \u002F `BREAKING CHANGE` in the body.\n- **Version bump**: Determine from the PR title (`chore(main): release \u003Cversion>`), the from→to in `.release-please-manifest.json`, and the version diff in `package.json`.\n- **CHANGELOG**: Cross-check the PR's `CHANGELOG.md` diff against the included commits (of types that trigger a release) for excess or omission.\n- **CI**: `gh pr checks \u003CN>`. If even one is not green, it's a failure.\n\n#### SemVer consistency rules (deterministic rules that can be turned into fixtures)\n\nDetermine the **expected bump** from the set of included commit types, in the following priority order (major > minor > patch > none):\n\n| Condition of included commits | Expected bump |\n| --- | --- |\n| Any has `!` (e.g. `feat!:`) or `BREAKING CHANGE` in the body | **major** |\n| (no breaking) any has `feat` | **minor** |\n| (no breaking \u002F feat) any has `fix` or `perf` | **patch** |\n| No type that triggers a release exists at all (only `docs` \u002F `chore` \u002F `refactor` \u002F `test` \u002F `style` \u002F `ci` \u002F `build`) | **none** (no release PR is raised at all) |\n\nThis rule is deterministic, and `tests\u002Frelease.test.mjs` reimplements and pins it with fixtures (commit type list → expected bump, including `!` \u002F BREAKING CHANGE). If the rules are added to or reduced, revise this table and the test together (do not add conditions on Claude's own judgment).\n\n> **Note on pre-1.0 (specific to this repo):** For 0.x packages where `release-please-config.json` sets `bump-minor-pre-major: true` \u002F `bump-patch-for-minor-pre-major: true`, breaking→minor \u002F feat→patch is **downgraded** while at `0.y.z` (the SemVer convention of treating breaking changes as minor before 1.0.0). When validating, check whether the target package's current major is 0, and if so, cross-check against the downgraded expected bump. The standard rules in the table above apply to major ≥ 1.\n\n### 3. Approval gate (follows the central autonomy policy)\n\n`gh pr merge --squash` is an **irreversible action**. Rather than hardcoding an individual gate in prose, it follows the central autonomy policy (the SSOT of the 3 classes \u002F gate vocabulary defined by the `policy` skill). Classification and zero-config default:\n\n| This skill's action | Class | policy reference | Zero-config default gate |\n| --- | --- | --- | --- |\n| release PR merge (`gh pr merge --squash`) | `irreversible` | `--action=merge` | `ask` (maintain the approval gate) |\n\nThe effective gate is looked up via the sibling `policy` skill's `policy-read.mjs` (user-scope: `~\u002F.claude\u002Fskills\u002Fpolicy\u002Fpolicy-read.mjs`, dogfood: `\u003Crepo>\u002F.claude\u002Fskills\u002Fpolicy\u002Fpolicy-read.mjs`, Codex\u002FGemini: `.agents\u002Fskills\u002Fpolicy\u002Fpolicy-read.mjs`):\n\n```bash\nnode \u003Cpolicy skill directory>\u002Fpolicy-read.mjs --action=merge --repo-root=\"$PWD\"\n# => .resolved.gate (default ask)\n```\n\nThe behavior is determined by the combination of the validation result and `--auto`:\n\n- **Validation failed (even one item)**: does not merge. Presents the failing item(s) and stops. Same with `--auto` (since releases are irreversible, validation cannot be skipped).\n- **All validations pass + `--auto` not specified** (default): presents a validation result summary (version \u002F key changes \u002F checklist pass status) and follows the policy gate:\n  - gate=`ask` (zero-config default): requests approval, and only executes `gh pr merge \u003CN> --squash` if approved.\n  - gate=`batch-confirm`: presents the summary once for a single batch confirmation → merge on approval.\n  - gate=`proceed`: merges without confirmation.\n- **All validations pass + `--auto` specified**: **skips the approval gate** and executes `gh pr merge \u003CN> --squash` directly (explicit opt-out of the irreversible gate).\n\n**Does not break even without policy present:** `policy-read.mjs` is fail-safe by design — if it can't be read, or the value is invalid, it defaults to the stricter side (`ask`). In environments where the `policy` skill is not installed, apply the zero-config default gate in the table above directly (`irreversible`=`ask`).\n\n### 4. Monitoring the publish workflow\n\nAfter merging, identify and poll the corresponding release workflow run (**npm-distributed repos only**. For repos without a publish workflow, go to step 6):\n\n```bash\n# Identify the release workflow run triggered after the merge (e.g. name=Release)\ngh run list --workflow release.yaml --branch main --limit 5 --json databaseId,status,conclusion,headSha,createdAt\n\n# Poll the identified run until it's green (success)\ngh run view \u003Crun-id> --json status,conclusion,jobs\n```\n\n- **30-second polling interval, 20-minute cap** (max 40 iterations). If the cap is reached, present it as a \"workflow monitoring timeout\" with the run URL and prompt for a subsequent manual check.\n- Once the workflow becomes `success`, confirm the rollout to npm with `npm view \u003Cpkg> version` (`\u003Cpkg>` is the `name` in `package.json`, e.g. `npm view @ozzylabs\u002Fskills version`). If it matches the PR's version, **distribution is complete**.\n- If the workflow becomes `failure`, proceed to the failure guidance in step 5.\n\nPublishing for this repo is via OIDC Trusted Publishers (the `publish` job in `release.yaml` is gated by `needs: release-please` + `if: release_created`, and issued via `npm publish --provenance --access public`). See the \"Prerequisites\" section for details.\n\n### 5. Guidance on failure\n\nIf the publish workflow is `failure`, summarize the failure log and give guidance on the cause (automatic fixing is out of scope):\n\n```bash\ngh run view \u003Crun-id> --log-failed   # fetch and summarize only the log of the failed step\n```\n\nCommon causes (in the OIDC Trusted Publishers context):\n\n| Symptom | Cause | Guidance |\n| --- | --- | --- |\n| `403 Forbidden — you don't have permission` | **Trusted Publisher not registered** \u002F mismatch of workflow filename \u002F repo name | Check Settings → Publishing on npmjs.com |\n| `OIDC token not available` | **`permissions: id-token: write` missing** on the workflow \u002F job | Add the permissions |\n| provenance is not attached | publish from a private repo \u002F CircleCI (provenance unsupported) | Check for a GitHub-hosted runner + public repo |\n| npm CLI is outdated | npm CLI below v11.5.1 \u002F Node below 22.14 | Check `npm install -g npm@latest` |\n\nAutomatic fixing is out of scope for this skill. If a CI rerun or fix is needed, note that it can be connected to `\u002Fci-fix` etc.\n\n### 6. Branch for repos without a publish workflow\n\nFor repos that don't have a distributed artifact (no npm publish workflow), completion is defined as **merge + confirming the tag \u002F GitHub Release**:\n\n```bash\ngh release list --limit 5     # check the Release \u002F tag created by release-please\n```\n\nIf the tag and GitHub Release were created by the release-please merge, it's complete. Do not perform the npm rollout confirmation (the `npm view` in step 4).\n\n## Prerequisites: npm publish uses OIDC Trusted Publishers\n\n- npm publish uses **OIDC Trusted Publishers** (per the policy in knowledge `standards\u002Fnpm-trusted-publishers`). It **does not use** a long-lived **`NPM_TOKEN`** (due to leak risk and rotation burden).\n- The publish workflow has `permissions: id-token: write` and automatically attaches attestation via `--provenance` (verifiable with `npm view \u003Cpkg> dist.attestations`).\n- Note that **publishing from a private repo does not attach provenance even for a public package** (to keep the source link private).\n\n## Error handling\n\n| Situation | Behavior |\n| --- | --- |\n| `--repo` not specified and no GitHub remote | Present an error and prompt to specify `--repo owner\u002Frepo` explicitly. Does not merge |\n| `gh` not authenticated \u002F rate limit \u002F network | Present an error and abort (does not proceed to merge or publish monitoring) |\n| 0 release-please PRs | End with \"No releases pending\" + noting whether a draft release exists |\n| Validation failed (any of SemVer \u002F CHANGELOG \u002F CI) | Present the failing item(s) and stop (does not merge). Stops even with `--auto` |\n| Merge failure (branch protection, etc.) | Present the failure. Prompt for manual merge |\n| Publish workflow timeout (20 min) | Present the run URL and prompt for manual confirmation |\n| Publish workflow failure | Summary of `gh run view --log-failed` + guidance on common causes |\n\n## Out of scope\n\n| Item | Reason for exclusion |\n| --- | --- |\n| 1. automation dependency PRs (renovate \u002F dependabot) | Responsibility of `\u002Fdeps`. This skill handles only release-please PRs |\n| 2. Loosening the judgment criteria | Validation is only the fixed checklist. Does not decide mergeability by the LLM's free judgment (for reproducibility and the irreversibility of releases) |\n| 3. Automatic fixing of publish failures | Only up through log summary + cause guidance. Fixing is connected to `\u002Fci-fix` etc. |\n| 4. cross-repo release | Currently single-repo only |\n| 5. Generation of the release-please PR itself | Responsibility of release-please-action (CI). This skill only validates, merges, and monitors the generated PR |\n\n## Notes\n\n- Do not read or stage `.env` files.\n- Releases are externally visible and effectively irreversible. Maintain the approval gate by default (`irreversible`=`ask`). `--auto` is an explicit opt-out, but **even with `--auto`, it stops when validation fails**.\n- Validation is judged only by the fixed checklist (SemVer consistency \u002F CHANGELOG \u002F CI green). Claude does not re-judge (when in doubt, stop).\n- npm publish uses OIDC Trusted Publishers (no `NPM_TOKEN` used).\n- Do not add new runtime dependencies (Node stdlib + `gh` \u002F `git` \u002F `npm` only).\n",{"name":5,"description":7},"main","db212a47efe751fa1c42bd76e61dbfd8328e5b10",".agents\u002Fskills\u002Frelease","https:\u002F\u002Fgithub.com\u002Fozzy-labs\u002Fskills","https:\u002F\u002Fgithub.com\u002Fozzy-labs","2026-07-13 06:49:42",{"source":8,"skillName":5,"commands":49,"prompt":59,"zipAvailable":60},[50,53,56],{"tool":51,"command":52},"npx","npx skills add ozzy-labs\u002Fskills --skill release",{"tool":54,"command":55},"bunx","bunx skills add ozzy-labs\u002Fskills --skill release",{"tool":57,"command":58},"pnpm","pnpm dlx skills add ozzy-labs\u002Fskills --skill release","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fozzy-labs\u002Fskills\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease\u002FSKILL.md",true,[62],{"path":63,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":66,"sourceHtmlUrl":67},"SKILL.claude-code.md","REFERENCE","参考文档",3420,"https:\u002F\u002Fgithub.com\u002Fozzy-labs\u002Fskills\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease\u002FSKILL.claude-code.md",[69,93,118,139,171,193],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":37},"01M71J6R63H4E6ZE6KMDM4CT85","verify","An integrated skill that runs the combined validation of build \u002F typecheck \u002F test \u002F lint in one shot. The `verify.mjs` engine auto-discovers validation commands via a discovery chain (AGENTS.md's 「検証」 section → package.json scripts → justfile\u002FMakefile\u002Flefthook → language heuristics), executes them serially with their source attached, and returns a result summary. If a higher-priority stage produces a hit, only that stage is executed (no crossing stages).","https:\u002F\u002Fgithub.com\u002Fozzy-labs\u002Fskills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fverify\u002FSKILL.md",[],[71,76,77,78,79,80,81,82,27,26,83,84,85,86,87,88,89,90,91,92],"combined","heuristics","chain","repo","discovery","section","lefthook","package","stage","Bash","one","lint","dry","engine","with","test","typecheck",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":37},"01M71J6JW7SAY9PDKAWHG3SJCR","usage-guard","Monitors Claude Code's Usage Limit (5-hour = Current \u002F weekly = Weekly), pauses work when it exceeds 95%, and automatically resumes once the reset restores headroom. Bundles an engine form that a caller such as drive Reads at a checkpoint, and a standalone form, `\u002Fusage-guard \"\u003Ccontinuation command>\"`, that guards arbitrary work. Claude-only (depends on the OAuth usage-rate endpoint + ScheduleWakeup).","https:\u002F\u002Fgithub.com\u002Fozzy-labs\u002Fskills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fusage-guard\u002FSKILL.md",[],[100,101,102,103,104,27,105,25,106,107,108,109,110,111,112,113,114,115,116,117],"usage","usage guard","guard","weekly","standalone","guards","code","reset","work","command","at","rate","status","endpoint","as","continuation","form","limit",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"publishedAt":37},"01M71J6FRG119REA1G0S99Q4GZ","topics","Selects GitHub topic candidates by having the `topics.mjs` engine perform constraint validation, popularity measurement, broad+narrow \u002F singular-plural comparison, and hardcoded ozzy-labs conventions, then applies them via `gh repo edit --add-topic` following the policy's `externally-visible` gate (default batch-confirm). Scope is limited to use within ozzy-labs.","https:\u002F\u002Fgithub.com\u002Fozzy-labs\u002Fskills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftopics\u002FSKILL.md",[],[120,125,126,79,127,31,128,129,130,131,132,85,133,134,135,88,89,136,137,138],"measurement","scope","policy","true","gh","plural","use","comparison","apply","candidate","batch","candidates","github","via",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":155,"publishedAt":37},"01M71J6DC27P4FDSP10SDT2PSN","skill-observability","Defines the skill observability event contract (event.schema.json) and emit substrate (obs-emit.mjs). The SSOT for the measurement layer of the skill improvement loop. Referenced by other skills and hooks.","https:\u002F\u002Fgithub.com\u002Fozzy-labs\u002Fskills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fskill-observability\u002FSKILL.md",[145,150],{"categoryNo":146,"categoryName":147,"taxonomyType":148,"taxonomyTypeDesc":149},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":151,"categoryName":152,"taxonomyType":153,"taxonomyTypeDesc":154},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[156,157,125,158,159,160,161,162,163,164,165,166,167,168,169,170],"observability","skill observability","improvement","skill improvement","for","event","hooks","contract","schema","loop","false","substrate","json","improvement loop","layer",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":178,"publishedAt":37},"01M71J6AYECH1J94RAZ49QZ19Y","skill-metrics","Aggregates the local observability event log (~\u002F.agents\u002Fobservability\u002Fevents.jsonl) and presents, read-only, per-skill invocation counts and notable events (fallback \u002F HITL rejection \u002F loop cap reached \u002F abort). Fires on \"show me the skill metrics,\" \"aggregate the observability results,\" \"which skills get used the most?\" Does not send anything.","https:\u002F\u002Fgithub.com\u002Fozzy-labs\u002Fskills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fskill-metrics\u002FSKILL.md",[177],{"categoryNo":146,"categoryName":147,"taxonomyType":148,"taxonomyTypeDesc":149},[179,180,156,181,182,183,184,185,161,186,187,188,189,128,27,165,190,85,191,192],"skill metrics","metrics","event log","which","show","get","read-only","iso","aggregates","send","local","show me","log","jsonl",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":199,"publishedAt":37},"01M71J68TD0QFATGW3BBZVCWA2","ship","Runs verification, commit, and PR creation all at once. An integrated pipeline that runs verify (build + type + test + lint) → commit → PR creation in sequence against the changes.","https:\u002F\u002Fgithub.com\u002Fozzy-labs\u002Fskills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fship\u002FSKILL.md",[],[195,200,201,91,202,203,71,204,205,206,110,207,208,209,128,210,85,21,87],"type","verification","changes","pr","creation","build","pipeline","read","sequence","grep","pr creation"]