jmagly/aiwg – コードベースからのインテーク生成

スキルアクセスパターン（カーネルピボット後、2026.5+）

このドキュメントで参照されているスキル名は、AIWGスキルであり、スラッシュコマンドではありません。 そのほとんどはカーネルにリストされておらず、プラットフォームで /skill-name として呼び出すことはできません。 以下の方法でアクセスしてください：

aiwg discover "<capability>"
aiwg show skill <name>

カーネルにリストされているスキル（aiwg-doctor、aiwg-refresh、aiwg-status、aiwg-help、use、steward）のみが、スラッシュコマンドとして直接呼び出し可能です。skill-discovery rule を参照してください。

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

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

カーネル委譲

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 の場合、最大10問）
6. 生成: 既存のシステムを文書化する完全なインテークフォームを生成する

パラメータ

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

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

--guidance パラメータは自由形式のテキストを受け付け、分析の調整に役立ちます。以下の用途に使用します:

ビジネスコンテキスト:

/intake-from-codebase . --guidance "医療向けB2B SaaS、HIPAAコンプライアンスが重要、5万人のユーザー"

分析の焦点:

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

プロファイルのヒント:

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

問題点:

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

組み合わせ:

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

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

• 特定の領域（セキュリティ、コンプライアンス、スケール、パフォーマンス）を優先する
• コンテキストに基づいて不足情報を推測する（例：「医療」→ HIPAAパターンをチェック）
• プロファイルの推奨を調整する（例：「コンプライアンス重要」→ 本番/エンタープライズを優先）
• 質問を調整する（--interactive の場合、ガイダンス固有のトピックについて質問する）
• 「なぜ今このインテークなのか？」セクションに文書化する（ユーザーの意図をキャプチャ）

目的

ドキュメントがほとんど、またはまったくない可能性のある既存のコードベースに対して、包括的なインテーク文書を生成し、チームが以下を実行できるようにします:

• SDLCプロセス採用のためのブラウンフィールドプロジェクトの文書化
• 継承または買収したコードベースの理解
• リファクタリングまたはモダナイゼーションの取り組みのためのベースライン確立
• コンプライアンス/監査のための履歴プロジェクトインテークの作成

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

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

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

ガイダンスから抽出:

• ビジネスドメイン（医療、フィンテック、Eコマース、エンタープライズ、コンシューマー）
• コンプライアンス要件（HIPAA、PCI-DSS、GDPR、SOX、FedRAMP）
• スケール指標（ユーザー数、トランザクション量、地理的分布）
• 現在のフェーズ（プロトタイプ、MVP、本番、エンタープライズ）
• 問題点（パフォーマンス、セキュリティ、技術負債、チームスケーリング）
• 意図（コンプライアンス準備、監査、ハンドオフ、モダナイゼーション、資金調達）

以下にガイダンスを適用:

1. 分析の優先順位付け: ガイダンスで言及された領域に焦点を当てる
2. プロファイルの推奨: ガイダンスに基づいて基準に重み付けする（例：「HIPAA」→ 品質の重みを増やす）
3. インタラクティブな質問: ガイダンス固有のギャップについて質問する（--interactive の場合）
4. 文書化: 「なぜ今このインテークなのか？」セクションでガイダンスを参照する

ガイダンス処理の例:

入力: --guidance "医療向けB2B SaaS、HIPAAコンプライアンスが重要、5万人のユーザー、SOC2監査の準備中"

抽出されたもの:

• ドメイン: 医療（B2B SaaS）
• コンプライアンス: HIPAA（重要）、SOC2（進行中）
• スケール: 5万人のユーザー（本番プロファイルの可能性が高い）
• 意図: 監査準備

適用:

• 優先: セキュリティ分析（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 remote、package.json/package名、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 remote 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つのロール: ユーザー、管理者、スーパー管理者）
- データ保護: 保存時暗号化（検出済み）、転送中TLS
- シークレット管理: 環境変数、ハードコードされたシークレットは未検出
- セキュリティヘッダー: HTTPヘッダー用Helmet.js、CORS設定済み

**データ分類**: 機密（ユーザーデータ、支払い情報を含むため）

**コンプライアンス**:
- GDPR: 同意管理検出、データ削除機能（src/services/gdpr/）
- PCI-DSS: 支払いトークン化検出（Stripe）、カードデータの直接保存はなし
- 監査: アクセスログあり、詳細な監査証跡なし

**脆弱性の可能性**:
- 認証されていない一部のエンドポイント（API監査推奨）
- レート制限の欠如（ブルートフォース攻撃のリスク）
- 機密データの環境変数（本番での安全なシークレットローテーションなし）

ステップ6: インテーク文書の生成

これまでのすべてのステップを統合し、標準化されたインテーク文書を生成します。

出力ファイル:

# プロジェクトインテーク: {Project Name}

## 概要
{2～3文のプロジェクト概要}

## プロジェクト詳細

### テクノロジースタック
- **言語**: {プライマリ言語と割合}
- **フレームワーク**: {検出されたフレームワーク}
- **データベース**: {データベーステクノロジー}
- **インフラストラクチャ**: {デプロイメントテクノロジー}

### アーキテクチャ
{アーキテクチャスタイルとコンポーネントの説明}

### 依存関係と統合
{主要な外部サービスと統合ポイント}

### セキュリティとコンプライアンス
{セキュリティ態勢とコンプライアンスステータス}

## メタデータ
- **インテーク日付**: {YYYY-MM-DD}
- **インテーク作成者**: AIWGインテーク（コードベース分析）
- **コードベースディレクトリ**: {絶対パス}
- **分析モード**: {自動 / インタラクティブ}
- **ガイダンス**: {提供されている場合、ユーザーガイダンスのテキスト}
- **生成ファイル**: {生成されたすべての出力ファイルのリスト}

## なぜ今このインテークなのか？
{ユーザーの意図とコンテキスト（ガイダンスから抽出、またはデフォルト）}

SDLCプロファイルの推奨事項: ガイダンスと分析に基づき、適切なSDLCプロファイルを推奨:

• 最小限: 単純なプロジェクト、低リスク、個人/趣味
• 基本的な品質: 成長中のチーム、基本的なプロセスが必要
• 本番: ユーザーフェーシングアプリ、安定性が重要
• エンタープライズ: 規制対象業界、厳格なコンプライアンス

推奨マトリックス:

基準	最小限	基本的な品質	本番	エンタープライズ
チームサイズ	1～2人	3～10人	10～50人	50人以上
ユーザーベース	<100人	100～1k人	1k～10k人	10k人以上
データ機密度	公開	社内	機密	制限付き
コンプライアンス	なし	基本	重要	必須
ダウンタイム影響	最小限	中程度	高い	重大

推奨プロファイル: {最小限 / 基本的な品質 / 本番 / エンタープライズ} 理由: {プロファイルの根拠}

相互作用（--interactive モード）

--interactive が使用された場合、各分析ステップ中に不明瞭な領域について質問します。

ガイダンス処理中:

• ガイダンスから抽出された情報の確認: 「医療SaaS for 5万人のユーザーと解釈しました。正しいですか？」

検出中:

• 不明瞭なパターンの明確化: 「src/services/ に 'legacy' フォルダがあります。これは移行中ですか、それともアクティブなコードですか？」

ギャップへの対処:

• 不足情報の質問: 「CI/CDパイプラインは検出されませんでした。デプロイは手動ですか、それとも別のツールを使用していますか？」

分析後:

• 推奨事項の検証: 「品質プロファイル（中程度のチームサイズと重要なデータのため）を推奨しています。これでよろしいですか？」

質問は簡潔で、関連性があり、進行中の分析に関連するものです（一度に最大10問）。