bootstrap-repo

プロジェクトをスキャフォールドする

新規リポジトリを検証済みのベースラインまで立ち上げます。すべての品質ツールが組み込まれ、正常に動作することが実証された骨組みを用意し、最初の機能開発を最初からグリーンな状態で始められるようにします。

機能のコードに先走らないでください。成果物はハーネスであり、合格するサンプルテストを1つ実行して検証します。それ以上は不要です。

進捗を記録する

以下の各ステップ（0～4）について ToDo を作成し、順番に完了してください。各ステップは、完了条件を満たした場合にのみチェックを付けます。ステップ0はゲートです。ここで停止する場合（新規作成ではない場合）は、リストを中断して適切な手順へ案内してください。それ以外の場合、このゲートで防ぐべき失敗は、ステップを飛ばすことです。つまり、ベースラインが検証されないままになること、または configure-repo への引き継ぎを忘れることです。

0. 対象が新規作成か確認する — ゲート

スキャフォールディングでは、プロジェクトのルート（git リポジトリ、ルートマニフェスト、ルート README、ルート CI、ルートの pre-commit フック）に書き込みます。既存プロジェクトの上で実行すると、実際の設定と競合したり、上書きしたりする可能性があります。したがって、何よりも先に、スキャフォールディングを行う場所を特定し、空であることを確認してください。このゲートは省略できません。また、感覚で判断するものでもありません。チェックを実行してください。

対象ディレクトリを特定します。 デフォルトは現在の作業ディレクトリです。ユーザーが「packages/ の下に bot パッケージをスキャフォールドする」のように配置先を指定した場合、対象はそのパスです。現在の作業ディレクトリがすでに内容のあるリポジトリのルートであっても、ユーザーが新しいサブパッケージを求めているなら、対象はその新しいサブディレクトリです。ルートの判定で止まらず、そのサブディレクトリを分類してください。

自分で確認します（ディレクトリの中身をユーザーに尋ねず、確認してください）。

• ls -A <target> — 存在するか、空かを確認します。
• git -C <target> rev-parse --is-inside-work-tree および git -C <target> ls-files | wc -l — git リポジトリ内か、追跡対象ファイルがいくつあるかを確認します。
• 対象にパッケージマニフェスト（package.json、Cargo.toml、pyproject.toml、go.mod など）があるかを確認します。

分類して分岐します。

対象の状態	意味	対応
存在しない、または存在しても空／.git、README、LICENSE のみで、マニフェストがない	新規作成	ステップ1に進みます。
既存の git リポジトリ内にある新規／空のサブディレクトリ（例：モノレポ内の packages/bot）	サブパッケージ	サブディレクトリを対象としてステップ1に進み、inside-existing-repo = true に設定します（ステップ2ではルートに触れる作業を省略します）。
マニフェストまたは多数の追跡対象ファイルがある、実在するプロジェクト	新規作成ではない — 停止	スキャフォールドしないでください。以下に従って案内します。

停止が必要な場合は、選択肢を並べずに適切な手順へ案内します。

• ユーザーが既存リポジトリでこのスキルセットを使いたい（トラッカーの設定、コマンドの検証、ドキュメントの整備など）場合は、スキャフォールディングではなく configure-repo の対象です。実行するよう伝えてください。
• ユーザーがこのリポジトリ内に新しいパッケージを作りたい場合は、新しいサブディレクトリのパスを確認し、そのサブディレクトリを対象にこのゲートを再実行してください（サブパッケージの行に該当するはずです）。
• 間違ってここに来た場合は、停止してユーザーが再検討できるようにしてください。

検出したケースと、どの案内が適用されるかを明示してください。**完了条件：**対象を新規作成またはサブパッケージに分類し、解決済みのパスをユーザーに確認した場合、または停止して案内先を明示した場合です。

1. 技術スタックを詳しく確認する

必須のサブスキル：clarify-decisions を使い、対象の技術スタックとレイアウトに関する判断を確定します。各項目について、選択肢、影響、おすすめのデフォルトを含む完全な質問カードを（インラインのみで）提示してください。

• プロジェクト名（マニフェストと README で使用）
• 言語とランタイム
• フレームワーク（または「なし — プレーンなライブラリ／CLI」）
• テストランナー
• フォーマッターとリンター
• パッケージマネージャー
• リポジトリのレイアウト（単一パッケージかワークスペース／モノレポか、ソースとテストのディレクトリ構成）
• ライセンス
• 結果をコミットするか、先にステージングしてレビューするか

事実関係は自分で調べてください（ユーザーがインストールしているツール、サブパッケージモードでの親リポジトリの既存設定など）。ユーザーには判断が必要な項目だけを確認します。

**完了条件：**上記のすべての判断が明示的に確認され、解決済みの対象パスを含む1つの要約ブロックにまとめて再提示され、ユーザーの承認を得た場合です。

2. スケルトンの作成

確定した選択に基づき、解決済みのターゲットにスケルトンを作成します。サブパッケージモード（inside-existing-repo = true）では、(ルートのみ) と記された手順をスキップします。親リポジトリがすでにそれらを管理しているためです。また、競合する設定のコピーを作成せず、親の共有設定を継承します。

1. Git (ルートのみ) — ディレクトリがまだリポジトリでなければ git init を実行し、スタックに適した .gitignore を作成します。サブパッケージモードでは、初期化せず、ルートの .gitignore にも手を加えません。必要な場合に限り、パッケージローカルの除外設定を追加します。
2. プロジェクトのスケルトン — マニフェスト、ソースディレクトリ、最小限のエントリーポイントを用意します。サブパッケージモードでは、ワークスペースの共有ツールチェーン設定を拡張し（例：ルートを extends する tsconfig）、ワークスペースにパッケージを登録します。
3. テストハーネス — ランナーをインストールして設定し、パスするサンプルテストをちょうど1つ用意します。その目的は配線（インポートが解決される、ランナーがファイルを検出する、アサーションが実行される）を証明することであり、実際の動作をテストすることではありません。
4. フォーマッターとリンターの設定 — 設定をコミットし、format、lint、typecheck（該当する場合）をそれぞれ単一のコマンドで実行できるようにします。サブパッケージモードでは、ルートの設定を継承し、パッケージレベルの上書きのみを追加します。
5. コミット前フック (ルートのみ) — コミットごとに、ステージされたファイルをフォーマットしてから、リンター、型チェック、テストを実行します。スタックで一般的なフックの仕組みを使います。サブパッケージモードでは、競合するルートフックをインストールせず、親リポジトリの既存フックにパッケージを対象とする形で統合します。
6. CI のひな型 (ルートのみ) — プッシュ時とプルリクエスト時に同じ検証コマンドを実行するワークフローを1つ用意します。サブパッケージモードでは、新しいパイプラインを作成するのではなく、既存の CI にパッケージを対象とするジョブを追加します。
7. README のひな型 — プロジェクト名、1段落の説明文のプレースホルダー、インストールと検証のコマンドを記載します。ターゲットに配置します（サブパッケージモードでは <target>/README.md に配置し、リポジトリルートには置きません）。
8. ドキュメントの種 — ターゲットを基準として、CONTEXT.md（スキルセットの templates/CONTEXT.md を使用）、docs/specs/INDEX.md（ドメインルーター。templates/specs-INDEX.md を使用）、docs/specs/catalog/app.md（templates/specs-catalog-domain.md を使用し、ドメインは App）、空の docs/adr/ ディレクトリを用意します。パックの種は、存在する最初のパスを使って次の順に解決します：（1）この SKILL.md と同じ場所にある templates/、（2）変数が設定されている場合は ${CLAUDE_PLUGIN_ROOT}/templates、（3）この SKILL.md からの相対パス ../../../templates。任意のプロジェクトドキュメントレイヤー： これを一度だけ提案します（グリーンフィールドの複数機能プロジェクトには有用ですが、小規模なプロジェクトでは省略して後から追加できます）。ユーザーが希望した場合は、templates/product-vision.md、templates/architecture-INDEX.md、templates/product-guidelines.md を使って docs/product/vision.md、docs/architecture/INDEX.md、docs/product/guidelines.md も用意します。希望しない場合は、これらを一切用意しません。configure-repo の書き込み引き継ぎで、このレイヤーを有効にすることもできます。

完了条件： 該当するすべての項目が存在し、コミット済み（またはユーザーがステップ1で選んだ方法に応じてステージ済み）であること。

3. ベースラインを検証する

必須サブスキル：prove-claim を使用します。検証スイート（型チェック、リンター、テスト）全体を改めて実行し、出力を確認します。ルートモードでは、コミット前フックが実際に起動し、成功することも証明します（使い捨てのコミットまたはドライランを使用）。

失敗した、または検証されていないチェックが残った状態で引き継ぐスケルトンは、完了ではありません。先に進む前に、問題のある部分を修正するか削除してください。

完了条件： すべての検証コマンドが成功し、成功した出力をユーザーに提示していること。

4. 引き継ぎ

スキャフォールドが完成したことと、次のステップとして configure-repo を実行し、エージェント向け設定（docs/agents/*.md — 検証コマンド、トラッカー、ラベル、リリース手順）を作成することをユーザーに伝えてください。docs/agents/ は自分で作成しないでください。このウィザードが管理します。

スキル全体の完了条件： リポジトリのルートから、1つのコマンドで依存関係をインストールし、もう1つのコマンドで対象の検証スイートをすべて成功させます。最終的なまとめでは、両方のコマンドを明示してください（サブパッケージモードの場合、検証コマンドの対象は新しいパッケージに限定します）。