メニュー
Grimodex の Electron release workflow、tag build、署名、公証、 installer migration、artifact 集約、publish の失敗を、version と tag を増やさず診断・修正する。 「release CI失敗」「release workflow失敗」「tag build失敗」「署名／公証エラー」 「packaging失敗」「publish失敗」「成功済みplatformを再buildしたくない」で使用する。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Grimodex の Electron リリースバージョンを上げ、リリースノート、commit、 branch、PR、merge、注釈付き Release tag、GitHub Draft Release の確認まで進める。 Release は公開せず、Draft のまま停止する。 「バージョン上げて」「パッチ／マイナー／メジャーバージョン」 「リリースタグ」「リリース準備して」で使用する。
バグを調査・修正する。再現→原因特定→修正→検証の順で進める。 Use when: 「デバッグして」「修正して」「エラーが出る」「動かない」 と言われたとき。一般のPR／master CI、ランタイムエラー、型エラーの修正に使う。 Electron release workflow、tag build、署名、公証、publishの失敗はdebug-release-ciへ渡す。
現在の clean かつ commit 済み作業ブランチを push し、ready PR の作成または再利用、 CI・レビュー・HEAD の確認、squash merge、base branch への反映確認まで進める。 「PR出して」「プルリク作って」「pushしてマージ」「マージまでして」 「shipして」「リモートに上げてPR」で使用する。commit作成自体は行わない。 version更新を含むリリース準備は bump-version を主フローとし、release commit後の branch push、PR、mergeだけを担う。GitHub Releaseは公開しない。
docs/communication-style-guide.md を正本として、Grimodex の公開向け文章を 事実ベースで作成・改稿し、特に日本語／英語のリリースノートの意味、深刻度、 対応方法を一致させる。「リリースノートを書いて／直して」「日英の更新記録」 「リリース告知」「延期・障害・保守告知」「広報文」「SNS告知」 「README冒頭」「公式サイト見出し」「開発状況報告」で使用する。 Issue、PR、コミットメッセージ、UI文言、エラーメッセージと復旧手順、 API・IPC・MCP・CLI仕様、開発者向けセットアップ、法務文書、 セキュリティアドバイザリの技術詳細には使用しない。
Grimodex の AI 指示、system prompt、Codex skill、AI policy、AI 経路レジストリ、 評価 fixture と品質 manifest を作成・変更し、正本、Iron Laws、契約テスト、 追跡可能性を一貫して更新する。AI behavior asset の追加・変更、 「AI指示」「システムプロンプト」「Codexスキル」「AI評価fixture」で使用する。 一般的な UI／DB／IPC／Rust 機能実装、テストだけの追加、レビューだけの依頼、 バグ修正には使用しない。
Grimodex の Git 差分から関連 requirement と Light 評価 suite を選択し、 canonical quality workflow を読み取り専用で実行して証跡を報告する。 「差分評価」「品質ゲート」「impact gate」、commit／PR 前の検証、 grimodex-author 後の評価で使用する。テスト作成、失敗修正、意味的コードレビュー、 commit、push、merge には使用しない。
| name | debug-release-ci |
| description | Grimodex の Electron release workflow、tag build、署名、公証、 installer migration、artifact 集約、publish の失敗を、version と tag を増やさず診断・修正する。 「release CI失敗」「release workflow失敗」「tag build失敗」「署名／公証エラー」 「packaging失敗」「publish失敗」「成功済みplatformを再buildしたくない」で使用する。 |
Releaseをデバッグ用テストハーネスとして使わない。失敗runと修正HEADを固定し、最小再現、対象stageだけのhosted gate、修正のmergeを先に完了する。正式なversion bumpとtagは最後に一度だけ行う。
/debug-issue へ渡す。package.json、release notes、version、既存tagは変更しない。診断のためだけに新しいpatch versionやtagを作成しない。/ship-branch、focused gateとmerge完了後のDraft Release準備だけを /bump-version へ渡す。変更や再実行の前に、次を記録する。
gh run view <run-id> --json ... と失敗jobのlogを使い、推測で分類しない。同じrunの途中結果を、別SHAの結果と混ぜない。
gh run rerun <run-id> --failed を使う。.github/workflows/release.yml の手動実行はdebug専用で、publish=false以外を拒否する。workflow自体は常にtrusted default branchからdispatchし、candidate_refを別に渡す。未mergeのWindows／Linux修正は、originに存在する40桁commit SHAだけをcandidate_refに指定する。gateは指定SHAとcheckout結果の一致を検証し、そのSHAだけをbuild jobがcheckoutする。
| target | 実行場所 | 用途 |
|---|---|---|
windows | workflow=master、candidate=修正commitの40桁SHA | Windows package、未署名契約、実installer migration |
linux | workflow=master、candidate=修正commitの40桁SHA | Linux package、ABI、deb／rpm契約 |
mac | workflow／candidateともtrusted default branch | production Apple secretsを使う署名・公証付きmacOS build |
publish | workflow／candidateともtrusted default branch | source_run_idの成功済みhost artifactを再利用したread-only publish dry-run |
all | workflow／candidateともtrusted default branch | 全3 hostと早期bridge signing preflight。releaseは作成しない |
Windows／Linuxは修正commitをoriginへpushし、その40桁SHAを固定してcandidate_refに渡す。branch名や短縮SHAは渡さない。dispatchで返るrun URL／IDを記録し、gate logのresolved candidate SHAが指定SHAと一致することを確認する。手動runはtrusted default branchのworkflow定義とresolverを使い、candidate側の.github/workflows/release.ymlは実行しない。workflow YAML自体の修正はcontract testを通してmergeした後、candidate_ref=masterでhosted gateを実行する。
mac／publish／allはproduction secretをbranch codeへ渡さないため、focusedなlocal／contract検証後に修正を /ship-branch でdefault branchへmergeしてから実行する。candidateのpackage.json versionがdefault branchから変わっている場合もgateは拒否する。
例:
gh workflow run release.yml \
--ref master \
-f target=windows \
-f publish=false \
-f candidate_ref=<40-character-fix-commit-sha>
gh workflow run release.yml \
--ref master \
-f target=publish \
-f publish=false \
-f candidate_ref=master \
-f source_run_id=<failed-release-run-id>
target=publish はsource runが正規の.github/workflows/release.yml、対象tag／SHA、またはtrusted default-branch debug runに属することを検査してからhost artifactをdownloadする。artifact名とversionの完全性を検証し、署名、signature検証、latest.json生成まで行うが、GitHub Releaseの作成・更新・uploadは行わない。source artifactが期限切れの場合だけ、target=allをdefault branchで実行し、そのrun IDを新しいsource_run_idとして使う。
/ship-branchへ失敗run、原因、成功済みjob、focused gate、fix commit SHAを渡す。依頼範囲外なら証跡を報告して停止する。/ship-branchでdefault branchへmergeする。権限がなければ、secret-backed gateや/bump-versionへ進まずhandoff地点を報告する。candidate_ref=masterで対象targetをgreenにする。どちらの経路でも、元のゴールがrelease準備までの場合だけ、fixがorigin/masterに含まれfocused gateが成功した後 /bump-version へ渡す。version bump、tag、full release workflow、Draft Release組み立てはここで一度だけ行い、Releaseは公開しない。
--refがdefault branch以外、未mergeのWindows／Linux修正のcandidate_refが40桁SHA以外、またはsecret-backed targetのcandidate_refがdefault branch以外publish=true、tag移動、既存releaseの破壊的変更が必要/ship-branchへ進む権限もない停止時は、成功済みjobを含む現在状態、足りない証跡、次に必要な最小操作を報告する。