project-onboard

Project Onboard

構造化されたタスク別コンテキストファイルを生成して、あらゆるプロジェクトに AI エージェントをオンボーディングするスキルです。フラットなエージェントファイルを生成する /init とは異なり、このスキルでは段階的に情報を開示する仕組みを作成します。これにより、エージェントは現在のタスクに必要な情報だけを読み取るため、トークンを節約し、プロジェクトを重複して調査する手間を省けます。

Invocation

/project-onboard                     First run: full onboard. Re-run: refresh + audit.
/project-onboard --quick             Phase 1+2 only (skip audit & interview)
/project-onboard Thai                Full onboard, confirm output language first

個別の更新コマンドや監査コマンドを作成または説明しないでください。/project-onboard が唯一のエントリーポイントです。再度実行すると、既存のコンテキストを更新し、監査を自動的に再実行します。 単に「onboard」と言われた場合は、自然言語による project-onboard の実行リクエストとして扱ってください。/onboard スラッシュコマンドを作成、説明、参照しないでください。

まずここから：実行モードを選択する

いずれかのフェーズを実行する前に、初回オンボーディングか再実行かを判断します。 ユーザーが /project-onboard とだけ入力した場合も必ず判断してください。同じコマンドで初回オンボーディングと再実行の両方を処理します。

次の既存の生成済みコンテキストを確認します。

• .context/onboard-meta.json
• AGENTS.md または CLAUDE.md
• .context/features/audit-meta.json

次の判断表を使用します。

状況	実行モード
.context/onboard-meta.json がなく、生成済みの指示ファイルもない	初回オンボーディング
.context/onboard-meta.json はないが、project-onboard のマーカーがない AGENTS.md または CLAUDE.md がある	既存の指示ファイルのポリシーに従った初回オンボーディング
.context/onboard-meta.json があり、ユーザーが /project-onboard、「onboard again」、「rerun」、「update」、「refresh」のいずれかを指定している	project-onboard を再実行：更新＋監査
既存のコンテキストはあるが、メタデータがない、または無効	復旧のための再実行：全面更新＋監査。既存ファイルは保持
ユーザーが新しいリポジトリで /project-onboard --quick を指定	初回クイック実行：Phase 1 と 2 のみ実行
ユーザーがオンボーディング済みのリポジトリで /project-onboard --quick を指定	クイック再実行：生成済みコンテキストのみ更新。監査とインタビューはスキップ

生成済みの project-onboard マーカーは、``、.context/onboard-meta.json、または .context/ を参照するタスクルーティングです。 指示ファイルにこれらのマーカーがない場合は、project-onboard がすでに実行された証拠ではなく、保持して内容を統合するユーザー作成の入力として扱ってください。

初回オンボーディング

Phase 1 と Phase 2 を実行します。その後、ユーザーが --quick を指定していない場合は、Phase 3 と Phase 4 も実行するか確認します。

project-onboard の再実行

生成済みのコンテキストを更新してから、監査を再実行します。オンボーディングの再実行は、生成済みのコンテキストを最新にするリクエストでもあるため、監査を実行するかどうかを尋ねないでください。これは同じ /project-onboard コマンドの内部動作であり、独立した更新コマンドや監査コマンドではありません。

再実行の目標：

1. 古くなった、または変更されたコンテキストファイルを更新します。
2. 変更された領域について8カテゴリの監査を再実行します。変更を確実に検出できない場合は、全体を監査します。
3. .context/features/_feature-map.md と監査メタデータを更新します。
4. ルート、API、データ、認証、ジョブ、インテグレーション、テスト、警告、ワークフローに変更があった場合は、正規の指示ファイルにあるタスクルーティングを更新します。
5. インタビューから生成されたファイルと、ユーザーが記述した指示内容を保持します。ユーザーが明示的にユーザー記述の内容の修正を求めた場合を除き、生成された project-onboard セクションのみを更新します。
6. .context/onboard-meta.json を更新し、last_update、last_audit、git_commit、完了したフェーズ、検出されたカテゴリ、キャッシュ済みドキュメントの状態を記録します。

リポジトリに Git の履歴がない場合、保存済みのコミットが見つからない場合、または差分の取得に失敗した場合は、Phase 1、Phase 2 のコンテキストファイル、Phase 3 を対象に、保守的な全面更新へ切り替えます。インタビューの回答と既存のユーザー作成セクションは保持します。

言語サポート

ユーザーがコマンドに言語名を付けて実行した場合（例：/project-onboard Thai、 /project-onboard Japanese）、続行する前に言語を確認します。

"You requested output in Thai. This will generate all context files
and agent instruction files in Thai. Confirm? (yes/no)"

確認が取れたら、すべての出力ファイルをその言語で作成します。AGENTS.md、CLAUDE.md のシム、コンテキストファイル、機能マップなど、すべてが対象です。SKILL.md の説明自体は 英語のままですが、生成される出力にはユーザーが選択した言語を使用します。

指定がない場合のデフォルト言語は英語です。

動作の仕組み

このスキルは4つのフェーズで実行されます。各フェーズは前のフェーズを基に進みます。 各ステップでエージェントが得る情報が増えるため、後半のフェーズほど適切に判断できます。

Phase 1: DISCOVER .......... auto-detect stack + research docs
Phase 2: GENERATE .......... create AGENTS.md + CLAUDE.md shim + context files
Phase 3: FEATURE AUDIT ..... map Page → API → DB → Feature (optional)
Phase 4: INTERVIEW ......... ask the developer (knows everything now)

初回実行時、フェーズ3と4は任意です。再実行時は、ユーザーが --quick を指定しない限り、 フェーズ3が自動的に実行されます。初回実行でフェーズ2が終わったら、ユーザーに次の質問をします。

• 「既存の機能を監査しますか？（ページ、エンドポイント、DBをマッピングします）」
• 「ビジネスの背景についてお聞きしてもよいですか？」

ユーザーが /project-onboard --quick を実行した場合、フェーズ3と4をスキップします。

再実行時は、スキルは余計なやり取りをせず、直接作業します。まず生成済みのコンテキストと 監査出力を更新してから、変更内容を要約します。質問するのは、標準の指示ファイルの選択が 曖昧な場合、またはユーザーが作成した内容を保持するために判断が必要な場合に限ります。

---

フェーズ1：DISCOVER

2つのサブフェーズがあります。このフェーズではユーザーに何も質問しないでください。

フェーズ1a：DETECT

プロジェクトファイルを読み込み、技術スタックとツールを特定します。 再帰的な find や ls は使用しないでください。既知の特定のファイルのみを読み込みます。

次のファイルを確認します（存在しない場合はスキップします）。

パッケージマネージャーとスタック：

• package.json → Node.js エコシステム、フレームワーク、依存関係、スクリプト
• pubspec.yaml → Flutter/Dart
• go.mod → Go
• requirements.txt / pyproject.toml / Pipfile → Python
• Cargo.toml → Rust
• composer.json → PHP
• Gemfile → Ruby

モバイル：

• package.json の依存関係に react-native → React Native
• app.json / app.config.js → Expo
• pubspec.yaml の依存関係に flutter → Flutter

状態管理：

• 依存関係にある @reduxjs/toolkit / zustand / jotai / @tanstack/react-query
• pubspec.yaml にある riverpod / bloc / provider

バックグラウンドジョブ：

• 依存関係にある bullmq / bull / celery / sidekiq
• キュープロセッサーのファイル

i18n：

• ロケールファイル（en.json、th.json など）
• 依存関係にある i18n ライブラリ（next-intl、react-i18next、flutter_localizations）

設定：

• tsconfig.json → TypeScript の設定
• .eslintrc* / biome.json / .prettierrc → lint／フォーマット
• docker-compose.yml / Dockerfile → コンテナ化
• vercel.json / netlify.toml / fly.toml → デプロイ先
• .env.example → 環境変数（.env は絶対に読み込まない）

データベース：

• prisma/schema.prisma → Prisma スキーマ
• drizzle.config.ts → Drizzle ORM
• knexfile.* / ormconfig.* → その他の ORM
• migrations/ または db/migrate/ → マイグレーションツールを確認

CI/CD とワークフロー：

• .github/workflows/ → GitHub Actions
• .gitlab-ci.yml → GitLab CI
• .husky/ → git フック

テスト：

• jest.config* / vitest.config* / playwright.config* / cypress.config*
• テストファイル数を数える：存在する *.test.* または *.spec.* ファイルの数

既存の AI コンテキスト：

• AGENTS.md → 優先する標準のエージェント指示。保持し、後で統合します
• CLAUDE.md → 既存の Claude Code 指示。移行前にユーザーに確認します
• .cursor/rules/ → インポート規則
• .github/copilot-instructions.md → 既存の Copilot ルール

ドキュメント：

• README.md → プロジェクトの説明、セットアップ
• CONTRIBUTING.md → チームの規約
• CHANGELOG.md → 最近の変更、現在のバージョン
• docs/ → アーキテクチャのドキュメント

フェーズ 1b：調査

フェーズ 1a の情報を使って、対象を絞って調査します。

1. プロジェクトのドキュメント — リポジトリ内にあるものを読む

README.md を最後まで読みます。プロジェクトの目的、セットアップ手順、 アーキテクチャに関する注意事項を抽出します。CONTRIBUTING.md または docs/ がある場合は、 それらも読みます。

2. スタックのドキュメント — Context7 で最新のドキュメントを取得（条件付き）

.context/onboard-meta.json が存在する場合は読みます。主要な依存関係ごとに、以下を確認します。

• 前回のオンボーディングからバージョンが変わっている場合 → 最新のドキュメントを取得
• ドキュメントが 7 日より古い場合 → 最新のドキュメントを取得
• ドキュメントが最新で、バージョンも変わっていない場合 → スキップしてキャッシュを使用

取得する場合は、検出した特定のバージョンについて Context7 に問い合わせます。 以下に重点を置きます：規約、破壊的変更、移行ガイド、ベストプラクティス。

結果を .context/stack-docs/{lib}-{version}.md に保存します。

3. スキル — 関連するスキルを検索する

検出したスタックに基づいて、利用可能なスキルを検索します。

• CLI が利用可能な場合は npx skills search {framework}
• または、既知の情報源から推奨事項を記録します：
  • vercel-labs/agent-skills（React、Next.js、デプロイ）
  • VoltAgent/awesome-agent-skills（コミュニティのコレクション）

推奨事項はフェーズ 2 の出力およびフェーズ 4 の提案用に保存します。

4. エコシステム — 実際のツールを確認する

package.json のスクリプトを読み、実際のビルド／テスト／開発コマンドを把握します。 CI 設定を読み、実際のパイプラインの手順を把握します。 tsconfig/eslint を読み、実際のコード規約を把握します。 推測せず、設定ファイルで確認してください。

---

フェーズ 2：生成

出力ファイルを生成します。完全なテンプレートとファイル構成については、 references/output-format.md を読みます。

パスのルール — ファイルを書き込む前によく読んでください：

• コンテキストファイルは project-root/.context/（トップレベルのドットフォルダー）に配置します
• 正規のエージェント指示ファイルは project-root/AGENTS.md（複数形）に配置します
• Claude Code 互換の指示ファイルは project-root/CLAUDE.md に配置します
• 唯一の Claude コマンドは project-root/.claude/commands/project-onboard.md に配置します
• これらはプロジェクトルートにある別々のディレクトリ 2 つです。.context/ を .claude/ の中に入れてはいけません。
• 誤り：.claude/context/、.claude/.context/、.claude/architecture.md
• 正しい：AGENTS.md、CLAUDE.md、.context/architecture.md、.claude/commands/project-onboard.md

最初のファイルを作成する前に、書き込もうとしている場所が .context/ か .claude/context/ かを再確認してください。 パスに .claude/context または .claude/.context が含まれている場合は、停止してください。これは誤りです。.context/ に修正してください。

出力構成

project-root/
├── AGENTS.md                          # ≤ 150 lines, canonical task-routed instructions
├── CLAUDE.md                          # Compatibility shim pointing to AGENTS.md, unless user chooses otherwise
├── .context/                          # ⚠️ THIS IS project-root/.context/ — NOT .claude/context/
│   ├── architecture.md                # Directory map + patterns
│   ├── conventions.md                 # Coding standards (from config)
│   ├── workflow.md                    # CI/CD, deploy, branch strategy
│   ├── stack-docs/                    # Cached library docs
│   │   └── {lib}-{version}.md
│   ├── warnings.md                    # Things to watch out for
│   └── onboard-meta.json             # Metadata for reruns
└── .claude/
    ├── commands/
    │   └── project-onboard.md                 # /project-onboard command (single entrypoint)
    └── .claudeignore                  # (if not exists) auto-generated

⚠️ 重要なパスに関する警告： .context/ はプロジェクトルートにあります。AGENTS.md および CLAUDE.md と同じ階層です。 .claude/context/ は絶対に作成しないでください。これは誤りです。2 つのディレクトリは別々です：

• .context/ = オンボーディングのコンテキストファイル（アーキテクチャ、規約、機能など）
• .claude/ = Claude のコマンドと設定のみ

エージェント指示ファイル — 重要なルール

推奨される正規の指示ファイルとして、AGENTS.md（複数形）を使用します。単数形の AGENT.md は、 ここで使用する規約ではありません。

正規の指示ファイルは、人間向けのドキュメントではありません。AI エージェント用の 判断ツリーです。

タスクベースのルーティングパターンを使って記述します。

BEFORE [action] → read [file]
WHEN [situation] → read [file]

ファイルを列挙するだけにしてはいけません。各ファイルをいつ読むべきか、必ずエージェントに伝えてください。

完全な AGENTS.md テンプレートと CLAUDE.md のシムテンプレートについては、 references/output-format.md を読みます。

既存の指示ファイルに関するポリシー

AGENTS.md または CLAUDE.md を作成する前に、既存の指示ファイルがあるかどうかを確認してください。

• AGENTS.md と CLAUDE.md のどちらも存在しない場合：
  • タスクごとのルーティングを含む完全な内容を AGENTS.md に作成します。
  • Claude Code に最初に AGENTS.md を読むよう指示する簡潔なシムとして CLAUDE.md を作成します。
• AGENTS.md が存在し、CLAUDE.md が存在しない場合：
  • AGENTS.md を保持し、内容を統合します。
  • AGENTS.md を参照する簡潔なシムとして CLAUDE.md を作成します。
• CLAUDE.md が存在し、AGENTS.md が存在しない場合：
  • 所有権を変更する前に、ユーザーに確認します： 「既存の CLAUDE.md が見つかりました。その内容を AGENTS.md に移行し、CLAUDE.md を参照用に置き換えますか。それとも、CLAUDE.md を正式なファイルとして維持し、AGENTS.md をそのファイルへの参照として作成しますか？」
  • ユーザーが移行を選択した場合：CLAUDE.md を読み、ユーザーが作成したすべての内容を AGENTS.md に保持して、生成するタスクルーティングのセクションを追加した後、CLAUDE.md を AGENTS.md を参照するシムに置き換えます。
  • ユーザーが Claude を正式なものとして維持することを選択した場合：CLAUDE.md を保持して内容を統合し、その後、CLAUDE.md を参照するシムとして AGENTS.md を作成します。
• AGENTS.md と CLAUDE.md の両方が存在する場合：
  • 両方を読みます。
  • CLAUDE.md に、より新しい、またはより完全なユーザー作成の指示が明確に含まれていない限り、AGENTS.md を正式なファイルとして優先します。
  • どちらを正式なファイルとするか判断が難しい場合は、統合する前に確認します。
  • 正式でないファイルは、正式なファイルを参照するシムとして維持します。

ユーザー作成の指示内容を破棄してはいけません。シムによって既存ファイルを置き換えるのは、元の内容を正式なファイルに移行した後、またはユーザーがその方針を明示的に選択した後に限ります。

コンテキストファイル — AI 向けの記述

すべてのコンテキストファイルは、次の内容から始めてください：

1. このファイルをいつ読むべきか（1 行）
2. エージェントが情報をどのように使うべきか
3. 実際の内容 — 簡潔で、構造化され、実行可能

散文は書かないでください。エージェントが実行できる構造化データを記述してください。

onboard-meta.json

{
  "version": "2.0",
  "last_onboard": "ISO-8601",
  "last_update": "ISO-8601",
  "last_audit": "ISO-8601",
  "git_commit": "hash",
  "previous_git_commit": "hash",
  "language": "en",
  "agent_instructions": {
    "canonical": "AGENTS.md",
    "shim": "CLAUDE.md",
    "shim_direction": "CLAUDE.md -> AGENTS.md"
  },
  "stack": ["nextjs", "prisma", "postgresql"],
  "platforms": {
    "web": true,
    "mobile": false,
    "backend": true
  },
  "categories_detected": [
    "pages-routing",
    "api-middleware",
    "data-layer",
    "auth-security",
    "background-events",
    "integrations-infra"
  ],
  "stack_docs": {
    "next": { "version": "15.1.0", "docs_pulled_at": "ISO-8601" }
  },
  "phases_completed": ["discover", "generate"],
  "interview_done": false,
  "audit_done": false,
  "last_run_mode": "first-onboard | rerun-project-onboard | first-run-quick | rerun-quick | recovery-rerun"
}

既存の指示ファイルとの統合

正式な指示ファイルがすでに存在する場合：

1. すべて読みます
2. 既存の内容をすべて保持します
3. 不足しているセクション（タスクルーティング、コンテキスト参照、警告）を追加します
4. ユーザー作成の内容を上書きしないでください
5. 生成したセクションには `` のマークを付けます

スキルの推奨

ファイルを生成した後、利用可能なスキルをユーザーに提示します：

"Detected: Next.js + React + Prisma. Recommended skills:"
  1. vercel-react-best-practices — 40+ React performance rules
  2. web-design-guidelines — accessibility + UX audit
  
"Install with: npx skills add vercel-labs/agent-skills@vercel-react-best-practices"
"Want me to install any of these?"

---

Phase 3: UNIVERSAL AUDIT（初回は任意、再実行時は自動）

初回のオンボーディングでは、ユーザーがすでに監査を依頼している場合を除き、実行前に確認します：「既存の機能を監査しますか？ページ、状態、UI、API、データ、認証、ジョブ、インテグレーションをスキャンします。」project-onboard の再実行時は確認せず、生成済みコンテキストを更新した後、自動的に監査を実行します。

8 つのカテゴリを使ってコードベースをスキャンします。各カテゴリは自動検出され、見つからない場合は自動的にスキップされます。スキャン方法の詳細は references/universal-audit.md を読み、続いて出力テンプレートの正確な形式を確認するため templates/feature-audit-format.md を読んでください。

8 つのカテゴリ

#	カテゴリ	出力ファイル	対象範囲
1	ページとルーティング	pages-routing.md	ページ、画面、ナビゲーション、ディープリンク、ルートガード
2	状態とデータ取得	state-data.md	ストア、スライス、プロバイダー、クライアントキャッシュ、データ取得
3	デザインシステムと UI	design-system.md	コンポーネント、テーマ設定、フォーム、i18n、アクセシビリティ
4	API とミドルウェア	api-middleware.md	エンドポイント、ミドルウェアパイプライン、バリデーション、エラー処理
5	データ層	data-layer.md	DB スキーマ、マイグレーション、キャッシュ、トランザクション、シード
6	認証とセキュリティ	auth-security.md	認証、認可、レート制限、CORS、シークレット
7	バックグラウンド処理とイベント	background-events.md	ジョブ、イベント駆動型アーキテクチャ、スケジュール済みタスク、サービス間通信
8	インテグレーションとインフラ	integrations-infra.md	外部 API、ファイルストレージ、ログ記録、設定、ヘルスチェック

検出したすべてのカテゴリを _feature-map.md で相互参照してください。 また、対応付けられていないエンドポイント、ページ、状態、ジョブ、DB テーブルも特定してください。

監査の更新モード

オンボーディング済みの既存リポジトリで /project-onboard を再実行する場合：

1. .context/features/audit-meta.json が存在する場合は読み込みます。
2. .context/onboard-meta.json が存在する場合は読み込みます。
3. 変更されたファイルを特定します。
   • この実行ですでにコンテキストの更新ステップによって変更ファイルが生成されている場合は、 それを再利用します。
   • 変更ファイルが取得できない場合は、 audit-meta.json に記録されたコミットとの差分を確認します。存在しない場合は、onboard-meta.json の git_commit を使用し、それも存在しない場合は previous_git_commit を使用します。
   • 信頼できるコミットがない場合は、監査全体を実行します。
4. 変更されたファイルを使って、影響を受ける監査カテゴリを選択します。
5. 相互参照の正確性を保てるよう、影響を受けるカテゴリを十分に再スキャンします。 ページの変更は API 呼び出し元に影響する場合があり、API の変更はページや機能マップに影響する場合があります。スキーマ、認証、ジョブ、インテグレーションの変更は複数の機能セクションに影響する場合があります。
6. 機能マップはカテゴリ別の現在の出力を横断するインデックスであるため、.context/features/_feature-map.md は必ず再構築します。
7. 影響を受けるカテゴリを確実に判断できない場合は、古い機能マップを残さず、8 カテゴリすべての監査を実行します。
8. スキャンしたカテゴリ、スキップしたカテゴリ、カバレッジ数、孤立項目数、last_audit、使用した git コミットで audit-meta.json を更新します。

出力ファイル

.context/ は プロジェクトのルートにあり、.claude/ の中ではないことを忘れないでください。

.context/features/
  ├── _feature-map.md           # Cross-reference all categories per feature
  ├── pages-routing.md          # 1: Pages & Routing (web + mobile)
  ├── state-data.md             # 2: State & Data Fetching
  ├── design-system.md          # 3: Design System & UI
  ├── api-middleware.md          # 4: API & Middleware
  ├── data-layer.md             # 5: Data Layer
  ├── auth-security.md          # 6: Auth & Security
  ├── background-events.md      # 7: Background & Events
  ├── integrations-infra.md     # 8: Integrations & Infra
  └── audit-meta.json           # Coverage stats per category

生成後、正規の指示ファイルをタスクの振り分けルールで更新します。

BEFORE modifying or creating any page, screen, or route:
  → read .context/features/pages-routing.md
  → read .context/features/_feature-map.md

BEFORE modifying app state (stores/slices/providers):
  → read .context/features/state-data.md
  → read .context/features/pages-routing.md (check consumers)

BEFORE modifying UI components, theming, forms, or i18n:
  → read .context/features/design-system.md

BEFORE modifying or creating any API endpoint:
  → read .context/features/api-middleware.md
  → read .context/features/pages-routing.md (check callers)

BEFORE modifying database schema, caching, or migrations:
  → read .context/features/data-layer.md
  → read .context/features/_feature-map.md (check impact)

BEFORE modifying auth, permissions, or security config:
  → read .context/features/auth-security.md

BEFORE modifying background jobs, events, or service communication:
  → read .context/features/background-events.md

BEFORE modifying external integrations, logging, or config:
  → read .context/features/integrations-infra.md

---

フェーズ 4：インタビュー（任意）

エージェントはプロジェクト全体をスキャンし、理解しました。 質問はフェーズ 1～3 で発見したすべての情報に基づいています。

実行前に質問します：「プロジェクトについていくつか質問してもよいですか？コードからは分からないことを理解するのに役立ちます。」

フェーズ 3 を完了している場合 — 短いインタビュー（3 つの質問）

エージェントはすでにコードベースを深く理解しています。コードからは分からないことだけを質問します。

1. "[Summary from README + code]. Is this accurate?
    Any business context or domain terms I should know?"

2. "Any conventions, processes, or areas I should NOT touch
    without asking first?"

3. "Anything else you want me to know?"

フェーズ 3 をスキップした場合 — 詳細なインタビュー（4 グループ）

グループ 1：ビジネスとドメイン

1. "What does this project do? Who are the main users?"
2. "Any domain-specific terms I should understand?"
3. "What phase is this project in?
    (MVP / active dev / maintenance / legacy refactor)"

グループ 2：チームとワークフロー

4. "How many people work on this? Code review process?"
5. "Branch strategy? (trunk-based / gitflow / feature branches)"
6. "Deploy process? (auto/manual, staging environment?)"
7. "Any conventions you want me to always follow?"

グループ 3：コード品質とテスト

8. "Want to restructure the code?
    (e.g., extract business logic to service layer)"
    — If Phase 1 found logic in route handlers, mention it specifically.

9. "Do you want TDD? (write tests before implementation)"

10. "Testing strategy?"
    — Unit only
    — Unit + Integration
    — Unit + Integration + E2E
    — No tests yet, want to start

11. "Test framework preference?"
    — Mention what was detected: "Found [vitest/jest], correct?"
    — For E2E: Playwright / Cypress / other?

12. "Coverage target? (none / 60% / 80% / 90%+)"
    — If tests exist, mention current estimated coverage.

グループ 4：AI の動作

13. "Anything that AI agents frequently break in this project?"

14. "Files or folders I should never modify without asking?"

15. "How autonomous should I be?"
    — Conservative: always ask before acting
    — Balanced: act but explain
    — Autonomous: just do it

16. "Anything else I should know?"

適応型の質問

質問は、発見した内容に合わせて調整しなければなりません。フェーズ 1～3 ですでに答えが分かっている場合は、一般的な質問をしないでください。

例 — テストが検出された場合：

BAD:  "Do you want to write tests?"
GOOD: "Found Vitest with 23 test files, ~45% coverage.
       Want me to help increase coverage? Add E2E with Playwright?"

例 — ルートハンドラーにロジックがある場合：

BAD:  "Want to restructure the code?"
GOOD: "Found business logic directly in route handlers
       (e.g., /api/pipelines has 120 lines of logic).
       Want me to extract it to a service layer?"

インタビューの出力

回答をコンテキストファイルに保存します。

• ビジネスコンテキスト → .context/business.md
• テスト戦略 → .context/testing-strategy.md
• 保護すべきファイルや領域を warnings.md に反映
• チームのプロセス情報を workflow.md に反映
• 明示された希望を conventions.md に反映
• 新しいセクションを追加して、正規の指示ファイルのタスク振り分けを更新

onboard-meta.json を更新し、interview_done: true に設定します。

---

プロジェクトのオンボーディングを再実行する（/project-onboard）

オンボーディングのコンテキストがすでにあるリポジトリでユーザーが /project-onboard を実行した場合は、生成済みのコンテキストを更新し、同じコマンドを通じて監査を再実行します。別の更新コマンドや監査コマンドを実行するよう、ユーザーに案内しないでください。

1. .context/onboard-meta.json を読み込みます。
2. agent_instructions.canonical に記録された正規の指示ファイルを検証します。移動または消失している場合は、既存の指示ファイルのポリシーに基づいて、最適な正規ファイルを検出します。
3. git diff {last_commit}..HEAD --name-only を実行して、変更されたファイルを特定します。
   • メタデータの git_commit を {last_commit} として使用します。
   • git_commit がない、無効、または利用できない場合は、previous_git_commit を使用します。
   • git diff を実行できない場合は、全体を更新します。
   • diff が空の場合も、更新が不要と判断する前に、ドキュメントキャッシュの鮮度と監査メタデータのタイムスタンプを確認します。
4. 変更されたファイルごとに、更新が必要なコンテキストファイルを判断します。
   • package.json が変更された → スタックを再検出し、ドキュメントの更新が必要か確認します。
   • prisma/schema.prisma が変更された → .context/features/data-layer.md と .context/features/_feature-map.md を更新します。
   • ルートファイルが変更された → .context/features/api-middleware.md と .context/features/_feature-map.md を更新します。
   • ページファイルが変更された → .context/features/pages-routing.md と .context/features/_feature-map.md を更新します。
   • 設定ファイルが変更された → conventions.md または workflow.md を更新します。
5. 影響を受けるコンテキストファイルと、タスクの振り分けに変更があった場合は agent_instructions.canonical に記録された正規の指示ファイルのみを更新します。
6. ユーザーが正規の所有権の変更を求めない限り、agent_instructions.shim_direction に記録されたシムの方向性を維持します。
7. ユーザーが /project-onboard --quick を指定していない限り、コンテキストファイルの更新後にフェーズ 3 の監査更新モードを実行します。
8. ユーザーがインタビューのやり直しを求めない限り、インタビューから得られたファイルを保持します。
   • .context/business.md
   • .context/testing-strategy.md
   • .context/warnings.md、.context/workflow.md、.context/conventions.md に統合されたインタビューのセクション
9. onboard-meta.json を、新しいタイムスタンプ、previous_git_commit、現在の git_commit、last_run_mode、および監査を実行した場合は監査フィールドで更新します。git_commit を置き換える前に、古い git_commit を previous_git_commit にコピーします。初回のオンボーディングでは、previous_git_commit を null に設定するか、省略します。
10. 次の要約を表示します。「最終オンボーディング以降に変更された Z 個のファイルに基づき、X 個のコンテキストファイルと Y 個の監査ファイルを更新しました」

全体更新のリクエストまたは復旧のための再実行の場合：

• フェーズ 1 からすべてを再スキャンします。
• 生成対象のコンテキストファイルをすべて再生成します。
• インタビューの回答は保持し、ユーザーからやり直しを求められない限り、再度質問しません。
• ユーザーが /project-onboard --quick を指定していない限り、フェーズ 3 を実行します。

再実行時の安全ルール

• AGENTS.md、CLAUDE.md、またはコンテキストファイルから、ユーザーが記述したセクションを削除しないでください。生成されたセクションはその場に統合します。
• コードが変更されたという理由だけで、インタビューの回答を書き換えないでください。
• 再実行時に機能マップを省略しないでください。いずれかのカテゴリに変更があれば、_feature-map.md を再構築します。
• diff の信頼性が高い場合は対象を絞って更新し、diff がない、曖昧、またはコンテキストが古くなるリスクがある場合は全体を更新します。
• 再実行時に初回実行向けの定型的な質問をユーザーにしないでください。正規の所有権が曖昧な場合、またはビジネスコンテキストに明確な不足がある場合にのみ質問します。

---

スタックドキュメントのキャッシュ

Context7 のドキュメントは .context/stack-docs/ にキャッシュされます。 取得方法：

条件	アクション
これまで取得していない	今すぐ取得
ライブラリのバージョンが変更された	今すぐ取得（互換性を損なう変更が含まれる可能性があります）
バージョンは同じで、ドキュメントが 7 日以内	取得をスキップし、キャッシュを使用
バージョンは同じで、ドキュメントが 7 日より古い	最新版を取得
ユーザーが --force-docs を実行	すべて取得

---

今後の予定：マルチエージェントのサポート

このスキルは、エージェントに依存しない標準のエントリーポイントとして AGENTS.md を生成し、Claude Code との互換性を保つためのシムとして CLAUDE.md を生成します。今後のバージョンでは、追加のラッパーをサポートする可能性があります。

Claude Code  → CLAUDE.md shim → AGENTS.md + .context/
Cursor       → .cursor/rules/
Codex        → AGENTS.md + .context/
Copilot      → .github/copilot-instructions.md

.context/ 内のコンテキストファイルは、エージェントに依存しない Markdown で記述されています。他のエージェントのサポートを追加するには、同じコンテキストに誘導するラッパーファイルを生成します。

---

参照ファイル

出力を生成する前に、以下をお読みください。

• references/output-format.md — AGENTS.md テンプレート、CLAUDE.md シムのテンプレート、コンテキストファイルのテンプレート
• references/universal-audit.md — 8 つすべての監査カテゴリに対応する、完全なスキャン戦略と出力テンプレート
• templates/feature-audit-format.md — 機能監査の出力テンプレート