メニュー
Release a new ghactivities version end to end, including version selection, checks, release PR, GitHub release, workflow monitoring, and branch cleanup. Use when asked to publish or perform a production release.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/dyoshikawa/ghactivities --skill releaseコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Scan an entire repository for security issues and malicious code — leaked secrets, injection and code-execution flaws, supply chain and CI/CD risks, insecure configuration, and malicious instructions hidden in AI rule files. Use when the user wants a security scan or audit of the whole repository as it stands, rather than of a single diff.
Release a new ghactivities version end to end by drafting the release, waiting for green CI, merging the release PR, publishing the GitHub release, and verifying the npm release workflow. Use when asked to complete, finish, or publish a release through the goal-release workflow.
Create or update a Rulesync source file (rule, command, subagent, skill, ignore, mcp, permissions, or hooks) with the Rulesync MCP Server. Use when asked to add or modify project configuration under .rulesync.
SOC 職業分類に基づく
SKILL.md を表示中
| name | release |
| description | Release a new ghactivities version end to end, including version selection, checks, release PR, GitHub release, workflow monitoring, and branch cleanup. Use when asked to publish or perform a production release. |
| targets | ["*"] |
First, let's work on the following steps.
main branch. If not on the main branch, abort this operation.What's Changed, Contributors and Full Changelog are needed../tmp/release-notes.md will be used as the release notes.Then, get the requested new version from the user's request without the v prefix and assign it to $new_version. For example, if the request specifies "v1.0.0", the new version is "1.0.0".
Unless the user explicitly specifies the new version, determine $new_version from the release description by applying the general semantic-versioning rules (a breaking change bumps the major, a new feature bumps the minor, and a bug fix bumps the patch).
Let's resume the release process.
git pull.git checkout -b release/v${new_version}.package.json to ${new_version} with pnpm version ${new_version} --no-git-tag-version. The CLI reads its version from package.json, so no other file needs to change.pnpm cicheck. If the checks fail, fix the code until they pass.git add, git commit and git push.pnpm dev --version reports ${new_version}.gh pr create targeting the main branch, then gh pr merge --admin --merge to merge the release branch into main.gh release create v${new_version} --title v${new_version} --notes-file ./tmp/release-notes.md on the github.com/dyoshikawa/ghactivities repository. Creating the release triggers the Release workflow (.github/workflows/release.yml), which builds the project and publishes it to npm.Release workflow to complete successfully. Use gh run list --workflow=Release --limit 1 --json status,conclusion,databaseId to check the status. Poll until the workflow completes (status is "completed"). If it fails, report the failure.git checkout main, git branch -D release/v${new_version} and git pull --prune.