@careerchain/stdd 0.1.0

package/assets/.claude/skills/reverse-engineering-feature-spec/guides/figma-capture.md

@@ -0,0 +1,313 @@
+# Figma UIキャプチャガイド - Playwright MCPを使った画面キャプチャとFigma取り込み
+
+リバースエンジニアリング時に、実装済みのUIをPlaywright MCPで操作・キャプチャし、Figmaデザインファイルとして整理する手順。
+
+---
+
+## 目的
+
+- 実装済みUIの**視覚的なドキュメント**をFigmaに集約する
+- REQUIREMENTS.mdの「UI/UXデザイン」セクションからFigmaリンクで参照できるようにする
+- デザインの現状を正確に記録し、今後のUI改善・レビューの基盤とする
+
+---
+
+## 前提条件
+
+- 対象アプリがローカル環境で起動していること
+- Playwright MCPが利用可能であること
+- Figmaアカウントがあること
+
+---
+
+## 作業フロー
+
+```
+1. キャプチャ計画の作成（画面一覧・状態の洗い出し）
+   ↓
+2. Playwright MCPでアプリを操作し、各画面のスクリーンショットを取得
+   ↓
+3. Figmaファイルを作成し、スクリーンショットをフレームとして配置
+   ↓
+4. REQUIREMENTS.mdの「UI/UXデザイン」セクションにFigmaリンクを記載
+   ↓
+5. スクリーンショットファイルを削除（gitにはコミットしない）
+```
+
+---
+
+## Step 1: キャプチャ計画の作成
+
+コードリーディング（Phase 1）の結果を元に、キャプチャすべき画面と状態を一覧化する。
+
+### 洗い出すべき画面状態
+
+| カテゴリ | 状態例 |
+|---------|--------|
+| **初期状態** | データなし（空）、ローディング中 |
+| **データあり** | 1件表示、複数件表示 |
+| **フォーム** | 未入力、入力済み、バリデーションエラー |
+| **モーダル** | 開いた状態（新規追加/編集） |
+| **操作結果** | 成功トースト、削除確認ダイアログ |
+| **レスポンシブ** | デスクトップ（1280px）、モバイル（375px） |
+
+### 計画テンプレート
+
+```markdown
+## キャプチャ計画: [機能名]
+
+### デスクトップ（1280x800）
+| # | 画面名 | 状態 | 操作手順 |
+|---|--------|------|---------|
+| 1 | 一覧画面 | データあり | ログイン → 対象ページへ遷移 |
+| 2 | 一覧画面 | データなし | テストデータなしユーザーでログイン |
+| 3 | 追加モーダル | 空フォーム | 「追加」ボタンクリック |
+| 4 | 追加モーダル | 入力済み | フォーム項目を入力 |
+| 5 | 編集モーダル | 既存データ読み込み済み | 編集ボタンクリック |
+| 6 | 削除確認 | ダイアログ表示 | 削除ボタンクリック |
+
+### モバイル（375x812）
+| # | 画面名 | 状態 | 操作手順 |
+|---|--------|------|---------|
+| 1 | 一覧画面 | データあり | （同上、ビューポート変更） |
+| 2 | 追加モーダル | 空フォーム | （同上、ビューポート変更） |
+```
+
+---
+
+## Step 2: Playwright MCPでスクリーンショット取得
+
+### 操作ルール
+
+CLAUDE.mdの「Playwright MCPでのブラウザ操作ルール」に従う:
+
+```
+1. ブラウザを開く
+2. ログイン（テストユーザーを使用）
+3. 対象画面に遷移
+4. 各状態のスクリーンショットを取得
+5. ログアウト
+6. ブラウザを閉じる
+```
+
+### スクリーンショット取得のポイント
+
+**1. ビューポートサイズを明示的に設定する**
+
+```
+デスクトップ: 1280x800
+モバイル: 375x812
+```
+
+**2. 状態を正確に再現してからキャプチャする**
+
+```
+❌ 悪い例: ページを開いた直後にキャプチャ（ローディング中の可能性）
+✅ 良い例: データが表示されたことを確認してからキャプチャ
+```
+
+**3. 画面全体をキャプチャする（フルページ）**
+
+スクロールが必要な長い画面は、フルページスクリーンショットを取得する。
+
+**4. ファイル名は一貫した命名規則に従う**
+
+```
+{feature}-{screen}-{state}-{viewport}.png
+
+例:
+dashboard-overview-with-data-desktop.png
+dashboard-projects-add-modal-empty-desktop.png
+dashboard-projects-list-mobile.png
+```
+
+**5. スクリーンショットの一時保存先**
+
+```
+docs/<app>/<feature-path>/screenshots/
+```
+
+例:
+```
+docs/<app.id>/dashboard/common/screenshots/
+docs/<app.id>/dashboard/projects/screenshots/
+```
+
+⚠️ **重要: スクリーンショットはFigma取り込み後に削除すること。gitにはコミットしない。**
+詳細は「Step 5: スクリーンショットの削除」を参照。
+
+---
+
+## Step 3: Figmaファイル作成
+
+### Figmaファイル構成
+
+```
+Figmaファイル名: <app>-<Feature-Name>
+例: <app.id>-Dashboard-Common
+
+ページ構成:
+├── Desktop（1280px）
+│   ├── フレーム1: [画面名 - 状態]
+│   ├── フレーム2: [画面名 - 状態]
+│   └── ...
+└── Mobile（375px）
+    ├── フレーム1: [画面名 - 状態]
+    └── ...
+```
+
+### Figmaへの取り込み手順
+
+1. Figmaで新しいファイルを作成
+2. 「Desktop」「Mobile」のページを作成
+3. 各スクリーンショットをフレームとして配置
+4. フレーム名を設定（画面名 + 状態を含める）
+5. 必要に応じてアノテーション（注釈）を追加
+
+### フレーム命名規則
+
+```
+[画面名] - [状態]
+
+例:
+Overview Tab - データあり
+Projects Tab - 一覧表示
+Projects - 追加モーダル（空）
+Projects - 追加モーダル（入力済み）
+Projects - 削除確認ダイアログ
+```
+
+---
+
+## Step 4: REQUIREMENTS.mdへの記載
+
+オンボーディングのREQUIREMENTS.mdを参考に、以下のフォーマットで記載する。
+
+### 記載フォーマット
+
+```markdown
+## 3. UI/UXデザイン
+
+### Figmaデザイン
+
+**Figmaファイル**: [<ファイル名>](<FigmaファイルURL>)
+
+#### [画面名1]
+
+- [状態A](<FigmaファイルURL>?node-id=<node-id>)
+- [状態B](<FigmaファイルURL>?node-id=<node-id>)
+
+#### [画面名2]
+
+- [状態A](<FigmaファイルURL>?node-id=<node-id>)
+- [状態B](<FigmaファイルURL>?node-id=<node-id>)
+```
+
+### 記載例（ダッシュボードの場合）
+
+```markdown
+## 3. UI/UXデザイン
+
+### Figmaデザイン
+
+**Figmaファイル**: [<app.id>-Dashboard-Common](https://www.figma.com/design/xxxxx/<app.id>-Dashboard-Common)
+
+#### OverviewTab
+
+- [実績サマリ表示](https://www.figma.com/design/xxxxx/<app.id>-Dashboard-Common?node-id=1-2)
+
+#### タブ切り替え
+
+- [Overviewタブ（アクティブ）](https://www.figma.com/design/xxxxx/<app.id>-Dashboard-Common?node-id=2-2)
+- [Projectsタブ（アクティブ）](https://www.figma.com/design/xxxxx/<app.id>-Dashboard-Common?node-id=3-2)
+
+#### WelcomeSection
+
+- [ウェルカムバナー表示](https://www.figma.com/design/xxxxx/<app.id>-Dashboard-Common?node-id=4-2)
+```
+
+### node-idの取得方法
+
+1. Figmaでフレームを選択
+2. 右クリック → 「リンクをコピー」
+3. URLの`node-id=`パラメータが該当のnode-id
+
+---
+
+## Step 5: スクリーンショットの削除
+
+⚠️ **スクリーンショットはFigmaへの取り込みが完了したら必ず削除する。gitにはコミットしない。**
+
+### 理由
+
+- スクリーンショットはFigmaに取り込むための**一時ファイル**であり、Figmaが正（Single Source of Truth）
+- 画像ファイルはgitリポジトリを肥大化させる
+- UIの更新はFigma上で管理する
+
+### 削除手順
+
+```bash
+# Figma取り込み完了後、screenshotsディレクトリごと削除
+rm -rf docs/<app>/<feature-path>/screenshots/
+
+# 例
+rm -rf docs/<app.id>/dashboard/common/screenshots/
+rm -rf docs/<app.id>/dashboard/projects/screenshots/
+```
+
+### 削除タイミング
+
+```
+スクリーンショット取得 → Figma取り込み → node-idリンク記載 → スクリーンショット削除 → コミット
+```
+
+Figmaリンクの記載が完了し、node-idが正しいことを確認してから削除する。削除後にコミットすることで、スクリーンショットがgit履歴に残ることを防ぐ。
+
+---
+
+## チェックリスト
+
+### キャプチャ計画時
+
+```
+□ コードリーディングで全画面・全状態を洗い出した
+□ デスクトップ・モバイル両方の計画を作成した
+□ フォーム状態（空/入力済み/エラー）を網羅した
+□ モーダル・ダイアログの状態を含めた
+```
+
+### スクリーンショット取得時
+
+```
+□ テストユーザーでログインした
+□ ビューポートサイズを正しく設定した
+□ データが表示されたことを確認してからキャプチャした
+□ 命名規則に従ったファイル名を付けた
+□ 操作完了後にログアウトした
+```
+
+### Figma作成時
+
+```
+□ ファイル名が命名規則に従っている
+□ Desktop/Mobileのページを分けた
+□ フレーム名が画面名+状態を含んでいる
+□ 全スクリーンショットをフレームとして配置した
+```
+
+### REQUIREMENTS.md記載時
+
+```
+□ FigmaファイルURLを記載した
+□ 各画面のnode-id付きリンクを記載した
+□ 複数状態がある画面は状態ごとにリンクを記載した
+```
+
+### スクリーンショット削除時
+
+```
+□ Figmaへの取り込みが完了した
+□ REQUIREMENTS.mdのnode-idリンクが正しいことを確認した
+□ screenshotsディレクトリを削除した
+□ スクリーンショットがgit stagingに含まれていないことを確認した
+```

package/assets/.claude/skills/review-pr-with-agents/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: review-pr-with-agents
+description: |-
+  作成済み PR を `qa-engineer` と `code-reviewer` の2つの専門エージェントに並列でレビューさせ、結果を統合報告する。マージ前の最終チェックを2観点（QA観点＝整合性・テスト・論理バグ／コードレビュー観点＝規約・品質・セキュリティ・レスポンシブ）から同時に行う。PR の新規作成は `create-pr` が担い、本スキルは作成済み PR へのレビュー適用に特化する。
+when_to_use: |-
+  「PRをqa-engineerとcode-reviewerにレビューさせて」「let qa-engineer and code-reviewer handle this pr」「専門エージェントにPRをレビューさせて」「PRをチームレビューに回して」「PRにマルチレビューかけて」「review PR with agents」「PR #123をレビューさせて」「マージ前チェック」「PR最終確認」など、既存の PR を専門エージェントにレビュー依頼するとき。
+allowed-tools: Bash, Read, Grep, Glob, Agent
+---
+
+# Pull Request マルチエージェントレビュー
+
+作成済みのPRを `qa-engineer` と `code-reviewer` の2エージェントに**並列**でレビューさせ、結果を統合してユーザーに報告する。
+
+## 位置付け
+
+- `create-pr`: PRを新規作成する
+- `review-pr-with-agents`（本スキル）: **既にあるPR**を専門エージェントに投げてレビューしてもらう
+- `auto-implement` の Phase 3/4 と観点は重なるが、本スキルはパイプライン全体ではなく「レビュー適用のみ」に切り出した単発操作
+
+## 1. PR番号の特定
+
+引数で明示的にPR番号（`#1198` / `1198`）が指定されていればそれを使う。無ければ現在のブランチに紐づくPRを特定する。
+
+```bash
+# 現在のブランチに紐づくPR番号を取得
+gh pr view --json number,title,headRefName,baseRefName,url
+```
+
+該当PRが存在しない場合はその旨をユーザーに伝えて停止（create-pr を案内）。
+
+## 2. PR情報の収集
+
+次をまとめて把握する：
+
+```bash
+gh pr view <PR番号> --json number,title,body,headRefName,baseRefName,url,commits,files
+git fetch origin <baseRef>
+git log --oneline origin/<baseRef>...HEAD
+```
+
+集める情報：
+
+- PR番号・タイトル・概要（body）
+- base ブランチ（`.stdd.config.yml` の `project.primary_branch`）
+- 対象コミット一覧（`origin/<base>...HEAD`）
+- 主要な変更ファイル
+
+## 3. worktree / devcontainer の確定
+
+レビュー対象の作業が走っている worktree を確定する。
+
+```bash
+git worktree list
+```
+
+該当ブランチの worktree パスを控え、対応する devcontainer コマンドのテンプレを用意する：
+
+```
+devcontainer exec --workspace-folder <WORKTREE_PATH> --override-config <WORKTREE_PATH>/.devcontainer/devcontainer.override.json bash -c "<COMMAND>"
+```
+
+**重要**: devcontainer コマンドは必ず `devcontainer exec` から始める（変数代入を先頭に置かない）。プロジェクトの CLAUDE.md / memory「devcontainerコマンドパターン」を参照。
+
+## 4. 2エージェントを並列起動
+
+`qa-engineer` と `code-reviewer` を**同一メッセージ内の2つの `Agent` 呼び出し**として同時に起動する。片方を待ってから次を投げてはいけない（並列で効率化する意図）。片方をバックグラウンドにしたい場合は `run_in_background: true` を併用してよい。
+
+### 4.1 qa-engineer へのプロンプト雛形
+
+```
+PR #<番号> (ブランチ `<headRef>`) のQAレビューを実施してください。
+
+## PR概要
+<タイトル>
+<body のサマリ>
+
+## 対象コミット（origin/<base> からの N コミット）
+<git log --oneline の結果を貼り付け>
+
+## 作業場所
+- worktree: <WORKTREE_PATH>
+- devcontainer コマンドテンプレ:
+  devcontainer exec --workspace-folder <WORKTREE_PATH> --override-config <WORKTREE_PATH>/.devcontainer/devcontainer.override.json bash -c "cd /workspace/<app> && npm test -- --no-cache 2>&1 | tail -80"
+
+## レビュー観点
+1. Spec ⇔ テスト ⇔ 実装 の整合性（REQUIREMENTS.md / TECH_DESIGN.md ↔ *.test.* ↔ 実装ファイル）
+2. 影響する app のユニットテスト全体 pass/fail（--no-cache で実行）
+3. 論理的なバグ・エッジケース
+4. seed/マイグレーション変更時は既存データとの整合
+
+## 報告形式
+Critical / Major / Minor で分類し、ファイル:行で指摘。テスト結果サマリ含め <文字数制限> 字以内で。
+```
+
+### 4.2 code-reviewer へのプロンプト雛形
+
+```
+PR #<番号> (ブランチ `<headRef>`, worktree `<WORKTREE_PATH>`) のコードレビューを実施してください。
+
+## PR概要
+<タイトル>
+
+## 対象コミット（origin/<base> からの N コミット）
+<git log --oneline の結果>
+
+## レビュー観点
+1. CLAUDE.md 規約準拠（Domain層構造・命名・コメント方針・npm workspaces 依存ルール）
+2. 品質（YAGNI・Rule of Three・過剰設計の排除）
+3. セキュリティ（IDOR・XSS・SQLi・認可漏れ・URLパラメータ信頼）
+4. レスポンシブ / アクセシビリティ
+5. STDD 整合性（Spec → Test → 実装のフロー痕跡）
+
+## 主な変更ファイル
+<gh pr view の files 結果を貼り付け>
+
+## 報告形式
+Critical / Major / Minor で分類し、ファイル:行で指摘。マージ可否判定と総括を <文字数制限> 字以内で。
+```
+
+### 4.3 並列起動時の工夫
+
+- 両エージェントは独立作業のため、どちらかを `run_in_background: true` にして、もう一方が完了してから結果を束ねてもよい
+- ただし**片方ずつ起動するのは禁止**（並列化のメリットが消える）。1回のメッセージで2つの Agent tool use を含めること
+
+## 5. 結果の統合・報告
+
+両エージェントのレポートを受け取ったら、重複や類似の指摘をまとめ、以下の形式でユーザーに報告する：
+
+```
+## PR #<番号> マルチレビュー結果
+
+### テスト結果（qa-engineer）
+- <app名>: X passed / Y skipped / Z failed
+
+### Critical（両エージェント合算）
+- （無ければ「なし」）
+
+### Major
+- [QA] <指摘内容>（<ファイル:行>）
+- [CR] <指摘内容>（<ファイル:行>）
+
+### Minor（概要のみ）
+- QA: N件（詳細はエージェント返答参照）
+- CR: N件
+
+### 総合判定
+- <PASS / 要修正 / ブロッカーあり> の判断を明示
+- マージ前に必ず対処すべきもののチェックリスト
+```
+
+Critical / Major が残っている場合は「マージ前に対処が必要」と明確に伝え、Minor のみであれば「マージ可能（後続対応可）」の判断を明示する。判断はユーザーの最終決定に委ねるが、推奨は伝える。
+
+## 注意事項
+
+- **独自の判定ロジックは書かない**: 本スキルは `qa-engineer` / `code-reviewer` エージェントへのラッパーであり、評価は各エージェントに委ねる
+- **並列起動を徹底**: 同一メッセージで2つ起動しないと時間を無駄にする
+- **devcontainer コマンドは先頭から**: `devcontainer exec ...` で始めること。変数代入を先頭に置くとパーミッション承認を都度求められる
+- **複合コマンド禁止**: `&&` や `;` を使った複合 Bash コマンドは避ける（プロジェクトの pre-bash-check.sh でブロックされる）
+- 既存PRがない状態で呼ばれたら `create-pr` スキルを案内して停止する

package/assets/.claude/skills/searching-existing-solutions/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: searching-existing-solutions
+description: |-
+  実装前に既存ソリューションを調査する「車輪の再発明防止」ワークフロー。npm パッケージ、Supabase 組み込み機能、プロジェクト内の既存コードを調査してから実装を開始する。
+when_to_use: |-
+  「実装」「新機能」「ライブラリ」「パッケージ」「自前実装」「ユーティリティ」「ヘルパー」など、コードを書き始める前のとき。
+allowed-tools: Read, Grep, Glob, Bash
+---
+
+# 既存ソリューション調査（車輪の再発明防止）
+
+コードを書く前に既存のソリューションを調査し、車輪の再発明を防止するワークフロー。
+
+## 原則
+
+**実装を始める前に、以下の順序で既存ソリューションを調査すること:**
+
+1. プロジェクト内に同等の実装が既にないか
+2. 使用中の依存パッケージに該当機能がないか
+3. 信頼性の高いnpmパッケージで解決できないか
+4. Supabaseの組み込み機能で解決できないか
+
+## 5段階調査ワークフロー
+
+### Stage 1: プロジェクト内検索
+
+既存コードベースに同等機能がないか確認する。
+
+```
+検索対象（.stdd.config.yml の apps[] を読み、各 apps[].path について繰り返す）:
+- <apps[].path>/lib/ — ユーティリティ・ヘルパー関数
+- packages/shared/ — 共有コード（モノレポの共有パッケージがある場合）
+- <apps[].path>/domain/service/ — ビジネスロジック
+```
+
+**チェックポイント**:
+- [ ] 同名・類似名の関数/コンポーネントが存在しないか
+- [ ] 類似の処理を行っているファイルがないか
+- [ ] `packages/shared/` に共通化済みのコードがないか
+
+### Stage 2: 依存パッケージの機能確認
+
+現在の`package.json`に含まれるパッケージの機能を確認する。
+
+```
+よく見落とされるパッケージ機能:
+- date-fns: 日付フォーマット・計算（自前のDate操作は禁止）
+- zod: バリデーション（自前のバリデーション関数は禁止）
+- next/: Next.js組み込み機能（Image, Link, Font, Metadata等）
+- @supabase/supabase-js: Supabaseクライアントの組み込みメソッド
+- react-hook-form: フォーム状態管理（自前のフォーム管理は禁止）
+```
+
+### Stage 3: Supabase組み込み機能の確認
+
+Supabaseが提供する機能で解決できないか確認する。
+
+```
+見落としやすいSupabase機能:
+- RLS (Row Level Security): アクセス制御はRLSで実装
+- Database Functions: 複雑なクエリはDB関数で
+- Storage: ファイル管理はSupabase Storageで
+- Auth: 認証フローはSupabase Authで
+- Realtime: リアルタイム更新はSupabase Realtimeで
+- Edge Functions: サーバーサイド処理はEdge Functionsで
+```
+
+### Stage 4: npmパッケージの調査
+
+自前実装の前に、広く使われている信頼性の高いパッケージがないか確認する。
+
+**採用基準**:
+- 週間ダウンロード数が10万以上
+- メンテナンスが活発（直近6ヶ月以内のリリース）
+- TypeScript型定義が含まれている
+- バンドルサイズが妥当
+
+**注意**: npm workspaces依存管理ルール（CLAUDE.md参照）に従い、適切なpackage.jsonに追加すること。
+
+### Stage 5: 自前実装の判断
+
+上記すべてで適切なソリューションが見つからない場合のみ、自前実装を行う。
+
+**自前実装が許容されるケース**:
+- プロジェクト固有のビジネスロジック
+- 既存パッケージでは要件を満たせない
+- セキュリティ上の理由で外部依存を避ける必要がある
+
+## アンチパターン
+
+### やってはいけないこと
+
+1. **日付操作の自前実装**: `date-fns`を使う
+2. **バリデーション関数の自前実装**: `zod`スキーマを使う
+3. **HTTPクライアントの自前ラッパー**: `fetch`または既存のクライアントを使う
+4. **認証ロジックの自前実装**: Supabase Auth / NextAuthを使う
+5. **ファイルアップロードの自前実装**: Supabase Storageを使う
+6. **既存utility関数の重複作成**: `lib/`を検索して既存実装を再利用する
+
+## 出力テンプレート
+
+調査結果は以下のフォーマットで簡潔に記録する:
+
+```
+## Search-First 調査結果
+- プロジェクト内: [既存実装あり/なし] — [詳細]
+- 依存パッケージ: [利用可能/不可] — [パッケージ名・機能]
+- Supabase機能: [利用可能/不可] — [機能名]
+- 判断: [既存利用 / パッケージ追加 / 自前実装]
+```

package/assets/.claude/skills/setup-stdd/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: setup-stdd
+description: |-
+  STDD の導入入口（ルーター）。「STDD を導入して / 始めて / セットアップして」と言われたとき最初に起動し、対象プロジェクトが新規（コードがまだ無い）か既存（稼働コードがある）かを自動判定して、適切な駆動スキル（新規=starting-new-with-stdd / 既存=introducing-stdd）へ委譲する薄いディスパッチャ。再開中の導入PLAN/立ち上げPLANがあればそれを優先して続きから再開する。判定はユーザーに一言確認してから委譲する。
+when_to_use: |-
+  「STDDを導入して」「STDDを始めて」「STDDをセットアップ」「STDDを使い始める」「setup stdd」「start stdd」「stddを入れて」など、どちらのフローか未確定のままSTDD導入を頼まれた最初のとき。新規/既存が明確で続きから進める場合は starting-new-with-stdd / introducing-stdd を直接使う。
+allowed-tools: Read, Glob, Grep, Bash, Skill
+---
+
+# STDD 導入ルーター
+
+「STDD を導入して」と言われたときの**最初の受け口**。対象プロジェクトを調べ、
+**新規（コードなし）** か **既存（稼働コードあり）** かを判定し、適切な駆動スキルへ委譲する。
+自分自身は spec を書いたり実装したりせず、判定と委譲だけを行う薄い役割。
+
+---
+
+## 手順
+
+### 1. 再開中の PLAN を最優先で確認
+
+すでに導入/立ち上げが始まっている場合は、続きから再開する。次が存在するか確認する:
+
+```
+□ docs/common/plans/stdd-introduction.md がある → 既存フロー継続 → introducing-stdd へ
+□ docs/common/plans/stdd-bootstrap.md がある    → 新規フロー継続 → starting-new-with-stdd へ
+```
+
+どちらかがあれば、ユーザーに「導入を途中から再開します」と伝えて該当スキルへ委譲し、以降の判定はスキップする。
+
+### 2. 新規 / 既存 を判定
+
+PLAN が無ければ、リポジトリにアプリケーションのソースコードが実在するかで判定する。
+
+```
+□ アプリのソース（src / app / pages / packages の実装ファイル等）が実在するか
+□ package.json の dependencies に実プロダクトの依存があるか（雛形のみではないか）
+□ git 履歴に機能実装のコミットがあるか
+```
+
+判定基準:
+- **コードが実質ゼロ**（空ディレクトリ、または README / `.stdd.config.yml` / `.claude/` / `docs/` の雛形だけ）→ **新規**
+- **アプリのソースが存在する**（既に動く機能がある）→ **既存**
+
+判定材料の集め方の例:
+
+```bash
+# .git / node_modules / .claude / docs / 設定ファイルを除いた実ソースの有無をざっと見る
+git ls-files 2>/dev/null | grep -vE '^(\.claude/|docs/|\.stdd\.config\.yml|README|LICENSE|\.gitignore)' | head -50
+```
+
+### 3. ユーザーに確認してから委譲
+
+判定結果を一言で伝え、合っているか確認してから委譲する（誤判定を防ぐ）。
+
+- 例（既存）: 「アプリのソースを検出しました。**既存プロジェクトへの導入**として進めます。よいですか？」
+- 例（新規）: 「コードはまだ無いようです。**新規プロジェクトの立ち上げ**として進めます。よいですか？」
+
+確認が取れたら、対応する駆動スキルを起動する:
+
+| 判定 | 委譲先スキル |
+| --- | --- |
+| 新規（コードなし） | `starting-new-with-stdd` |
+| 既存（コードあり） | `introducing-stdd` |
+
+委譲後は、そのスキルが以降のフロー（spec 生成・フォーマット策定・機能ループ等）を駆動する。
+
+---
+
+## 前提
+
+- このスキルは `stdd init`（`.claude/` と `.stdd.config.yml` の配置）が済んだプロジェクトで使う想定。
+  `.stdd.config.yml` が無い場合は、まず `npx @careerchain/stdd init` を案内する。
+- 判定がどうしても曖昧な場合は決め打ちせず、ユーザーにどちらで進めるか尋ねる。
+
+---
+
+## When NOT to Use This Skill
+
+- **新規/既存が明確で続きから進めたい**: `starting-new-with-stdd` / `introducing-stdd` を直接呼ぶ。
+- **単一機能のリバースだけしたい**: `reverse-engineering-feature-spec` を直接使う。
+- **個別機能の新規実装**: `auto-implement`（順行 STDD）を使う。