共有リポジトリのプロジェクト（参画案件）に自分個人の AI 開発手法（スキル、計画駆動フロー、クロスモデルレビュー手順）を持ち込むとき、「チームの成果物に個人の道具を混ぜない＝共有リポジトリへの書き込みゼロ」を不変条件にし、手法を3層に分けて配置する。

判断基準（3層分離）

• 能力（スキル・エージェント定義）: 個人プラグインとして user スコープでインストールする。プラグインの実体はホーム配下のキャッシュに展開され、どのスコープでもプロジェクトのリポジトリにはコピーされない。スコープで変わるのは有効化フラグの書き込み先だけなので、project スコープ（共有設定ファイルに入りチームに見える）は避け、全プロジェクトで使うなら user、特定プロジェクトだけなら local（untracked なローカル設定）を選ぶ。配布は非公開の Git リポジトリやローカルディレクトリを marketplace として登録すれば、公開リポジトリにする必要はない。
• 計画ドキュメント（実装計画・設計下書き）: リポジトリ外の個人ノート置き場（ホーム配下の dev-notes のような場所）にプロジェクト別ディレクトリで置く。置き場はゼロ設定で自動導出する: git toplevel のディレクトリ名をプロジェクト名にし、worktree では main checkout の名前に正規化、非 git ワークスペースではカレントディレクトリ名にフォールバック。例外のプロジェクトだけ宣言で上書きする。
• プロジェクト別の宣言（置き場・完了条件・並列境界などの上書き）: untracked のローカル指示ファイル（CLAUDE.local.md 等）に置く。チーム共有の指示ファイル（CLAUDE.md / AGENTS.md）には書かない。
• 一時出力（レビュー結果など）をリポジトリ内に置く必要がある場合は、共有の gitignore を変更せず、個人用の除外設定（.git/info/exclude）に追記する。

却下した代替案

• 計画を共有リポジトリにコミットする: 参画案件では個人ドキュメントの持ち込み自体ができない。自リポジトリでは可能だが、手法が「リポジトリにコミットできること」に依存すると横展開できなくなる。
• 計画を知識ベース（メモサービス）に直接置く: 書き換えながら育てる長文の作業計画と「確定した判断の記録」はライフサイクルが合わない。計画はファイルで育て、確定した判断だけを知識ベースへ昇格させる役割分担にする。
• リポジトリ内の ignore 済み作業ディレクトリに計画を置く: 手元では近くて便利だが、バックアップされず worktree 間でも共有されない。

検証

共有リポジトリで git status と diff が完全にクリーンなまま、スキル呼び出し→計画作成→実装→レビューの1サイクルが回ることを確認する。プラグイン導入・設定変更の後に、共有側の設定ファイルや gitignore に差分が出ていないことも見る。