project-init-orchestrator

プロジェクト初期化オーケストレーター

最小限で安全なセットアップ経路を選択します。新しい Shipshit.dev のプロダクトリポジトリでは、まず npx @shipshitdev/v0 を主要なスキャフォルダーとして使用し、生成されたワークスペースをカスタマイズして検証します。既存のリポジトリ、修復、または v0 で対応していないプロジェクトタイプには、より低レベルの初期化スキルを使用します。

許可されたスコープ

ユーザーの依頼と既存の承認の範囲内でのみ作業してください。このスキルを読み込んでも、新たな権限は付与されません。報告のみの依頼は報告のみにとどめ、依頼者が指定した対象、ホスト、プロバイダー、コスト制限を守り、スコープを拡大する前に確認を求め、それらの制限を委任先にも伝えてください。

契約

入力：

• 対象プロジェクトのパスとプロジェクト名
• プロジェクトタイプ：新しい Shipshit.dev プロダクト、既存のリポジトリ、ドキュメントのみ、ライブラリ、またはカスタム
• プロジェクトディレクトリとプロダクト名、プロダクトのスコープまたは PRD 形式の概要
• 希望するアプリの提供形態、ルート、エージェントへの引き継ぎ（codex、claude、または skip-agent）、および GitHub のセットアップ

出力：

• 選択した初期化経路
• 委任したスキルまたは使用した v0 コマンドの一覧（v0 コマンドまたは対話形式の経路）
• 生成されたワークスペースの概要、作成または変更したファイル／ディレクトリ
• 品質ゲートと起動状況
• アプリ固有のカスタマイズと、残りの手動セットアップに関する後続タスク

作成／変更対象：

• npx @shipshitdev/v0 を使用した新しいプロダクトリポジトリ：v0 が生成する .agents/skills、.agents/memory、.claude、.codex、apps、packages、.v0 ファイルを含む Bun/Turbo リポジトリ
• v0 の生成後にカスタマイズする場合に限り、アプリ固有のファイル
• 委任先でセットアップを行う場合、既存リポジトリの .agents/、.claude/、.codex/、lint、テスト、およびスキャフォールドのファイル

外部への影響：

• v0 または委任先のセットアップスキルを使用すると、依存関係がインストールされ、apps/web が起動される場合があります
• GitHub フラグを付けて v0 コマンドを実行した場合に限り、GitHub リポジトリまたは issue が作成される場合があります

確認が必要な場合：

• GitHub リポジトリまたは issue を作成する前
• 現在のワークスペース外、または空ではないディレクトリでセットアップを実行する前
• 既存のエージェント／設定ファイル、または v0 の完了後に生成されたアプリファイルを上書きする前

委任先：

• AI プロジェクトコンテキストのみが必要な既存リポジトリには agent-folder-init（v0 が生成したリポジトリには使用しません）
• リポジトリの修復または v0 後のカスタマイズには linter-formatter-init、testing-cicd-init、husky-test-coverage、および shadcn（セットアップモード）
• 既存のコードベース内で小規模なモジュール／コンポーネントを追加する場合は scaffold

使用する場面

このスキルは、ユーザーが次のような場合に自動的に有効になります。

• プロジェクトをゼロから始める
• 1 つのコマンドで Shipshit.dev プロダクトを一通りセットアップしたい
• AI ファーストの開発インフラとコード品質ツールが必要
• 「プロジェクトを初期化」「新しいプロジェクトをセットアップ」「プロジェクトをブートストラップ」と依頼する
• 複数のプロジェクトで一貫したセットアップを行いたい

オーケストレーション対象のスキル

順序	スキル	目的	必須
1	npx @shipshitdev/v0	新しい Shipshit.dev プロダクトリポジトリ	条件付き
2	agent-folder-init	既存リポジトリ向けの AI ドキュメントと規約	条件付き
3	linter-formatter-init	ESLint/Biome、フォーマッター、コミット前の修復	条件付き
4	testing-cicd-init / husky-test-coverage	テストと CI のゲート	任意
5	scaffold	モジュール／コンポーネントの段階的な追加	任意

経路の選択

次の順序で選択してください。

1. 新しい Shipshit.dev プロダクトリポジトリ：npx @shipshitdev/v0 を実行します。
2. 新しい非プロダクトリポジトリ：依頼されたリポジトリ構成のみをスキャフォールドし、その後、エージェント用ドキュメントとゲートを追加します。
3. AI コンテキストが不足している既存リポジトリ：agent-folder-init を実行します。
4. 品質ゲートが弱い既存リポジトリ：linter、テスト、CI のスキルのみを実行します。
5. 機能／モジュールが 1 つ必要な既存リポジトリ：3 つ以上の例を見つけてから scaffold を実行します。

v0 を使用したセットアップでは、ユーザーがすべての入力を提示していない限り、対話モードを使用してください。

npx @shipshitdev/v0 <project-directory>

対話なしで Shipshit.dev プロダクトをセットアップする場合：

npx @shipshitdev/v0 <project-directory> \
  --scope "<product scope>" \
  --agent codex \
  --apps web,app,desktop,mobile,extension,cli \
  --routes overview,new-task,search,inbox,activities \
  --no-github

CI／スモークテストの場合、またはユーザーがスキャフォールドの書き込みのみを希望する場合は、--skip-agent、--no-install、--no-start を使用してください。

レガシー手動ルート

v0 が適切でない場合、または既存のワークスペースを拡張する場合にのみ使用してください。v0 を利用できない場合、またはユーザーが明示的にバイパスする場合を除き、新しい Shipshit.dev 製品リポジトリでは使用しないでください。

スタック：Next.js 16（proxy.ts）＋ React 19 ＋ TypeScript 6 ＋ Tailwind v4 CSS-first（フロントエンド）、NestJS 12 ＋ Prisma 7/Postgres ＋ Better Auth ＋ Swagger（バックエンド）、カバレッジ 80% の Vitest ＋ Biome ＋ GitHub Actions CI、Bun パッケージマネージャー。依存関係のバージョン固定はすべて scripts/init-workspace.py の先頭にある V テーブルに記載されています。npm view <pkg> version で更新してください（Expo パッケージは最新リリースではなく、SDK の bundledNativeModules.json に従います）。

手順の全体、生成される構成、主要なコードパターン、開発コマンドについては、references/legacy-manual-route.md を読み込んでください。ヘルパースクリプトは scripts/ にあります（init-workspace.py、add-api-collection.py、add-frontend-app.py）。生成後、bun install を実行し、.env.example を api/.env にコピーして、api/ から bun run prisma:migrate を実行してください。続けて bun run prisma:generate を実行します（Prisma 7 では migrate でクライアントがビルドされなくなったため、スキーマ変更のたびに再実行してください）。また、生成されたファイルを Biome で整形するため、bun run lint:fix を一度実行してください。add-api-collection.py で追加したコレクションは AuthGuard で保護され、リクエスト入力ではなくセッションから取得したサインイン中のユーザーに紐付けられます。

使い方

クイックスタート（推奨）

ユーザーが「プロジェクトを初期化して」または「新しいプロジェクトをセットアップして」と言った場合：

1. Ask for project context:
   - Project path (default: current directory)
   - New Shipshit.dev product or existing repo repair?
   - Product scope if using v0
   - App surfaces and routes if non-default
   - Agent to hand off to: codex or claude
   - Need existing-repo repair or incremental scaffolding?

2. Execute phases in order:
   v0 route OR existing-repo phases → verification

既存リポジトリの修復

v0 が適切なルートではないと判断した後にのみ、低レベルのスキルを使用してください。

1. AI ドキュメントとエージェント設定には agent-folder-init を使用します。
2. リント／フォーマットの不整合には linter-formatter-init を使用します。
3. テストと CI のゲートには testing-cicd-init または husky-test-coverage を使用します。
4. 要求されたモジュール、エンドポイント、コンポーネント、またはパッケージには scaffold を使用します。

ルート一覧

リクエスト	主なルート	備考
新しい Shipshit.dev 製品リポジトリ	npx @shipshitdev/v0	デフォルトのルートです。アプリの各サーフェスとエージェントのセットアップが含まれます。
新しい非製品リポジトリ	最小限のスキャフォールド ＋ agent-folder-init	要求されたリポジトリに見合った範囲のセットアップにします。
既存リポジトリの AI コンテキスト	agent-folder-init	アプリケーションソースは生成しません。
既存リポジトリの品質ゲート	リンター／テスト／CI スキル	不足しているゲートのみを修復します。
既存リポジトリの機能／モジュール	scaffold	まずローカルの例を 3 件以上確認します。

ベストプラクティス

実行順序

• 新しい Shipshit.dev 製品では、最初に v0 を実行します。
• 既存リポジトリでは、リポジトリ固有の修復作業を行う前に AI ドキュメントを追加します。
• リンターとフォーマッターの両方が未設定の場合は、テストフックより先にセットアップします。
• 対象のコードベースのパターンを把握してから scaffold を実行します。

カスタマイズ

• 各フェーズがすでに設定済みであれば、省略できます。
• 各フェーズは冪等であり、安全に再実行できます。
• オーケストレーション後に設定をカスタマイズできます。

検証チェックリスト

オーケストレーション後、次を確認してください。

• 選択したルートがユーザーのリクエストに合っている
• 明示的な例外がない限り、新しい製品リポジトリは v0 を通じて作成されている
• 既存リポジトリへの変更が、委任された修復／追加の範囲に限られている
• bun lint、bun test、またはリポジトリで文書化された同等のコマンドが、利用可能な場合に動作する

やり取りの例

ユーザー：「~/projects/my-saas に新しい製品をセットアップして」

オーケストレーターの応答：

Route: new Shipshit.dev product repo → v0.

npx @shipshitdev/v0 ~/projects/my-saas --agent codex --no-github

参考資料

• references/legacy-manual-route.md - 手動のワークスペース手順
• references/templates/ - コード生成テンプレート（NestJS の service/controller/e2e 仕様、Better Auth の guard/service/client、proxy.ts、React コンポーネント／フックの仕様、モック認証クライアントを使ったフロントエンドのテストセットアップ）
• references/vitest.config.ts - バックエンドの Vitest 設定（カバレッジ 80%、unplugin-swc）
• references/vitest.config.frontend.ts - フロントエンドの Vitest 設定（jsdom）
• references/github-actions/ci.yml - CI/CD ワークフロー
• references/architecture-guide.md - アーキテクチャ上の決定事項
• references/coding-standards.md - コーディング規則
• references/deployment-guide.md - デプロイのガイド

トラブルシューティング

フェーズが完了しない

• 依存関係（node、python3）がインストールされているか確認します
• プロジェクトディレクトリへの書き込み権限を確認します
• 競合する設定が存在しないか確認します

セットアップ後にリンティングエラーが発生する

• bun run lint:fix を実行して自動修正します
• ルートの biome.json がスタックに合っているか確認します
• TS を使用している場合は TypeScript の設定を確認します

プリコミットフックが実行されない

• bunx husky install を手動で実行します
• .husky/pre-commit が存在し、実行可能であることを確認します
• package.json の prepare スクリプトを確認します

prisma generate または bun run build で DATABASE_URL を求められる

• スキャフォールドの api/prisma.config.ts は process.env.DATABASE_URL を直接読み取るため、 .env がなくても generate と build は動作します。URL が必要なのは prisma migrate と実行中の API のみです。未設定の場合にエラーを発生させる env("DATABASE_URL") には切り替えないでください。