القائمة
セッション間の引き継ぎプロトコル。Implementation Plan を docs/proposals/ の git 管理ファイルとしてバトンパスに使い、SPECIFICATION.md / USER_GUIDE は完了状態の記録として使う。新規実装・大幅修正の着手前、またはセッション開始/終了時に発動する。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
| name | core_session_handoff |
| description | セッション間の引き継ぎプロトコル。Implementation Plan を docs/proposals/ の git 管理ファイルとしてバトンパスに使い、SPECIFICATION.md / USER_GUIDE は完了状態の記録として使う。新規実装・大幅修正の着手前、またはセッション開始/終了時に発動する。 |
CSW (Claude Desktop Switcher / Rust + Tauri v2 macOS app) のセッション間引き継ぎ標準。Implementation Plan を git 管理のバトンパスとして使い、docs/SPECIFICATION.md / docs/USER_GUIDE*.md は完了状態の記録として使う。Plan のライフサイクル全体を本スキルに統合している。
| ドキュメント | 目的 | タイミング | 配置 |
|---|---|---|---|
| Implementation Plan | セッション間のバトンパス + PR レビュー時の背景共有 | 着手前に作成 + ライフサイクルで更新 | docs/proposals/<slug>.md（git 管理、frontmatter の status で管理） |
docs/SPECIFICATION.md | 仕様の現在地（完了状態の正典 / spec canon） | タスク完了後に更新 | docs/ 直下 |
docs/USER_GUIDE.md / USER_GUIDE_EN.md | ユーザー向けガイド（完了状態） | タスク完了後に更新 | docs/ 直下 |
Plan は「次に何をやるか（前方参照）」、SPECIFICATION / USER_GUIDE は「何が完成したか（後方の記録）」。役割を混同しない。
blueprint.mdは存在しない。仕様の正典は必ずdocs/SPECIFICATION.md。
docs/proposals/（git 管理。worktree ローカルパスには絶対に置かない — worktree 削除で消失する）<kebab-case-slug>.md。中身が分かる英語短縮トピック名。日付はファイル名に付けず、frontmatter の created と git 履歴に持たせるdocs/proposals/cli-env-eval-profile-switch.md / docs/proposals/keychain-isolation-per-profile.md各 plan ファイルの先頭に以下の YAML frontmatter を必ず記載する：
---
title: タスクの短いタイトル（50字以内）
created: YYYY-MM-DD
status: draft | approved | in-progress | completed | rejected
pr: 42 # PR 作成後に番号を追記（未確定時は省略可）
related_prs: [] # 関連 PR 番号（任意）
related_issues: [] # 関連 Issue 番号（任意）
---
| status | 意味 |
|---|---|
draft | 作成中・ユーザ Approve 未取得 |
approved | ユーザが Approve 済み、実装着手可能 |
in-progress | PR 作成済み、実装中 |
completed | PR マージ済み、タスク完了 |
rejected | PR Close または plan 自体が見送りになった |
遷移は draft → approved → in-progress → completed（または途中で rejected）。
| ステージ | アクション | commit |
|---|---|---|
| 1. ドラフト作成 | docs/proposals/<slug>.md を作成、status: draft | ✅ する |
| 2. ユーザ Approve | status: approved に更新 | ✅ する |
| 3. PR 作成 | PR 本文に plan へのリンクを貼り、status: in-progress に更新 | ✅ する |
| 4. 実装中の更新 | 必要に応じて plan を更新（変更履歴は git diff で追える） | ✅ する |
| 5. PR マージ | status: completed に、pr フィールドに番号確定 | ✅ する |
| 6. PR Close | status: rejected に、末尾に Close 理由を追記 | ✅ する |
status: in-progress → completed の事後追記・誤字修正・リンク切れ修正など、軽微な変更も含めて plan へのすべての変更は PR 経由。本スキル自体の更新も同様に PR 経由。gh pr merge --squash のみ。--admin / --no-verify で CI をスキップして例外を作らない。待ち時間が惜しければ軽微更新を実装 PR にまとめる。次セッションが読むだけで即着手できるレベルにする。最低限：
CLAUDE.md および既存スキルから適用するルール（特にセキュリティ・プライバシー・倫理を利便性と引き換えにしない、を明記）crates/core (csw-core / ロジック + テスト) / crates/cli (csw-cli) / crates/desktop (csw-desktop / Tauri v2) のどこを触るか）ローカルに cargo が無い環境があるため、検証の正典は CI（実装 → CI で build/test/clippy → fix → 収束、の Workflow フィードバックループで回す）。ローカルで動く場合は同じコマンドを先に流す：
cargo fmt --check # フォーマット
cargo clippy --workspace --all-targets -- -D warnings # lint（warning をエラー扱い）
cargo build --workspace # build（desktop 含む / build.yml 相当）
cargo test --workspace # test（ローカル）
test.yml が cargo test --workspace --exclude csw-desktop（core + cli）、build.yml が cargo build --workspace（desktop 含むワークスペース全体）を実行する。cargo tauri dev を検証計画に追記する。PR 本文の冒頭に必ず plan へのリンクを記載する：
## Plan
[docs/proposals/<slug>.md](https://github.com/matsumotory/claude-desktop-switcher/blob/main/docs/proposals/<slug>.md)
## Summary
...
これにより、レビュアー（人間 + Claude）が背景・設計判断・スコープを即座に理解でき、マージ後に status: completed へ更新する起点になる。PR レビューは /code-review スラッシュコマンド（--comment でインライン投稿、--fix で修正適用）または Task/Agent サブエージェントで観点別に回す。/gemini review は使わない。
git fetch origin main を最初に必ず実行（ローカル checkout は信用しない）。作業は .claude/worktrees/<name> の隔離 worktree で行い、/tmp には作らないdocs/SPECIFICATION.md — 仕様の現在地・全体コンテキストdocs/proposals/ 配下の status: in-progress または status: approved の plan — 具体的な着手ポイントCLAUDE.md と該当ドメインの .agents/skills/（modern-rust-workflow / tauri-v2-best-practices 等）cargo audit（導入済みなら）または .github/workflows/security.yml の結果を確認。脆弱性があればセキュリティ対応を優先するstatus を実態に合わせて更新（approved → in-progress → completed 等）pr フィールドに番号を確定追記gh pr merge --squash でマージ（自律マージ可）git pull origin main を実行し、ローカル main を同期docs/SPECIFICATION.md / USER_GUIDE に「次やること」の詳細手順を書く（完了状態の記録のみ。前方参照は plan に書く）--admin / --no-verify で CI を飛ばしてマージする（軽微な plan 単体 PR でも禁止）CLAUDE.md §7 違反）استنادا إلى تصنيف SOC المهني
CSW のユーザー向け UI・コピーの正典。ユーザー向け語彙(「環境」)、共有モードの3語(共有/分離/コピー)、選択行の見せ方(塗りのみ)、メニューバーを主機構にしない、コピーの一次ソースは LP、Claude 本体の現行用語への追従、並列 UI の分量・文体、禁止記号(em-dash/※/絵文字)を定める。アプリ UI・LP・docs のラベル/モード名/説明文/マイクロコピーを作る/変える前に読む。
用語・概念・UI・コピーを1箇所変えたら、全サーフェス（アプリ UI・トレイ・docs ja/en・README ja/en・LP ja/en・スクリーンショット・OG 画像）へ同時反映し、旧表現を全リポ grep で残存ゼロ確認する。スクショ等の非テキスト派生物は grep に映らないので明示列挙して再生成する。UI・用語・コピーを変えたら発動。
PR をマージする際のレビュー・マージ実行チェックリスト (Rust + Tauri v2 / CSW)。スコープ外変更・安全装置の格下げ・テスト負債・高リスクインフラファイル改変を検出し、CI green を確認したうえで自律的に squash merge する手順を定義する。
CI (GitHub Actions の Test / Build / Security job) が想定時間を大幅に超過した場合のハング検出と cancel / rerun フロー。macos-latest runner の混雑や cargo の依存取得・コンパイル stall 等、transient な GHA 側障害の典型対処。CI が想定より長く `in_progress` のまま動かない時に発動。
日本語の見出し・本文の折り返し / タイポグラフィ品質ゲート。日本語 UI・LP・ドキュメントのコピーやフォントサイズ、改行、行間に触れる前に必ず読む。英語の折り返しルールをそのまま日本語に当てると崩れる(禁則・文節・字面密度が違う)ため、JP 専用の規則・モダン CSS・モジュラースケール・実機検証手順を正典化する。design-taste-frontend を補完する JP 特化スキル。
LP(website/) と人間向けドキュメント(docs/・README) と実装(crates/) が「同じ一つの事実」を語っているかを横断監査する。用語・アーキテクチャ・CLI 表面・機能主張・ja/en 整合・禁止表現を点検し、不整合を file:line と修正案つきで報告する。リリース前やドキュメント/LP/実装を変えた後に実行する read-only 監査。
