release - SKILL.md Agent Skill

name: release description: memorize の本番リリース手順。「push and release」「リリースして」「公開して」「main に上げて」のような指示が出たとき、または手元の変更を本番（GitHub Release / DMG / Homebrew cask）に届ける必要があるときに使う。バージョン bump 判断、vendor/anki の dirty な submodule 状態の扱い、commit 規約、release workflow の確認手順をまとめる。memorize リポジトリ専用。

memorize Release

memorize の本番リリースは main への push で完全自動。.github/workflows/release.yml が tauri-action でビルドし、GitHub Release を作って Latest 化、iQeda/homebrew-tap の cask も自動更新する。

前提運用ルール（毎回これを思い出す）

毎リリースで version を必ず bump する（bump 幅は semver で決める）（重要）
- package.json / src-tauri/tauri.conf.json / src-tauri/Cargo.toml の version を 3 ファイル同時に 上げる
- bump 幅は変更の種類で決める（ユーザー指示 2026-06-07）:
  - バグ修正 / リファクタ / chore / ci のみ → patch（0.5.5 → 0.5.6）
  - 後方互換のある機能追加 → minor（0.5.5 → 0.6.0）
  - 破壊的変更 → major（0.5.5 → 1.0.0）
- 「機能追加系は適宜マイナーを上げる」こと。patch 固定で出さない（過去に TSV インポート機能を patch で出して再指摘を受けた）
- これを忘れる（同じ version で出す）と tauri-plugin-updater が反応しない。updater は latest.json の version で判定するため、同じ version で release を出しても既存ユーザーの自動 update が起動しない（過去に実害あり）
- bump 後は一度 cargo check --manifest-path src-tauri/Cargo.toml を走らせて src-tauri/Cargo.lock も追従させ、まとめて 1 commit に含める
- commit メッセージ末尾に - version 0.5.X → 0.5.Y（または 0.X.0）の 1 行を入れる慣習（過去履歴参照）
vendor/anki の dirty は絶対に commit しない
- apply-vendor-patches.sh が vendor/anki/rslib/... に local patch を当てるので、submodule は常に dirty 状態（m vendor/anki）
- これは設計通りの状態。CI でも同じ patch を当てるので、submodule の中身を新しい SHA に進める commit を作ってはいけない
- git add -A / git add . は厳禁。常に ファイル名を明示 して git add <path...>
commit メッセージは日本語の type(area): 内容 形式
- 過去履歴例:
  - feat(reviewer): カードを答えるたびにサイドバーのデッキバッジを再取得
  - feat(shortcuts): edit を E に戻し、Study Now / Back to decks に Space を追加
  - fix(note-editor): Front 自動フォーカスを bind:this 経由で確実に発火
  - ci: tauri-action を v0.5.25 に pin して release 作成失敗を解消
  - chore(deps): ...
- area は reviewer / shortcuts / sync / settings / note-editor / home / layout / ci / chore など、変更箇所のドメイン名
- 末尾に Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> を必ず入れる

実行手順

1. 事前ビルドチェック（任意だが推奨）

リリース前に CI が落ちる原因を手元で潰しておく:

pnpm exec svelte-check                          # フロント型チェック
cargo check --manifest-path src-tauri/Cargo.toml # Rust コンパイルチェック
pnpm build                                       # SSR ビルド (CardFrame の <script> tokenizer 罠を catch)

CardFrame.svelte 周辺を触ったときは特に pnpm build を必ず通す（CLAUDE.md の "Svelte tokenizer pitfall" 参照）。

2. 状態確認

git status                # vendor/anki の m は無視。それ以外を確認
git diff --stat           # 規模感
git log --oneline -5      # commit メッセージの過去スタイル参照

3. 明示的に stage

# ファイル名を一つずつ列挙する。-A や . は使わない。
git add path/to/file1 path/to/file2 ...
git status                # vendor/anki が "Changes not staged" のまま残ることを確認

4. commit

HEREDOC で commit メッセージを渡す（フォーマット崩れを避けるため）:

git commit -m "$(cat <<'EOF'
feat(area): 1 行サマリ

(必要なら本文。何を変えたかではなく WHY を中心に。
 機能名やキーバインド、デフォルト値など読み手が知りたい事実を含める)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
EOF
)"

5. push（ここから先は副作用が外に出る）

git push origin main

ユーザーから明示的にリリース指示を受けてから push する。push と同時に release workflow が起動するため、push 自体がリリースの実行アクションになる点に注意。

6. workflow の確認

sleep 5 && gh run list --workflow=release.yml --limit 1

in_progress であることを確認したら、ビルド完了 (過去履歴で 4-7 分) まで待つ。

7. 完了確認と URL 報告

5-7 分後、または gh run watch <run-id> で完了を待ってから:

gh run list --workflow=release.yml --limit 1                # success/failure
gh release list --limit 1                                   # 新 tag を確認
gh release view <tag> --json url -q .url                    # release URL

完了したらユーザーに以下を伝える:

新しい tag (例: v0.4.19-20260507-1134-16aa9a5)
Release ページの URL
homebrew tap 自動 bump が走ったか（成功なら gh release view の本文に何も注記なし。HOMEBREW_TAP_TOKEN 未設定時は warning でスキップする）

失敗時の対処

workflow が失敗した場合

gh run view <run-id> --log-failed

過去に踏んだ罠:

tauri-action @v0 が v0.6 に勝手に上がって失敗（2026-04-29 頃）→ v0.5.25 に pin して解決済み（commit 9906ced）。再発したら release.yml の tauri-apps/tauri-action@<ver> を確認
codesign 検証失敗（"Signature=adhoc" が出ない / --verify --deep --strict 失敗）→ workflow 内 "Verify bundle signature" ステップで error::bundle integrity が出る。bundle 構造を変えるような Tauri 設定変更を疑う
homebrew tap bump がスキップ（warning 出力）→ HOMEBREW_TAP_TOKEN secret 未設定。リリース自体は成功しているので追加対応不要、必要なら secret 設定後に再 push

push 後に「やっぱり戻したい」場合

GitHub Release は gh release delete <tag> + tag 削除 (git push --delete origin <tag>) で消せるが、homebrew-tap への自動 bump commit はすでに別 repo に push されているので別途 revert が必要。基本は push 前に確認しておく のが鉄則で、push 後の rollback はユーザー明示確認が必須。

チェックリスト（迷ったらこれを順に通す）

git status で変更確認、vendor/anki の dirty 以外を把握
version を 3 ファイル bump したか？（毎リリース必須。機能追加=minor / 修正=patch）
ビルドチェック通った？（svelte-check / cargo check / pnpm build）
git add でファイル名明示（-A 使ってない）
commit メッセージは feat(area): ... 日本語スタイル + Co-Authored-By
ユーザーから明示的に push 指示があるか
push 後に workflow 起動を gh run list で確認
完了確認 → release URL をユーザーに報告