runtime-release-with-paired-ja-synclisted

# runtime-release-with-paired-ja-sync: runtime リリース＋ja-side 同期ワークフロー claude-org-runtime のリリースは PyPI 発行を経由して claude-org-ja の attention watcher integration test に必ず波及する。 本 skill はそのカスケードを「リリース起票時に予測し、paired ja-sync を同一 Secretary セッション内で land しきる」ためのチェックリスト。 > **本 SKILL のスコープ**: 窓口が runtime release 系タスクを受領した際の > 委譲設計と paired ja-sync 計画。実 commit / テスト修正はワーカー側であり本 skill ではない。 ## なぜこの skill が必要か `claude-org-runtime` 側で `DEFAULT_NOTIFY` の値や classifier 語彙・`role_configs_schema.json` （runtime 同梱 schema。ja 側ミラーが `tools/org_extension_schema.json`）の項目を 更新してリリースすると、PyPI publish 後に `claude-org-ja` 側の以下が同時に古くなる: - `tests/test_attention_runtime_integration.py` の expectation - `tools/org_extension_schema.json` のバイト一致コピー - `.claude/skills/org-setup/references/permissions.md` の projection - `tools/templates/attention.example.json` の severity / TTL 過去のリリースサイクルでは「runtime release は無事だったが ja-side CI が翌日に red」になる カスケードが観測されており、これを毎回観測してから後追いで直すと、 - Secretary セッションが切れて context を失う - ja-side worker に「なぜこの変更が必要か」の経路を再構築させる - 修正の paired-ness が暗黙的になり次回も同じカスケードを踏む の 3 重コストが発生する。本 skill は paired-ness を**リリース起票時に明示化**し、 同一 Secretary セッション内で land しきる規律を提供する。 ## 発動条件 以下のいずれかに該当する場合、Secretary は org-delegate より前にこの skill を確認する: - task_id に `release` を含む、または `vX.Y.Z` 形式のタグを発行するリリース系タスク - chore release 系のユーザー指示プロンプト（「runtime のリリース」「PyPI 上げ」等） - runtime 側の `DEFAULT_NOTIFY` / classifier mapping / `role_configs_schema.json` / attention テンプレのいずれかを触る変更が land 寸前 - runtime 側の `role_configs_schema.json` にある `