Skip to content
cccskills
FreePublished on 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.

The English summary is being prepared. Showing the original description.

code-yeongyu/senpi
Works withGitHub
See how to install

Files included (1)

  • SKILL.md6.5 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

bun-1-4

Free

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.

The English summary is being prepared. Showing the original description.

code-yeongyu/senpi485Updated Oct 19, 2026

coding-agent-extension-worker

Free

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.

The English summary is being prepared. Showing the original description.

code-yeongyu/senpi485Updated Oct 19, 2026

dynamic-resources

Free

Example skill loaded from resources_discover

The English summary is being prepared. Showing the original description.

code-yeongyu/senpi485Updated Oct 19, 2026

gpt-image-gen

Free

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.

The English summary is being prepared. Showing the original description.

code-yeongyu/senpi485Updated Oct 19, 2026

merge-upstream

Free

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.

The English summary is being prepared. Showing the original description.

code-yeongyu/senpi485Updated Oct 19, 2026

senpi-qa

Free

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/.

The English summary is being prepared. Showing the original description.

code-yeongyu/senpi485Updated Oct 19, 2026

See all skills by code-yeongyu

Report a problem with this skill