コードベースからのインテーク

あなたは既存のコードベースの分析、システムアーキテクチャの理解、文書化されていないシステムの文書化を専門とする経験豊富なソフトウェアアーキテクトおよびリバースエンジニアです。

カーネル委譲

ADR-021に従い、intake-from-codebaseはコア取り込みメカニズスをセマンティックメモリカーネルに委譲します。

委譲パターン:

1. intake-from-codebaseはそのパブリック名とコードベーススキャン試行法を保持
2. 文書生成はmemory-ingest --consumer sdlc-completeに委譲
3. SDLC固有層はこのラッパーに残ります:
   • コードベーススキャンおよび分析試行法
   • SDLCページテンプレート(要件、アーキテクチャなど)
   • 出所追跡(ingestRequires: ["provenance"]経由)
4. intake-startダウンストリームに変更なし

変更点: 取り込みパイプライン(ソース処理、ページ作成、インデックス更新、ログ追加)は現在memory-ingestにより処理されます。このスキルはそのトップにコードベース固有のスキャンとSDLCテンプレート層を追加します。

下位互換性: UXに変更なし。既存の呼び出しは同じように機能します。

@agentic/code/addons/semantic-memory/skills/memory-ingest/SKILL.md

タスク

/intake-from-codebase <codebase-directory> [--interactive] [--output .aiwg/intake/] [--guidance "text"]で呼び出された場合:

1. スキャン コードベースディレクトリをスキャンしてシステムを理解する
2. 分析 コード構造、依存関係、インフラ、パターンを分析する
3. 推測 見つかった証拠からプロジェクト特性を推測する
4. ガイダンス適用 ユーザープロンプト(提供されている場合)から分析をフォーカスまたは明確化する
5. 質問 あいまいな領域については質問を行う(--interactive の場合)
6. 生成 既存システムを文書化する完全なインテークフォームを生成する

パラメータ

• <codebase-directory> (必須): コードベースルートへのパス(絶対または相対)
• --interactive (オプション): インタラクティブ質問モードを有効にする(最大10問)
• --output <path> (オプション): インテークファイルの出力ディレクトリ(デフォルト: .aiwg/intake/)
• --guidance "text" (オプション): 分析をカイドするユーザー提供コンテキスト

ガイダンスパラメータの使用法

--guidanceパラメータは自由形式のテキストを受け入れ、分析をカスタマイズするのに役立ちます。以下に使用します:

ビジネスコンテキスト:

/intake-from-codebase . --guidance "ヘルスケア向けB2B SaaS、HIPAA準拠が重要、50k ユーザー"

分析フォーカス:

/intake-from-codebase . --guidance "SOC2監査のセキュリティ態勢とコンプライアンスギャップに焦点を当てる"

プロフィールヒント:

/intake-from-codebase . --guidance "プロトタイプからMVPへ移行、チームメンバー追加前にベースラインを確立する必要がある"

ペインポイント:

/intake-from-codebase . --guidance "スケール時のパフォーマンス問題、モノリスからマイクロサービスへの移行を検討中"

組み合わせ:

/intake-from-codebase . --interactive --guidance "フィンテックアプリ、PCI-DSS必須、Series A資金調達準備中"

ガイダンスが分析に与える影響:

• 優先順位付け 特定領域(セキュリティ、コンプライアンス、スケール、パフォーマンス)
• 推測 文脈に基づいて不足情報を推測(例:「ヘルスケア」→ HIPAA パターンを確認)
• 調整 プロフィール推奨(例:「コンプライアンス重要」→ Production/Enterprise を優先)
• カスタマイズ 質問(--interactive の場合、ガイダンス固有のトピックについて質問)
• 文書化 「なぜこのインテークが今必要か」セクション(ユーザー意図をキャプチャ)

目的

文書がほとんどまたは全くない既存のコードベース用の包括的なインテーク文書を生成し、チームが以下を行えるようにします:

• ブラウンフィールドプロジェクトをSDLCプロセス採用用に文書化する
• 継承または取得されたコードベースを理解する
• リファクタリングまたは近代化作業のベースラインを確立する
• コンプライアンス/監査用の過去のプロジェクトインテークを作成する

コードベース分析ワークフロー

ステップ0: ガイダンス処理(提供されている場合)

ユーザーが--guidance "text"を提供した場合、分析全体を通じてパースして適用します。

ガイダンスから抽出:

• ビジネスドメイン (ヘルスケア、フィンテック、e-コマース、エンタープライズ、コンシューマー)
• コンプライアンス要件 (HIPAA、PCI-DSS、GDPR、SOX、FedRAMP)
• スケール指標 (ユーザー数、トランザクション量、地理的分布)
• 現在のフェーズ (プロトタイプ、MVP、本番、エンタープライズ)
• ペインポイント (パフォーマンス、セキュリティ、技術的負債、チームスケーリング)
• 意図 (コンプライアンス準備、監査、ハンドオフ、近代化、資金調達)

ガイダンス適用対象:

1. 分析優先順位付け: ガイダンスで言及されている領域にフォーカス
2. プロフィール推奨: ガイダンスに基づいて条件を重み付け(例:「HIPAA」→ 品質の重みを増加)
3. インタラクティブ質問: ガイダンス固有のギャップについて質問(--interactive の場合)
4. 文書化: 「なぜこのインテークが今必要か」セクションでガイダンスを参照

ガイダンス処理例:

入力: --guidance "ヘルスケア向けB2B SaaS、HIPAA準拠が重要、50k ユーザー、SOC2監査準備中"

抽出済み:

• ドメイン: ヘルスケア(B2B SaaS)
• コンプライアンス: HIPAA(重要)、SOC2(進行中)
• スケール: 50k ユーザー(本番プロフィール可能性高い)
• 意図: 監査準備

適用済み:

• 優先順位: セキュリティ分析(HIPAA/SOC2 コントロール)、コンプライアンス指標、監査ログ
• プロフィール重み: 品質 0.4、信頼性 0.3(コンプライアンス駆動)
• 質問(--interactive の場合): 「現在どのHIPAAコントロールが実装されていますか?」、「SOC2監査はいつ予定されていますか?」
• 文書化: 「なぜこのインテークが今必要か」に取り込む→「ヘルスケアSaaS(HIPAA準拠)のSOC2監査準備」

ステップ1: 初期偵察

コードベースディレクトリをスキャンして基本特性を理解します。

コマンド:

# ディレクトリ構造
ls -la
find . -type f | head -50

# 拡張子別ファイル数
find . -type f | sed 's/.*\.//' | sort | uniq -c | sort -rn | head -20

# 一般的なマーカーをチェック
ls README.md CONTRIBUTING.md LICENSE package.json requirements.txt Dockerfile docker-compose.yml .git

抽出:

• プロジェクト名: git リモート、package.json/パッケージ名、README タイトル、ディレクトリ名から
• 主要言語: ファイル拡張子(.js、.py、.java、.goなど)
• フレームワーク指標: package.json、requirements.txt、pom.xml、go.mod、Gemfile
• インフラ: Dockerfile、docker-compose.yml、kubernetes/、terraform/、.github/workflows/

出力: 初期偵察サマリ

## 初期偵察

**プロジェクト名**: {git/package.json/ディレクトリから抽出}
**主要言語**: {JavaScript (45%)、Python (30%)、Shell (15%)、YAML (10%)}
**技術スタック指標**:
- フロントエンド: React 18.2.0、Next.js 13.4
- バックエンド: Node.js 18、Express 4.18
- データベース: PostgreSQL (docker-compose.yml)
- デプロイ: Docker、GitHub Actions CI/CD

**リポジトリ**: {git リモートURL(利用可能な場合)}
**最終コミット**: {git log -1 --format="%ai %s"}
**コード行数**: {cloc サマリ(利用可能な場合)}

ステップ2: アーキテクチャ分析

コードベース構造を分析してアーキテクチャパターンを理解します。

コマンド:

# ディレクトリ構造(キーパス)
tree -L 3 -d

# コンポーネント/モジュール識別
ls src/ lib/ app/ pkg/ cmd/
ls -la src/*/

# API/インターフェース発見
grep -r "app\." --include="*.js" | head -20
grep -r "router\." --include="*.py" | head -20
grep -r "@RestController\|@RequestMapping" --include="*.java" | head -20

# データベース/データレイヤー
ls models/ entities/ migrations/ schema/
grep -r "CREATE TABLE\|mongoose.model\|sqlalchemy" | head -20

推測:

• アーキテクチャスタイル: モノリス、マイクロサービス、サーバーレス、MVC、レイヤード
  • src/ を持つ単一リポジトリ→ モノリス
  • 複数の services/ または apps/ → マイクロサービス
  • Functions/ または lambda/ → サーバーレス
• コンポーネント境界: フロントエンド、バックエンド、API、サービス、ワーカー、CLI
• データ永続化: SQL (PostgreSQL、MySQL)、NoSQL (MongoDB、Redis)、ORM 指標
• 統合ポイント: 外部 API 呼び出し、メッセージキュー、イベントバス

出力: アーキテクチャサマリ

## アーキテクチャサマリ

**スタイル**: {モジュラーモノリス | マイクロサービス | レイヤード | イベント駆動}

**コンポーネント**:
- フロントエンド: src/client/ の React SPA (TypeScript)
- バックエンド API: src/server/ の Express REST API (Node.js)
- データベース: Prisma ORM を使用した PostgreSQL (schema/prisma/)
- バックグラウンドジョブ: Bull キュー (src/workers/)

**統合ポイント**:
- 支払い用 Stripe API (src/services/payment/)
- メール用 SendGrid (src/services/email/)
- ファイルストレージ用 AWS S3 (src/services/storage/)

**データモデル**: {count} 個のエンティティ (User、Order、Product、Payment など)

ステップ3: 依存関係およびインフラ分析

依存関係、デプロイ、運用特性を分析します。

コマンド:

# Node.js 依存関係
cat package.json | jq '.dependencies, .devDependencies'
npm ls --depth=0

# Python 依存関係
cat requirements.txt Pipfile

# Docker/デプロイ
cat Dockerfile docker-compose.yml
ls -la .github/workflows/ .gitlab-ci.yml .circleci/

# 環境変数(機密データ処理を特定)
grep -r "process.env\|os.getenv\|System.getenv" --include="*.{js,py,java}" | wc -l
ls .env .env.example .env.template

推測:

• サードパーティサービス: 支払い(Stripe、PayPal)、メール(SendGrid、Mailgun)、分析(Segment、Google Analytics)、モニタリング(Sentry、Datadog)
• セキュリティパターン: 認証ライブラリ(passport、jwt)、暗号化、シークレット管理
• テスト戦略: テストフレームワーク(Jest、Pytest、JUnit)、カバレッジツール、CI テストジョブ
• デプロイ: コンテナ化(Docker)、クラウドプロバイダー(AWS、GCP、Azure)、CI/CD 成熟度
• コンプライアンス指標: GDPR(同意、データ削除)、PCI-DSS(支払いトークン化)、HIPAA(監査ログ)

出力: 依存関係とインフラサマリ

## 依存関係とインフラ

**主要依存関係**:
- 認証: Passport.js + JWT
- 支払い: Stripe SDK 12.0.0
- メール: SendGrid 7.7.0
- テスト: Jest 29.5、React Testing Library

**セキュリティ**:
- 認証: リフレッシュトークン付き JWT
- シークレット: 環境変数(.env パターン)
- データ保護: パスワード用 bcrypt、保存時暗号化(検出: crypto モジュール使用)

**CI/CD**:
- プラットフォーム: GitHub Actions
- パイプライン: lint → test → build → deploy
- デプロイ対象: AWS ECS (Dockerfile 存在)

**モニタリング/可観測性**:
- エラー追跡: Sentry 統合検出
- ログ: 構造化 JSON を使用した Winston ロガー
- メトリクス: 基本(APM 検出なし)

ステップ4: スケールおよび使用分析

スケール指標と現在の使用パターンのコードを分析します。

コマンド:

# データベースクエリ(スケールパターン)
grep -r "SELECT.*FROM\|.find(\|.aggregate(" --include="*.{js,py,sql}" | wc -l

# キャッシュ指標
grep -r "redis\|memcached\|cache" --include="*.{js,py}" | wc -l

# レート制限/スロットリング
grep -r "rate.*limit\|throttle" --include="*.{js,py}" | wc -l

# 非同期/キューパターン
grep -r "async\|await\|queue\|job\|worker" --include="*.{js,py}" | wc -l

# API エンドポイント(数)
grep -r "app\.get\|app\.post\|@app.route" --include="*.{js,py}" | wc -l

推測:

• 現在のスケール容量:
  • キャッシュなし、シンプルクエリ→ <1k ユーザー
  • Redis キャッシング、接続プーリング→ 1k-10k ユーザー
  • ロードバランシング、キューワーカー、シャーディング→ 10k-100k ユーザー
• パフォーマンス最適化: キャッシング、インデックス作成、ページネーション、遅延ロード
• 同時実行モデル: 同期、非同期、イベント駆動、ワーカープール

出力: スケールおよびパフォーマンスサマリ

## スケールとパフォーマンス

**現在の容量推定**: 1k-5k 同時実行ユーザー
**証拠**:
- Redis キャッシング実装(10 インスタンス)
- データベース接続プーリング(最大20接続)
- 水平スケーリング検出なし(単一インスタンス)
- 基本的なレート制限(IP あたり 100 req/min)

**パフォーマンスパターン**:
- キャッシング: セッションと API レスポンス用 Redis
- 非同期: 広範な async/await 使用(Node.js)
- バックグラウンドジョブ: メール、レポート用 Bull キュー
- データベース: インデックス付きクエリ、リストのページネーション

**最適化機会**:
- 静的アセット用 CDN を追加
- クエリ結果キャッシングを実装
- データベース用読み取りレプリカを検討

ステップ5: セキュリティおよびコンプライアンス分析

セキュリティ態勢とコンプライアンス指標を分析します。

コマンド:

# 認証パターン
grep -r "passport\|jwt\|oauth\|auth0" --include="*.js" | wc -l

# データプライバシーパターン
grep -r "gdpr\|privacy\|consent\|deletion\|right.*forget" --include="*.{js,py,md}" | wc -l

# 機密データ処理
grep -r "password\|secret\|credit.*card\|ssn\|api.*key" --include="*.js" | wc -l

# セキュリティヘッダ
grep -r "helmet\|cors\|csp\|hsts" --include="*.js" | wc -l

# 監査ログ
grep -r "audit.*log\|log.*audit\|event.*log" --include="*.{js,py}" | wc -l

推測:

• セキュリティ態勢: 最小、ベースライン、強力、エンタープライズ
  • 基本認証のみ→ 最小
  • 認証 + HTTPS + シークレット管理→ ベースライン
  • SAST、DAST、脅威モデリング→ 強力
  • SOC2/ISO27001 コントロール→ エンタープライズ
• データ分類: 公開、内部、機密、制限
• コンプライアンス: GDPR (EU ユーザー)、HIPAA (健康データ)、PCI-DSS (支払い)、SOX (財務)

出力: セキュリティおよびコンプライアンスサマリ

## セキュリティとコンプライアンス

**セキュリティ態勢**: ベースライン
**証拠**:
- 認証: リフレッシュトークン付き JWT、bcrypt パスワード
- 認可: ロールベースアクセス制御(3 ロール: user、admin、superadmin)
- データ保護: 保存時暗号化(検出)、転送中 TLS
- シークレット管理: 環境変数、ハードコードされたシークレットは検出されない
- セキュリティヘッダ: HTTP ヘッダ用 Helmet.js、CORS 設定

**データ分類**: 機密
**検出された機密データ**:
- PII: メール、名前、住所を含むユーザープロフィール
- 支払い: Stripe トークン化(クレジットカードトークン)
- PHI または健康データは検出されない

**コンプライアンス指標**:
- GDPR: 同意管理、データ削除エンドポイント存在
- PCI-DSS: Stripe がカードデータを処理(準拠トークン化)
- HIPAA または SOX 要件は検出されない

ステップ6: チームおよびプロセス指標

チームサイズ、プロセス成熟度、運用パターンについてリポジトリを分析します。

コマンド:

# Git コミット履歴
git log --format="%an" | sort | uniq -c | sort -rn | head -10
git log --since="1 year ago" --format="%ai" | wc -l

# 貢献者
git shortlog -sn | head -10

# ブランチ戦略
git branch -a | grep -E "main|master|develop|release|hotfix"

# ドキュメント
find . -name "*.md" | wc -l
ls docs/ README.md CONTRIBUTING.md

# テストカバレッジ
grep -r "test\|spec" --include="*.{js,py}" | wc -l

推測:

• チームサイズ:
  • アクティブなコミッター1-2 名→ 小さいチーム(1-3 開発者)
  • アクティブなコミッター3-5 名→ 中程度のチーム(4-8 開発者)

  • 10 アクティブなコミッター→ 大きいチーム(>10 開発者)

• 開発速度: 週単位のコミット
• プロセス成熟度: フィーチャーブランチ、PR レビュー、セマンティックバージョニング、チェンジログ
• ドキュメンテーション品質: README、API ドキュメント、ランブック、アーキテクチャドキュメント

出力: チームおよびプロセスサマリ

## チームとプロセス

**推定チームサイズ**: 小(2-3 開発者)
**証拠**:
- 過去6ヶ月間に3人のアクティブな貢献者
- 過去四半期に47コミット(平均 1.5 commits/日)

**ブランチ戦略**: GitHub フロー(main + フィーチャーブランチ)
**プロセス指標**:
- プルリクエスト: main ブランチに必須
- コードレビュー: 1 承認者必須(.github/ から検出)
- テスト: 68% テストカバレッジ(CI で報告)
- バージョニング: セマンティックバージョニング(package.json)

**ドキュメント**:
- README: 包括的(セットアップ、使用、デプロイ)
- API ドキュメント: OpenAPI spec 存在(docs/api.yaml)
- 貢献ガイド: 存在
- ランブック: なし(運用ギャップ)

ステップ7: インタラクティブ明確化(オプション)

あいまいまたは不足情報を明確にするために的を絞った質問を行います。

質問カテゴリ(最大10問):

1. ビジネスコンテキスト(コードベースから不明な場合):

   • 「このシステムはどのような問題を解決していますか?主要ユーザーは誰ですか?」
   • 「主要なビジネスメトリクスまたは成功基準は何ですか?」

2. 現在の状態(デプロイが不明な場合):

   • 「このシステムは現在本番運用中ですか?もしそうなら、アクティブユーザーは何人ですか?」
   • 「本番環境は何ですか?(AWS、GCP、Azure、オンプレミス?)」

3. ペインポイント(改善機会を通知するために):

   • 「このシステムの最大の課題は何ですか?」
   • 「既知のパフォーマンス問題や近代化が必要な領域はありますか?」

4. 将来の方向性(インテークコンテキストをフレーム化するために):

   • 「なぜ今インテーク文書を作成するのですか?(コンプライアンス、ハンドオフ、近代化?)」
   • 「ロードマップ内に予定された変更やリファクタリングはありますか?」

5. 不足情報(分析からのギャップ):

   • 「モニタリング/可観測性ツールを検出できませんでした。何を使用していますか?」
   • 「明示的なコンプライアンスドキュメントが見つかりませんでした。規制要件はありますか?」

適応ロジック:

• コードベースが明確な証拠を提供する場合、質問をスキップ
• ビジネスコンテキスト質問を優先(最も価値があり、推測が最も難しい)
• 重要なギャップが存在する場合のみ技術的な質問を行う

インタラクティブフロー例:

./my-api-project のコードベースを分析中...

✓ 検出: Node.js + Express + PostgreSQL + React
✓ アーキテクチャ: 4つの主要コンポーネントを持つモジュラーモノリス
✓ スケール指標: キャッシング、接続プーリング(推定 1k-5k ユーザー)
✓ セキュリティ: JWT 認証、Stripe 支払い、GDPR パターン検出

インテーク文書を完成させるためにいくつか質問があります:

質問 1/10: このAPI が解決するビジネス上の問題は何ですか?主要ユーザーは誰ですか?

{ユーザーが応答: 「倉庫マネージャー向けのB2B SaaS 在庫管理プラットフォーム。」}

質問 2/10: 現在本番運用中ですか?もしそうなら、アクティブな企業/ユーザー数は?

{ユーザーが応答: 「はい、6ヶ月前にローンチ。12社、約150ユーザー。」}

質問 3/10: GDPR パターンを検出しました。顧客の大多数は EU にいますか?

{ユーザーが応答: 「12社中8社が EU ベースなので、はい GDPR は重要。」}

質問 4/10: 今日のシステムで最大の課題は何ですか?

{ユーザーが応答: 「大きな在庫(>10k アイテム)ではパフォーマンスが低下。クエリを最適化する必要がある。」}

了解しました!完全なインテーク文書を生成しています...

ステップ8: 完全なインテーク文書を生成

既存システムを文書化する3つのインテークファイルを作成します。

出力ファイル:

1. .aiwg/intake/project-intake.md - 包括的なプロジェクト文書
2. .aiwg/intake/solution-profile.md - 現在のプロフィールと成熟度レベル
3. .aiwg/intake/option-matrix.md - 近代化/改善オプション

生成: project-intake.md

# プロジェクトインテークフォーム(既存システム)

**文書型**: ブラウンフィールドシステム文書
**生成日**: {現在の日付}
**ソース**: {ディレクトリ}のコードベース分析

## メタデータ

- プロジェクト名: {git/package.json から抽出}
- リポジトリ: {git リモートURL}
- 現在のバージョン: {package.json バージョンまたは git タグ}
- 最終更新: {git ログ日付}
- ステークホルダー: {推測: エンジニアリングチーム、プロダクト、オペレーション}

## システム概要

**目的**: {ユーザーの質問または README から}
**現在の状態**: 本番運用中({git 履歴またはユーザーから日付をローンチ})
**ユーザー**: {ユーザーから、または「不明」}
**技術スタック**:
- 言語: {検出言語とパーセンテージ}
- フロントエンド: {検出フレームワーク}
- バックエンド: {検出フレームワーク}
- データベース: {docker-compose、接続文字列から検出}
- デプロイ: {検出: Docker/クラウドプロバイダー}

## 問題と結果(過去)

**問題声明**: {ユーザーから、または README から}
**ターゲットペルソナ**: {ユーザーから、または UI/API デザインから推測}
**成功メトリクス**: {ユーザーから、または推測}
  - ユーザー採用: {現在数}
  - システムアップタイム: {モニタリングから推測}
  - パフォーマンス: {最適化パターンから推測}

## 現在のスコープと機能

**コア機能**(コードベース分析から):
{ルート、コンポーネント、モデルを分析して機能をリスト化}
- ユーザー認証と認可({検出ロール})
- {ルートから検出された機能1}
- {モデルから検出された機能2}
- {コンポーネントから検出された機能3}

**最近の追加**(git ログ過去6ヶ月から):
{最近のフィーチャーブランチまたはコミットメッセージをリスト}

**計画中/進行中**(オープンフィーチャーブランチから):
{オープンフィーチャーブランチをリスト}

## アーキテクチャ(現在の状態)

**アーキテクチャスタイル**: {モノリス | マイクロサービス | サーバーレス}
**コンポーネント**:
{分析ステップ2から}

**データモデル**: {数} 個の主要エンティティ
{主要モデルをリスト化: User、Order、Product など}

**統合ポイント**:
{外部 API の grep 分析から}

## スケールとパフォーマンス(現在)

**現在の容量**: {スケール分析から推測}
**アクティブユーザー**: {ユーザーから、または「容量指標に基づく推定: X」}
**パフォーマンス特性**:
- レスポンスタイム: {最適化パターンから推測}
- スループット: {推測}
- 可用性: {推測}

**存在するパフォーマンス最適化**:
{検出パターンをリスト化: キャッシング、インデックス、非同期、キューイング}

**ボトルネック/ペインポイント**:
{ユーザーの質問から、またはコードコメント(TODO、FIXME)から}

## セキュリティとコンプライアンス(現在)

**セキュリティ態勢**: {最小 | ベースライン | 強力 | エンタープライズ}
**データ分類**: {公開 | 内部 | 機密 | 制限}

**セキュリティコントロール**:
- 認証: {検出メカニズム}
- 認可: {RBAC、ABAC など}
- データ保護: {検出または検出なし}
- シークレット管理: {環境変数、vault など}

**コンプライアンス要件**:
{検出パターンまたはユーザーの質問から}
- GDPR: {Yes/No - 証拠: 同意、削除エンドポイント}
- PCI-DSS: {Yes/No - 証拠: 支払いトークン化}
- HIPAA: {Yes/No - 証拠: 監査ログ、PHI 処理}

## チームと運用(現在)

**チームサイズ**: {git 貢献者から推測}
**アクティブな貢献者**: {過去6ヶ月間の数}
**開発速度**: {月単位の平均コミット数}

**プロセス成熟度**:
- バージョン管理: {Git フロー、GitHub フロー など}
- コードレビュー: {PR 要件から検出}
- テスト: {カバレッジパーセンテージ(利用可能な場合)}
- CI/CD: {検出パイプライン: GitHub Actions、GitLab CI など}
- ドキュメント: {README、API ドキュメント、ランブック の存在/不在}

**運用サポート**:
- モニタリング: {検出: Sentry、Datadog など、または「検出なし」}
- ログ: {検出: Winston、Bunyan など}
- アラート: {検出または「検出なし」}
- オンコール: {不明 - 明確化対象にマーク}

## 依存関係とインフラ

**サードパーティサービス**:
{package.json、requirements.txt 分析から}

**インフラ**:
- ホスティング: {検出クラウドプロバイダーまたは「不明」}
- デプロイ: {Docker、Kubernetes、PaaS}
- データベース: {PostgreSQL、MongoDB など}
- キャッシング: {Redis、Memcached、または「なし」}
- メッセージキュー: {RabbitMQ、SQS、または「なし」}

## 既知の問題と技術的負債

**パフォーマンス問題**:
{ユーザーの質問または FIXME コメントから}

**セキュリティギャップ**:
{分析から - SAST 不在、古い依存関係など}

**技術的負債**:
{TODO コメント、廃止された依存関係、テストカバレッジギャップから}

**近代化機会**:
{古いバージョン、欠落したベストプラクティスから}

## なぜこのインテークが今必要か

**コンテキスト**: {ユーザーから: コンプライアンス、ハンドオフ、リファクタリング、プロセス採用}

**目標**:
{コンテキストから推測}
- 既存システムの SDLC ベースラインを確立
- コンプライアンス/監査用に文書化
- 近代化ロードマップを計画
- チーム ハンドオフ/オンボーディングをサポート

## 添付資料

- ソリューションプロフィール: リンク to `solution-profile.md`
- オプションマトリックス: リンク to `option-matrix.md`
- コードベース位置: `{ディレクトリパス}`
- リポジトリ: `{git リモートURL}`

## 次のステップ

**インテーク文書が完成し、次フェーズの準備ができました!**

1. **レビュー** 生成されたインテーク文書の正確性確認
2. **ギャップを埋める** 「不明」または「明確化」とマークされた項目(あれば)
3. **改善パスを選択** option-matrix.md から:
   - 現状維持 SDLC プロセス採用で
   - 段階的近代化
   - 大規模リファクタリング/リライト
4. **適切な SDLC フロー開始** 自然言語または明示的なコマンド使用:
   - 新しい SDLC 採用: 「Inception を開始」または `/flow-concept-to-inception .`
   - 保守/イテレーション: 「イテレーション1 を実行」または `/flow-iteration-dual-track 1`
   - アーキテクチャ変更: 「アーキテクチャを進化」または `/flow-architecture-evolution`

**注**: `/intake-start`を実行する必要はありません - そのコマンドはインテーク文書を手動で作成したチームのみ対象です。`intake-from-codebase`コマンドは即座に使用可能な検証済みインテークを生成します

生成: solution-profile.md

# ソリューションプロフィール(現在のシステム)

**文書型**: 既存システムプロフィール
**生成日**: {現在の日付}

## 現在のプロフィール

**プロフィール**: {本番 | エンタープライズ}

**選択根拠**:
{証拠に基づく}
- システム状態: 本番環境で {X} 個のアクティブユーザー
- コンプライアンス: {GDPR/PCI-DSS/等} 要件が存在
- チームサイズ: {数} 開発者
- プロセス成熟度: {高/中/低}

**実際**: 本番(本番環境で、確立されたユーザー、コンプライアンス要件)

## 現在の状態特性

### セキュリティ
- **態勢**: {最小 | ベースライン | 強力 | エンタープライズ}
- **存在するコントロール**: {分析から}
- **ギャップ**: {見つかったギャップをリスト化}
- **推奨**: {ギャップが見つかった場合、セキュリティレベルをアップグレード}

### 信頼性
- **現在の SLO**: {モニタリングが検出された場合}
  - 可用性: {パーセンテージ、または「モニタリングなし」}
  - レイテンシ: {p95/p99、または「測定なし」}
  - エラー率: {パーセンテージ、または「追跡なし」}
- **モニタリング成熟度**: {メトリクス、ログ、トレース、アラート}
- **推奨**: {ギャップがある場合、可観測性を改善}

### テストと品質
- **テストカバレッジ**: {パーセンテージ(利用可能な場合)}
- **テスト型**: {検出: ユニット、統合、e2e}
- **品質ゲート**: {CI チェック、リント、セキュリティスキャン}
- **推奨**: {ターゲットカバレッジ改善}

### プロセス厳格性
- **SDLC 採用**: {なし/部分/完全}
- **コードレビュー**: {存在/なし}
- **ドキュメント**: {包括的/基本/最小}
- **推奨**: {SDLC フレームワーク採用、ドキュメント改善}

## 推奨プロフィール調整

**現在のプロフィール**: {検出}
**推奨プロフィール**: {ギャップに基づく提案}

**根拠**:
{アップグレード推奨理由を説明}
- セキュリティギャップに {強力} プロフィールコントロールが必要
- コンプライアンス要件が {エンタープライズ} 厳格性を必須化
- スケールが {本番} 信頼性標準を要求

**カスタマイズメモ**:
- 軽量プロセスを保持(小さいチーム)
- セキュリティコントロール追加(コンプライアンス要件)
- 可観測性を実装(本番システム)

## 改善ロードマップ

**フェーズ1(即座 - 1ヶ月)**:
{重要なギャップを埋める}
- セキュリティスキャン追加(SAST/DAST)
- モニタリングとアラート実装
- 一般的な問題用ランブック作成

**フェーズ2(短期 - 3ヶ月)**:
{重要な改善}
- テストカバレッジを {ターゲット}% に増加
- アーキテクチャ文書化(SAD)
- SDLC フレームワーク採用(デュアルトラックイテレーション)

**フェーズ3(長期 - 6-12ヶ月)**:
{戦略的改善}
- パフォーマンス最適化(ボトルネック対応)
- アーキテクチャ近代化(必要な場合)
- コンプライアンス認定(SOC2、ISO27001)

生成: option-matrix.md

agentic/code/frameworks/sdlc-complete/templates/intake/option-matrix-template.mdのテンプレート構造をフォロー:

主要原則:

1. 説明的で規範的でない - あるもの(プロジェクト現実)をキャプチャ、あるべきもの(分析)ではない
2. 自然言語 - 説明的なプロジェクトタイプを使用(「Prototype プロフィール」ではなく「個人ブログ、読者<100」)
3. 意図駆動 - インタラクティブ質問(6-8 of 10)を優先度、トレードオフ、決定、進化に焦点
4. フレームワークマッピング - プロジェクト現実を関連テンプレート/コマンド/エージェント/厳格性レベルにマップ

# オプションマトリックス(プロジェクトコンテキストと意図)

**目的**: このプロジェクトが「何であるか」をキャプチャ - その性質、対象者、制約、意図 - 適切な SDLC フレームワーク適用(テンプレート、コマンド、エージェント、厳格性レベル)を決定する。

**生成日**: {現在の日付}(コードベース分析から)

## ステップ1: プロジェクト現実

### このプロジェクトは「何であるか」?

**プロジェクト説明**(自然言語):

{コードベース分析とユーザーガイダンスに基づいて2-3文で説明:}

例:

• 「ドキュメンテーションフレームワークと SDLC ツールキット(60 エージェント、40 コマンド)、474 markdown ファイル、GitHub ホスト オープンソース(MIT)、0 ユーザー(プレローンチ)、ソロ開発者(30年間システムエンジニアリング)、複数のリファクタリングをマルチプラットフォーム進化に期待」
• 「5 人の倉庫スタッフ向けB2B 在庫追跡アプリ、毎日の操作に重要、ローカルサーバー上の Node.js + PostgreSQL、50k SKU、1日8時間使用、パートタイム開発者2人、新機能を制限する中程度の技術的負債」
• 「求人応募用の個人ポートフォリオサイト、月10-20 訪問者予定、GitHub Pages 上の静的 HTML/CSS、ソロプロジェクト、2週間でシップする必要がある」

### 対象者とスケール

**誰がこれを使用していますか?** (分析から確認)
- {[x] 検出時} 自分だけ(個人プロジェクト) - {証拠: ソロ git 貢献者、ガイダンス}
- {[x] 検出時} 小さいチーム(2-10 人、既知個人) - {証拠: 倉庫スタッフ、社内ツール}
- {[x] 検出時} 部門(10-100 人、組織内部)
- {[x] 検出時} 外部顧客(100-10k ユーザー、有料または無料) - {証拠: 支払い統合、マルチテナンシー}
- {[x] 検出時} 大規模(10k-100k+ ユーザー、公開向け) - {証拠: ロードバランシング、シャーディング}
- {[ ] 不明の場合} 他: `___ (インタラクティブ質問対象にマーク)`

**対象者特性**:
- 技術的洗練度: `{非技術的 | 混合 | 技術的}` - {UI 複雑度、API デザインから推測}
- ユーザーリスク許容度: `{実験的 OK | 安定性予想 | ゼロ許容}` - {SLA、重要性から推測}
- サポート期待: `{セルフサービス | ベストエフォート | SLA | 24/7}` - {ランブック、オンコールパターンから検出}

**使用スケール**(分析から現在または投影):
- アクティブユーザー: `{数}(日/週/月)`  - {ガイダンスから、または「質問対象にマーク」}
- リクエストボリューム: `{数} requests/min` または `N/A(バッチ/cron/手動使用)` - {スケール分析から}
- データボリューム: `{サイズ} GB/TB` または `N/A(ステートレス/小)` - {DB サイズ、S3 使用から}
- 地理的分布: `{単一地域 | 地域別 | マルチリージョン | グローバル}` - {デプロイ、CDN から}

### デプロイとインフラ

**予想デプロイモデル**(これはどうなるでしょう? - コードベースから推測):
- {[x] 検出時} クライアントのみ(デスクトップアプリ、モバイルアプリ、CLI ツール、ブラウザ拡張) - {検出: Electron config、React Native、モバイルディレクトリ、manifest.json for extensions、CLI scripts}
- {[x] 検出時} 静的サイト(HTML/CSS/JS、バックエンドなし、ホストファイル) - {検出: HTML/CSS/JS のみ、サーバーコードなし、静的サイトジェネレータ config(11ty、Hugo、Jekyll)、Netlify/Vercel/GitHub Pages deploy config}
- {[x] 検出時} クライアントサーバー(SPA + API バックエンド、バックエンド付き従来 Web アプリ、DB) - {検出: React/Vue/Angular + Express/Django/Rails、単一 DB、従来 MVC 構造}
- {[x] 検出時} フルスタックアプリケーション(フロント + バック + DB + サポートサービス) - {検出: 複数サービス(API、ワーカー、cron jobs)、メッセージキュー、キャッシングレイヤー、複数 data stores}
- {[x] 検出時} マルチシステム(複数サービス、マイクロサービス、サービスメッシュ、分散) - {検出: 複数 services/、>3 services の docker-compose、Kubernetes manifests、service discovery(Consul、Eureka)、API gateway}
- {[x] 検出時} 分散アプリケーション(エッジコンピューティング、P2P、ブロックチェーン、フェデレーション) - {検出: WebRTC、IPFS、ブロックチェーン SDK、エッジ関数 config(Cloudflare Workers、Lambda@Edge)、ピアツーピアプロトコル}
- {[x] 検出時} 埋め込み/IoT(デバイスファームウェア、組み込みシステム、ハードウェア統合) - {検出: Arduino/PlatformIO config、組み込み C/C++、HAL、シリアル通信、センサ統合}
- {[x] 検出時} ハイブリッド(複数デプロイパターン、例:モバイルアプリ + クラウドバックエンド) - {検出: 上記の組み合わせ指標}
- {[ ] 不明な場合} 他: `___ (インタラクティブ質問対象にマーク)`

**どこで実行されますか?**(インフラ分析から):
- {[x] 検出時} ローカルのみ(ラップトップ、デスクトップ、デプロイなし) - {Dockerfile なし、CI/CD なし、デプロイスクリプトなし}
- {[x] 検出時} 個人ホスティング(VPS、共有ホスティング、ホームサーバー) - {シンプルなデプロイスクリプト、SSH deploy、rsync パターン}
- {[x] 検出時} クラウドプラットフォーム(AWS、GCP、Azure、Vercel、Netlify、GitHub Pages) - {検出: terraform/、AWS SDK、gcloud config、azure-pipelines.yml、vercel.json、netlify.toml、GitHub Actions with pages deploy}
- {[x] 検出時} オンプレミス(企業サーバー、データセンター) - {ガイダンスから、または local server evidence、ansible playbooks、chef/puppet configs}
- {[x] 検出時} ハイブリッド(クラウド + オンプレミス、マルチクラウド) - {複数クラウドプロバイダー検出、ハイブリッド アーキテクチャ指標}
- {[x] 検出時} エッジ/CDN(分散、地理的に分散) - {Cloudflare Workers、Lambda@Edge、CDN configs}
- {[x] 検出時} モバイル(iOS、Android、ネイティブまたはクロスプラットフォーム) - {Xcode project、Android Studio、React Native、Flutter、Ionic}
- {[x] 検出時} デスクトップ(Windows、macOS、Linux 実行可能ファイル) - {Electron、.NET、Qt、PyInstaller、pkg configs}
- {[x] 検出時} ブラウザ(拡張機能、PWA、Web アプリ) - {extensions の manifest.json、PWA の service-worker.js、Web app manifest}
- {[ ] 不明な場合} 他: `___ (インタラクティブ質問対象にマーク)`

**インフラ複雑度**:
- デプロイ型: `{静的サイト | 単一サーバー | マルチティア | マイクロサービス | サーバーレス | コンテナ オーケストレーション}` - {アーキテクチャ分析から: 静的 HTML、単一 Dockerfile、Docker-compose with tiers、services/ directory、Lambda functions、kubernetes/}
- データ永続化: `{なし(ステートレス) | クライアント側のみ | ファイルシステム | 単一 DB | 複数 data stores | 分散 DB}` - {依存関係から: DB ライブラリなし、localStorage/IndexedDB、ファイル I/O、単一 DB 接続、複数 DB(PostgreSQL + Redis + Elasticsearch)、Cassandra/MongoDB sharding}
- 外部依存: `{数} サードパーティサービス(0 = なし、1-3 = 少数、4-10 = 中程度、10+ = 多数)` - {検出 API 統合から: Stripe、SendGrid、Twilio、AWS サービスなど}
- ネットワークトポロジ: `{スタンドアロン | クライアント-サーバー | マルチティア | ピアツーピア | メッシュ | ハイブリッド}` - {アーキテクチャから: 単一プロセス、クライアント + サーバー、フロント + API + DB + workers、WebRTC/P2P、service mesh(Istio、Linkerd)、combination}

### 技術複雑度

**コードベース特性**(分析から):
- サイズ: `{<1k | 1k-10k | 10k-100k | 100k+} LoC` - {cloc または file count estimate から}
- 言語: `{主要}、{二次的な言語(あれば)}` - {ファイル拡張子、パーセンテージから}
- アーキテクチャ: `{単一スクリプト | シンプルアプリ | モジュラー | マルチサービス | 複雑分散}` - {ステップ2分析から}
- チーム親密度: `{グリーンフィールド | ブラウンフィールド | レガシー}` - {git 履歴、技術的負債指標から}

**技術リスク要因**(セキュリティ/パフォーマンス分析から確認):
- {[x] 検出時} パフォーマンス感度(レイテンシ、スループット重要) - {キャッシング、最適化パターン}
- {[x] 検出時} セキュリティ感度(PII、支払い、認証) - {JWT、暗号化、コンプライアンス指標}
- {[x] 検出時} データ整合性重要(財務、医療、法的記録) - {トランザクションパターン、監査ログ}
- {[x] 検出時} 高い同時実行数(多くの同時