메뉴
Use this skill when cutting, preparing, validating, tagging, publishing, or troubleshooting a Weft npm release for @lostgradient/weft.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use this skill when refreshing Weft public documentation, AGENTS.md, CLAUDE.md, or mirrored skills from recent pull requests.
Use this skill when restoring or protecting Weft coverage with LCOV-backed branch targeting, structural test doubles, coverage allowlists, conformance fixtures, or tests for hard-to-reach protocol, schema, lifecycle, and CLI paths.
Use this skill when a Weft change touches ack-gated flows, pending promises, WebSocket workers, shutdown, disposal, cancellation, retries, reconnects, heartbeats, timers, or any lifecycle path where ordering can leave work hanging.
Use this skill when writing or reviewing Weft comments, JSDoc, documentation, README examples, test prose, or operation descriptions that describe wire responses, server diagnostics, masked errors, public APIs, or runtime recovery.
Use this skill when a Weft change renames, reshapes, normalizes, hashes, serializes, or replays persisted data such as effect-log records, checkpoints, tool calls, tool results, JSONValue content, storage payloads, or compatibility fixtures.
Run the full verification cycle before declaring work done: build, typecheck, lint, test, export review, diff review. Use when the user says "verify", "validate", "check everything passes", "run the full suite", "make sure it's ready", or before committing, opening a PR, or finishing a feature. Also use proactively after completing any non-trivial implementation work.
| name | release-publish |
| description | Use this skill when cutting, preparing, validating, tagging, publishing, or troubleshooting a Weft npm release for @lostgradient/weft. |
Publish Weft through the GitHub Actions release workflow, not by defaulting to a
local npm publish. The workflow triggers from a pushed vX.Y.Z tag, verifies
that the tag, package.json.version, and src/version.ts agree, runs
bun run validate, runs bun run prepack, performs
npm publish --dry-run --ignore-scripts, and publishes with npm provenance via
npm publish --ignore-scripts. After the npm publish succeeds, the workflow
opens downstream bump issues for repositories listed in
downstream-release-repositories.toml using DOWNSTREAM_ISSUE_TOKEN.
Confirm the target SemVer version. If the user did not provide it, inspect the current package and npm state before choosing:
jq -r '.version' package.json
npm view @lostgradient/weft version
git fetch origin main --tags
git tag --list 'v*' --sort=-version:refname | head -5
Work from a clean branch based on current origin/main. Do not release from
a detached head, dirty checkout, stale base, or unmerged pull request branch.
git status --short --branch
git fetch origin main --tags
git switch -c steve/release-vX.Y.Z origin/main
Update every shipped version surface together:
package.json versionsrc/version.ts VERSIONREADME.md current release lineSearch for the old version and update only release-version references that are meant to track the current package version:
rg '0\.0\.0|X\.Y\.Z|Current release|VERSION' README.md documentation src package.json
Run the release-specific checks before opening the release pull request:
bun run scripts/verify-release-version.ts --tag=vX.Y.Z
bun run validate
bun run prepack
npm publish --dry-run --ignore-scripts
Treat every failing gate as blocking. Do not skip, weaken, retry-count bump, or timeout-bump a gate to keep the release moving.
Open a normal pull request, not a draft, after the local gates pass. Validate the title with the repository title helper:
draft_title="Release vX.Y.Z"
normalized_title=$(bun run scripts/pr-title.ts normalize --title "$draft_title" | jq -r '.normalizedTitle // empty')
pull_request_title="${normalized_title:-$draft_title}"
bun run scripts/pr-title.ts validate --title "$pull_request_title"
The pull request body must list the target version and the exact release gates
that passed. Keep monitoring until CI is green, review comments are resolved, and
the branch has no conflicts with origin/main.
After the release pull request is merged, fetch the merged commit and create the
release tag from current origin/main:
git fetch origin main --tags
git switch main
git pull --ff-only origin main
bun run scripts/verify-release-version.ts --tag=vX.Y.Z
git tag vX.Y.Z
git show --stat vX.Y.Z
Pushing the tag starts the real npm publish. Confirm before pushing the tag unless the user already explicitly authorized release publication:
git push origin vX.Y.Z
Monitor .github/workflows/release.yaml until every job is terminal and green:
gh run list --workflow release.yaml --limit 5
gh run watch <run-id> --exit-status
npm view @lostgradient/weft version
The release is complete only when the workflow succeeded, npm reports the new version, and the downstream notification job either created or explicitly skipped the configured bump issues as duplicates. If the tag workflow fails, diagnose the failing job, fix the repository state through a pull request when code changes are needed, delete or move the tag only with explicit user confirmation, and re-run the release from a clean tag.
Use local npm publish --ignore-scripts only when the user explicitly asks for
manual publication and understands it bypasses the normal trusted-publishing
workflow. Before doing that, rerun bun run prepack,
npm publish --dry-run --ignore-scripts, and
bun run scripts/verify-release-version.ts --tag=vX.Y.Z.