本文へ移動
cccskills
無料GitHub で公開

release-publish

Release, publish, CalVer tag push, npm publish, 배포, 릴리즈 for senpi. Use for the canonical release flow, GitHub tag/release publication, and npm publishing.

code-yeongyu/senpi
インストール方法を見る

含まれるファイル（1）

  • SKILL.md6.5 KB

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Release Publish

Use this skill when releasing senpi with the canonical CalVer flow, pushing a release tag, publishing the GitHub Release, or publishing packages to npm.

Canonical release flow

Run scripts/release.mjs from a clean main checkout.

  • Confirm you are on main.
  • Confirm the worktree is clean.
  • Confirm the release version is a valid CalVer.
  • Run the changelog audit before release.
  • Make only product-facing release notes from packages/coding-agent/CHANGELOG.md via scripts/release-notes.mjs.
  • Skip housekeeping, upstream-sync, and generated-catalog-only entries.
  • Duplicate user-facing ai/agent/tui changes into the coding-agent changelog.
  • Run npm run check.
  • Run npm run build.
  • Run CI=1 npm test.
  • Create the release commit.
  • Create the release tag.
  • Create the next-cycle changelog commit.
  • Push main and the tag.

Pre-flight checklist

  • Read the current release rules in AGENTS.md and scripts/AGENTS.md.
  • Use a clean dedicated clone if the main checkout has foreign state.
  • Never clean, stash, or otherwise disturb other people's work.
  • Use the protected-main path when needed; UPSTREAM_AUTOMATION_TOKEN exists for authenticated protected-main pushes.
  • npm publish is delegated: the tag pipeline's publish-npm job no longer publishes — it dispatches publish-npm.yml in publish-only mode (the proven route from the v2026.7.28-x and v2026.8.4 recoveries) and gates the public GitHub Release on that run's success. npm's trusted publisher matches the publish-npm.yml workflow identity only; never reintroduce a direct publish or an environment: on the publish path (the environment subject is what npm rejects).
  • Do not rerun scripts/release.mjs after the tag has been pushed.
  • If checks fail before the tag push, fix first, then re-release from the beginning.
  • Treat E404 noise for @code-yeongyu/senpi-orchestrator as non-fatal.
  • Use node scripts/release-notes.mjs / the cl.md audit before publishing notes.
  • Keep release notes product-facing only.

Publish watch

After tag push, watch the build-binaries workflow run (find the run id via gh run list --workflow=build-binaries.yml --branch main --limit 1 --json databaseId -q '.[0].databaseId').

The publish-npm job dispatches publish-npm.yml in publish-only mode, prints the dispatched run URL, waits up to 60 minutes, and fails if the publish run fails. There is no environment approval gate on the publish path — the old npm-publish environment subject is exactly what npm's trusted-publisher registration rejects.

Never consider the release done before publish-npm and publish-github-release complete and the GitHub Release is non-draft. If the publish job fails, recover with gh workflow run publish-npm.yml -f version=<v> -f publish-only=true, never by rerunning release.mjs.

Gate disambiguation

These are separate controls and must not be conflated:

  • GitHub Environment approval: removed from the publish path (the npm-publish environment subject is what npm rejects); the unused environment may remain in repo settings harmlessly.
  • npm OIDC trusted publishing: the npm-side trusted publishing path used by the job.
  • npm lifecycle-script review: the npm approve-scripts --allow-scripts-pending trust review, which is not publish approval.
  • Protected-main authorization: the authenticated push path for protected main, which is distinct from publish approval.

Hazards and hard rules

  • Protected-main push failures are expected if the token path is wrong; use UPSTREAM_AUTOMATION_TOKEN for the authenticated release push path.
  • The tag pipeline publishes only through the dispatched publish-npm.yml identity (see Pre-flight checklist). If npm-side config changes, re-verify with a dry_run dispatch before the next release.
  • Never rerun scripts/release.mjs after the tag is pushed. If publishing fails, recover from the existing tag workflow.
  • If a check or test fails before the tag push, stop and fix the issue, then re-release. Do not try to salvage a bad release by continuing past the failure.
  • E404 noise for @code-yeongyu/senpi-orchestrator is not a release failure.
  • An npm PUT 404 during npm publish can be a false negative: the publish may have landed anyway (observed live on 2026-07-28 with @code-yeongyu/senpi@2026.7.28-2 — the job failed but the version exists). ALWAYS verify with npm view <pkg> versions --json before treating a publish error as real, before rerunning anything, and before declaring a release failed.
  • A failed publish-npm job skips publish-github-release and triggers the draft-cleanup path; check gh release view v<version> before recovering — the release may already be live. Recover only through the existing tag workflow, never by rerunning release.mjs.
  • If the main checkout has foreign state, use a clean dedicated clone/worktree. Never clean or stash someone else's work.

Release notes provenance

  • Extract notes only from packages/coding-agent/CHANGELOG.md via scripts/release-notes.mjs.
  • Keep changelog entries product-facing.
  • Run the cl.md audit before release.
  • Skip housekeeping, upstream-sync, and generated-catalog-only changes.
  • Duplicate user-facing ai, agent, and tui changes into the coding-agent changelog so the release notes stay complete.

Post-release verification checklist

  • build-binaries is complete.
  • stage-github-release is complete.
  • publish-npm is complete.
  • publish-github-release is complete.
  • The npm registry resolves the published version.
  • The GitHub Release is published and non-draft.

Notes

  • The canonical release path is scripts/release.mjs from clean main.
  • The approval checkpoint is mandatory for the normal tag-driven release.
  • Publishing today goes through the publish-npm.yml publish-only dispatch (see the known-broken note above), NOT the tag pipeline's environment-gated job.
  • If the tag pipeline's publish-npm fails after stage-github-release succeeded, the cleanup path deletes the draft release; the build assets survive as the run's release-assets-v<tag> artifact — re-create the release with gh release create <tag> --verify-tag --draft --title <tag> --notes-file RELEASE_NOTES.md <assets> and publish with gh release edit <tag> --draft=false after verifying npm view shows every package.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

bun-1-4

無料

Read before a js eval cell that installs a package, spawns a server or PTY, or starts a long run, and before any bun -e, script, server, CLI, test, bundle, or package-management work: this session's eval js kernel runs Bun 1.4+ (this skill is present only when it does). Bun 1.4 ships builtins that replace 15+ npm deps — check here BEFORE installing sharp, puppeteer/playwright (scraping), marked, node-cron, node-pty, concurrently, serve-static, tar, json5, fast-xml-parser, string-width. Triggers: eval js, bun, Bun.serve, bun test, bun build, bun install, bun run, image resize, headless browser, markdown render, cron, PTY.

日本語の概要は準備中です。原文の説明を表示しています。

code-yeongyu/senpi4742026年10月11日 更新

coding-agent-extension-worker

無料

Implements a single feature in the pi-mono `todotools` builtin extension work. Use for refactoring, continuation runtime, config resolver, prompt builder, test authoring, golden snapshots, CHANGELOG entries, and harness helpers. Does NOT do manual tmux QA.

日本語の概要は準備中です。原文の説明を表示しています。

code-yeongyu/senpi4742026年10月11日 更新

dynamic-resources

無料

Example skill loaded from resources_discover

日本語の概要は準備中です。原文の説明を表示しています。

code-yeongyu/senpi4742026年10月11日 更新

gpt-image-gen

無料

MUST read before generating images. Prompt-crafting guide for gpt-image-2.5 covering tool routing (native image_generation server tool vs the generate_image tool), model and quality selection, prompt structure, exact text rendering, reference-image editing, transparent assets, output formats, and multi-turn refinement.

日本語の概要は準備中です。原文の説明を表示しています。

code-yeongyu/senpi4742026年10月11日 更新

merge-upstream

無料

Sync a fork branch with an upstream remote using a history-preserving merge. Use this whenever the user says /merge-upstream, merge upstream, sync upstream, sync fork, or wants upstream changes integrated without rebasing or force-pushing.

日本語の概要は準備中です。原文の説明を表示しています。

code-yeongyu/senpi4742026年10月11日 更新

senpi-qa

無料

Manual QA harness for the senpi coding agent itself. MUST USE after changing packages/ai, packages/agent, packages/coding-agent, or packages/tui — a green typecheck and `npm test` are NOT QA. Drives the real CLI from source in an isolated sandbox (never touches ~/.senpi or real credentials) across four channels: remote RPC (--mode rpc JSONL stdio), TUI smoke (node-pty on Windows, tmux on POSIX), mock loop (a local fake model server for deterministic, zero-token agent-loop runs), and CLI smoke (--help/--print/--list-models). Every helper ships a --self-test. Use whenever someone says qa senpi, test the agent, verify my change, rpc qa, tui qa, mock-loop qa, smoke the cli, or needs evidence that an agent-loop, tool, keybinding, or provider change works end to end. Capture evidence to local-ignore/qa-evidence/.

日本語の概要は準備中です。原文の説明を表示しています。

code-yeongyu/senpi4742026年10月11日 更新

code-yeongyu のスキルをすべて見る

このスキルの問題を報告する