Setup Anping Skills プロジェクト起動ツール
現在のリポジトリを、Codexとの長期協業に適したプロジェクト環境に初期化します。このスキルはプロンプト駆動型であり、決定論的なインストールスクリプトではありません。まず探索し、次に質問し、その後ドラフトを提示し、最後に書き込みます。
目標はすべてのスキルをインストールすることではなく、プロジェクトのニーズに応じて適切に組み合わせることです。
- Anping 自作スキル（例:
multi-agent-orchestrator、transfer-codex-sessions） - 外部優良スキル（例: Matt Pocock の engineering skills）
- プロジェクトルールと知識ファイル（例:
AGENTS.md、CONTEXT.md、CONTEXT-MAP.md、docs/agents/、docs/adr/）
動作原則
- 開始前に実行主体を説明する。長期または複数ファイルにわたる初期化は、現在のプロジェクトのマルチエージェントオーケストレーションルールに従うこと。ツールポリシーが委任を許可しない場合は、段階的フォールバックを使用することを説明する。
- 一度にユーザーに質問するのは1つの部分のみ。すべての決定を一度にユーザーに提示しない。
- 推奨する各スキルについて、用途、出典、そしてなぜ現在のプロジェクトに適しているかを説明する。
- サードパーティ製スキルのソースコードをベンダリングしない。外部スキルはインストール元または参照ディレクトリ経由でのみ接続する。
- ファイルを書き込む前に、変更するファイル、重要なブロック、デフォルトの選択肢を提示し、ユーザーの確認を得てから書き込む。
- ユーザーが既に持っている
AGENTS.md、README.md、CONTEXT.md、docs/agents/*の内容を上書きしない。既存のブロックを更新し、重複して追加しないようにする。
ワークフロー
1. 依存スキルの事前チェック
まず、現在のセッションと ~/.codex/skills/ に重要なスキルが既にあるかどうかを確認します。references/skill-catalog.md を読み込み、プロジェクトのニーズに基づいて必須、推奨、オプションを判断します。
- スキル選択と目標の明確化:
ask-matt、grill-with-docs - ドメインと知識の定着:
domain-modeling - メインスレッドオーケストレーション:
multi-agent-orchestrator - エンジニアリングプロジェクト設定:
setup-matt-pocock-skills
不足しているものを自動的にすべてインストールしないでください。まず、不足しているスキル、出典、用途、推奨レベルをユーザーに説明します。ユーザーが確認した後、skill-installer または上流の推奨方法を使用してインストールします。
2. プロジェクトの探索
現在のリポジトリの状態を簡単に確認し、短いスナップショットのみをユーザーに提供します。過度な結論は導き出さないでください。
git remote -vと.git/config: GitHub/GitLab/ローカルプロジェクトかを確認。- ルートディレクトリの
AGENTS.md、CLAUDE.md: 既にエージェントルールやAgent skills関連のセクションがあるか。 - ルートディレクトリの
README.md: プロジェクトの目標が既に明確に記述されているか。 - ルートディレクトリの
CONTEXT.md、CONTEXT-MAP.md。 docs/agents/、docs/adr/、src/*/docs/adr/。.scratch/: ローカルのマークダウン課題規約が既にあるか。~/.codex/skills/または現在のセッションで利用可能なスキル: どの自作スキルと外部スキルが既にインストールされているか。
3. 発見事項の提示
短いリストでユーザーに伝えます。
- 現在のプロジェクトの大まかなタイプ。
- 既存のAI協業ファイル。
- 存在しないが価値があるかもしれないファイル。
- インストール済み/未インストールの重要なスキル。
- 次に段階的にどのような決定事項について質問するか。
4. 段階的な質問
各セクションでは、まず1〜3文で用途と影響を説明し、次にデフォルトの提案を示し、ユーザーの回答を待ってから次のセクションに進みます。
A. プロジェクト目標
プロジェクト目標が不明確な場合、まず ask-matt を使用して適切なフローを選択します。インタビュー形式でドキュメントを整理する必要がある場合は grill-with-docs を使用します。目標が合意されたら、README.md のプロジェクト説明に書き込むか更新するかを尋ねます。
B. メインスレッドオーケストレーションパターン
multi-agent-orchestrator を有効にするかどうかを尋ねます。利点として、コンテキストガバナンス、独立した検証、セルフバリデーションの削減を説明します。欠点として、短いタスクでは総トークン数が増加する可能性があることを説明します。ユーザーが同意したら、プロジェクトレベルの委任承認を書き込むかどうかを続けて尋ねます。つまり、メインスレッドが system/developer/tool policy、リポジトリルール、承認要件を遵守した上で、サブエージェントやロールエージェントを自動作成または使用し、ユーザー可視のCodexスレッドを通じて協業することを許可します。ユーザーが確認したら、メインスレッドオーケストレーションルールと承認を AGENTS.md に書き込みます。既にインストールされているスキルのテンプレートを優先して使用します。
C. コンテキストレイアウト
ユーザーに選択肢を提示します。
Single-context: ルートディレクトリに1つのCONTEXT.mdとdocs/adr/。ほとんどのリポジトリではこれがデフォルトです。Multi-context: ルートディレクトリのCONTEXT-MAP.mdが複数のコンテキストディレクトリを指します。monorepo やマルチプロダクトリポジトリに適しています。
具体的なファイルを書き込む必要がある場合は、references/project-files.md を読み込みます。
D. プロジェクト知識ベース
人間とAIの両方を対象としたプロジェクト知識ベースを作成するかどうかを尋ねます。デフォルトの提案は以下の通りです。
docs/agents/anping-skills.md: このプロジェクトで有効化されたスキル、その用途、呼び出し境界。docs/agents/project-knowledge.md: プロジェクト知識の定着ルール。docs/adr/README.md: ADRの使用方法。デフォルトでは中国語でADRを作成します。ただし、ユーザーが明示的に英語またはバイリンガルを希望する場合はその限りではありません。
E. 外部スキルの導入
プロジェクトのタイプに応じて外部スキルを推奨します。デフォルトではすべてをインストールしません。現在のプロジェクトで実際に使用される組み合わせのみを推奨します。サードパーティ製スキルをインストールする前に、出典と理由を説明し、確認を求めます。
5. ドラフトの提示と確認
書き込み前に以下を表示します。
- 変更または作成するファイルのリスト。
AGENTS.mdに追加/更新予定のセクションの概要。Delegation Authorizationを書き込むかどうかも含みます。docs/agents/anping-skills.mdに記録予定のスキルリスト。CONTEXT.mdまたはCONTEXT-MAP.mdのレイアウト。- 外部スキルをインストールするか、インストールを推奨するか。
ユーザーが確認した後、ファイルの変更を実行します。
6. プロジェクト設定の書き込み
ユーザーの選択に従って書き込みます。
AGENTS.mdまたは既存のエージェントルールファイルへの Anping/Codex 協業セクション。docs/agents/anping-skills.md。docs/agents/project-knowledge.md。CONTEXT.mdまたはCONTEXT-MAP.md。docs/adr/README.md。.gitignoreへの安全な除外項目。例: セッション移行を使用するプロジェクトの場合はcodex_sessions/。
プロジェクトが setup-matt-pocock-skills も使用する場合、同じ意味の Agent skills ブロックを重複して書き込まないでください。既存のセクションを更新またはマージします。
7. 検証
書き込み後、まず軽量な検証を行ってから完了を報告します。
- 変更した重要なセクションを再度読み込み、内容が意図したファイルに含まれていることを確認します。
- Anping / Agent skills / Multi-Agent Orchestrator のブロックが重複していないことを確認します。
- 作成すべきファイルが存在することを確認します。例:
docs/agents/anping-skills.md、CONTEXT.mdまたはCONTEXT-MAP.md、docs/adr/README.md。 - YAML、TOML、JSON、またはその他のパース可能な設定を変更した場合は、ローカルパーサーを使用してフォーマットを検証します。
- 何らかの選択が実行されなかった場合は、その理由と残存リスクを記録します。
8. 終了
最後に以下を報告します。
- どの機能が有効化されたか。
- どのファイルが変更されたか。
- どのスキルがインストールされ、どのスキルが単に推奨されただけか。
- 今後ユーザーがどのような一言でこれらの機能をトリガーできるか。
- 残存リスク（例: 外部スキルが未インストール、GitHub認証情報が利用不可、プロジェクト目標がまだ不明確）。
ユーザーが明示的に要求しない限り、自動的にコミット、プッシュ、または公開アップロードしないでください。