ce-setup

Compound Engineering のセットアップ

対話方法

以下の各質問は、現在のツール一覧にあるホストのブロッキング質問ツールを使って行ってください（ホスト固有の名前ではなく、機能で一致させます）。現在のツール一覧に存在することは、そのツールが利用可能である証拠です。存在を確認するために、ユーザー向け質問ツールを呼び出してはいけません。一致するツールが一覧にあるものの読み込まれていない場合は、ホストのツール検出プリミティブを使ってその機能を読み込んでください。別のホストのツール名を探してはいけません。該当するツールが一覧にない場合、または実際の質問呼び出しでエラーが発生した場合に限り、ホストのユーザーに表示されるチャット画面で番号付きリストを使ってください。黙って省略したり、自動設定したりしてはいけません。

ce-setup は軽量なヘルスチェックとリポジトリ内設定の補助ツールです。任意の依存関係をすべて一括インストールするものではありません。不足しているツールは任意の機能として報告されるため、ユーザーは利用するワークフローに必要なものだけをインストールできます。

Pack のスキャフォールド

呼び出し時に追加、作成、またはスキャフォールドする Compound Pack が指定されている場合（pack:<id> 引数、または同じ内容の文章によるリクエスト）、このスキルのディレクトリにある references/pack-scaffold.md を読み、Phases 1-2（リポジトリ内の問題の診断と修正）の代わりに、その手順に従ってください。ユーザーの承認後にのみ Pack とその設定エントリーを書き込み、ヘルスチェックを自ら実行して、Phase 3（概要）に結果を報告します。

成果物ルートの解決

成果物ディレクトリ（solutions、plans、ideation、その他 CE 管理のツリー）を読み書きするすべての Compound Engineering スキルは、以下のルールでルートを解決します。ce-setup はその正規の説明を保持し、解決されたルートを報告するため、他のスキルを実行する前に成果物の保存先を担当者が確認できます。

成果物パスを組み立てる前に、CE 成果物ルート <root> を解決してください。

• 読み取り：docs_root は <repo-root>/.compound-engineering/config.yaml からのみ読み取ります（<repo-root> = git rev-parse --show-toplevel）。config.local.yaml から読み取ってはいけません。未設定の場合、これまでどおり <root> は docs です。
• 検証：設定値がある場合は検証します。リポジトリ相対のディレクトリであり、シンボリックリンクを解決した実際のパスがリポジトリ内にとどまり、リポジトリルートでも .git/ 配下でもない必要があります。条件を満たさない場合は、docs_root とその値を示してエラーで停止してください。docs にフォールバックしてはいけません。
• 使用：<root> を唯一の成果物保存先として使用します。存在しない場合は作成し、各パスを <root>/<subdir>（このスキル固有のサブディレクトリ）として組み立て、docs を併せて読み取ってはいけません。

Phase 1：診断

Step 1：プラグインのバージョンを特定する

プラットフォームで確認できる場合は、プラグインのメタデータまたはマニフェストを読み取り、インストールされている compound-engineering プラグインのバージョンを検出します。バージョンを特定できない場合は、このステップを省略してください。

バージョンが見つかった場合は、--version を指定してチェック用スクリプトに渡します。それ以外の場合は、このフラグを省略してください。

Step 2：ヘルスチェックを実行する

スクリプトを実行する前に、次を表示します。

Compound Engineering -- checking your environment...

同梱のチェック用スクリプトを実行します。SKILL_DIR には、この ce-setup の SKILL.md を読み込んだ絶対ディレクトリを設定してください。Bash ツールの CWD はユーザーのプロジェクトであり、スキルのディレクトリではないため、単独の scripts/ パスでは解決できません。

SKILL_DIR="<absolute path of the directory containing this SKILL.md>";
if [ -f "$SKILL_DIR/scripts/check-health" ]; then bash "$SKILL_DIR/scripts/check-health" --version VERSION; else echo "Bundled health script not found at $SKILL_DIR/scripts/check-health; run the inline checks from ce-setup instead."; fi

Step 1 でバージョンを特定できなかった場合は、同じコマンドを --version VERSION なしで使用してください。

スクリプトを利用できない場合は、references/repo-fixes.md に記載されている同等のインライン処理を実行してください。

診断結果をユーザーに表示します。不足している任意のツールはセットアップの失敗ではありません。ヘルスレポートには、解決された成果物ルートと、その取得元の設定レイヤー（上記の成果物ルートの解決に従う）が含まれています。CE の成果物が書き込まれる場所を担当者が確認できるよう、その行を表示してください。config.yaml がない場合は、不在として報告されますが、プロジェクトの問題ではありません。

ステップ 3：修正が必要かどうかを判断する

ヘルスレポートに記載されたリポジトリ内の修正は、レポートで診断したチェックアウトにのみ適用されます。フェーズ 2 で別の書き込み可能なチェックアウトに変更を加える場合は、まずそのチェックアウトを診断してください。プラグインのバージョンやオプションのツールなど、セッションレベルの診断結果は、このセッションのフェーズ 1 から取得します。

ヘルスレポートを確認したら、書き込み可能なチェックアウトがあるかどうかに基づいて、フェーズ 2 を実施するか判断します。

• このセッションに書き込み可能な git チェックアウトがある場合は、project_issues が 0 でも、ローカルでフェーズ 2 を実施します。フェーズ 2 では常にサンプルを更新し、config.yaml がない場合は常に作成を提案します。
• このセッションに書き込み可能なチェックアウトはないものの、ユーザーがリポジトリを指定し、ハーネスが書き込み可能なチェックアウトを備えたリモートリポジトリ作業環境を提供している場合は、その環境でフェーズ 2 を実施し、フェーズ 3 でリモートのリポジトリ内の修正を報告します。
• それ以外の場合は、フェーズ 2 を省略してフェーズ 3 に進み、書き込み可能なチェックアウトがないためリポジトリ内への変更を見送ったことを伝えます。

このマシンに関する 2 つの提案は、フェーズ 2 の実施有無にかかわらず行います。レポートにレガシーの Compound Codex ツールマップが記載されている場合は、このスキルのディレクトリにある references/legacy-codex-tool-map.md に従って削除することを提案します。バンドルされたヘルススクリプトで node の行が利用可能と報告された場合は、references/acpx-cache-warm.md に従って、モデル間で使うピア向けに npm キャッシュをウォームアップすることを提案します。

レポートに次のプロジェクトの問題が記載されている場合は、それらも修正します。

• 古くなった compound-engineering.local.md
• .compound-engineering/config.local.yaml が存在するものの、安全に gitignore されていない
• .compound-engineering/config.example.yaml が存在しない、または古くなっている
• ヘルスレポートで ce-work スキルの実装エンジンが利用不可または無効と判定されている、廃止されたスカラー形式のルーティングキーが検出されている、あるいは形式が不正な休止中の work_engine_preferences または形式が不正な work_engine_effort が報告されている
• ヘルスレポートで docs_root が無効と判定されている（Invalid docs_root ...）— 修正されるまで CE の成果物は書き込まれません

オプションのツールが不足している場合、一括インストールは提案しないでください。診断結果には、該当するインストールコマンドまたはプロジェクト URL がすでに出力されています。「使用するワークフローに必要なオプションのツールだけをインストールしてください」と伝えます。

フェーズ 2：リポジトリ内の問題を修正する

リポジトリ内の変更を行う前に、このスキルのディレクトリにある references/repo-fixes.md を読みます。そこには、ステップ 4～9 が記載されています。内容は、古くなった compound-engineering.local.md の削除、サンプル設定の更新、config.yaml の作成提案、無効な work_engine_preferences と docs_root の修復、2 つの .gitignore に関する提案、エージェントへの指示に関する提案（ナレッジストアへの言及、コンパウンディング指示、ce-noslop 向けのチャットレジスター指示）です。

ここに記載されているすべてのパスは、現在の作業ディレクトリではなく、リポジトリのルート（git rev-parse --show-toplevel）を基準に解決します。生成されたサンプルファイルのメンテナンスは、フェーズ 2 で行う作業です。具体的には、config.example.yaml を更新し、置き換えられた config.local.example.yaml を削除します。ユーザーが所有するファイルへの変更は、すべて事前に提案し、ユーザーの承認がある場合にのみ適用します。

フェーズ 3：要約

ユーザーが実行できる呼び出しの表記。 セットアップの要約では、デフォルトで /ce-setup を使用します。$ce-setup を使用するのは、アクティブなホストが Codex である場合、またはドル記号を接頭辞とするスキル呼び出しが明示的に文書化されている場合に限ります。oh-my-pi（omp）では、/skill:ce-setup を使用します。インラインコードとして出力するのは呼び出しだけとし、形式は 1 つだけ出力します。

簡潔な要約を表示します。

✅ Compound Engineering setup complete

Fixed:     <fixes applied, or none>
Skipped:   <fixes declined, or none>
Optional:  <missing optional tools, or all available>

Run `<rendered invocation>` anytime to re-check.