SKILL.md
analyze-gap: Gap分析
Gap分析スキルは、既存コードベースと新規実装の差分を分析し、統合ポイントを特定します。
概要
このスキルは以下を実行します：
- 既存コードベース分析:
- 既存のアーキテクチャを把握 - 既存のAPI・データモデルを確認
- 新規実装との差分分析:
- 新規実装が既存コードとどのように統合されるか - 競合する部分を特定
- 統合ポイント特定:
- インターフェースの統合ポイント - データモデルの統合ポイント - ワークフローの統合ポイント
- 実装戦略提案:
- 段階的な統合戦略 - リスク回避策 - ロールバック計画
- Gap分析レポート: 分析結果と実装戦略を記載
使用方法
自動発動
以下のキーワードで自動発動します：
- 「Gap分析したい」
- 「既存コードとの統合を分析」
- 既存システムへの新機能追加時に自動提案
明示的発動
/michi analyze-gap {pj-name}例:
/michi analyze-gap user-authサブエージェント活用（並列探索）
既存コードベースの探索を3つのExploreエージェントで並列実行します：
Phase 1: 並列コードベース探索
| エージェント | 対象 | 目的 | 出力 |
|---|---|---|---|
| アーキテクチャ探索 | src/, lib/, packages/ | レイヤー構造、設計パターン特定 | アーキテクチャ構造レポート |
| API探索 | routes/, controllers/, api/ | 既存APIエンドポイント一覧 | API仕様リスト |
| データモデル探索 | models/, entities/, migrations/ | DBスキーマ、リレーション | データモデルリスト |
Phase 2: 統合分析（メインエージェント）
- Phase 1の結果を統合
- 新規実装との差分を分析
- Gap分析レポート生成
メリット:
- コードベース探索を大幅に高速化（並列実行により）
- 複数の観点から並行して分析
- 各エージェントが独立して動作し、結果を統合
実行内容
1. 既存コードベース分析
既存アーキテクチャの把握:
- レイヤー構造
- 使用技術スタック
- 設計パターン
既存API・データモデルの確認:
- REST API エンドポイント一覧
- データベーススキーマ
- 外部サービス連携
2. 新規実装との差分分析
新規実装の影響範囲:
- 新規追加されるAPI
- 新規追加されるテーブル
- 既存APIの変更
競合する部分を特定:
- 既存のユーザー認証と新規実装の認証
- 既存のデータモデルと新規実装のデータモデル
- 既存のワークフローと新規実装のワークフロー
3. 統合ポイント特定
インターフェースの統合ポイント:
- API Gateway との統合
- フロントエンドとの統合
- 外部サービスとの統合
データモデルの統合ポイント:
- 既存テーブルとの外部キー
- 共有されるマスターデータ
- データ移行が必要な部分
ワークフローの統合ポイント:
- 既存の処理フローに新機能を組み込む
- イベント駆動の統合
4. 実装戦略提案
段階的な統合戦略:
- Phase 1: 独立した機能として実装（既存コードに影響なし）
- Phase 2: API統合（新規APIを既存フロントエンドから呼び出し）
- Phase 3: データ統合（既存データと新規データを連携）
- Phase 4: ワークフロー統合（既存処理フローに組み込み）
リスク回避策:
- Feature Flagを使用して段階的にロールアウト
- Blue-Green Deployment で切り替え
- カナリアリリースで段階的に展開
ロールバック計画:
- データベース変更のロールバックスクリプト
- Feature Flagでの機能無効化
- 以前のバージョンへのデプロイ手順
5. Gap分析レポート
分析結果を以下の形式でレポートします：
# Gap分析レポート: {pj-name}
## 既存コードベース
### アーキテクチャ
- Monolithic Architecture
- Backend: Node.js + Express
- Frontend: React + Redux
- Database: PostgreSQL
### 既存API
- POST /api/session - セッション管理
- GET /api/profile - プロフィール取得
### 既存データモデル
- sessions テーブル
- profiles テーブル
## 新規実装との差分
### 新規追加
- POST /api/users - ユーザー登録
- POST /api/login - ログイン
- users テーブル
### 既存APIの変更
- なし
### 競合箇所
- 既存の sessions テーブルと新規の users テーブルの連携
## 統合ポイント
### インターフェース統合
- API Gateway: 既存エンドポイントと新規エンドポイントを統合
- フロントエンド: ログインページから新規ログインAPIを呼び出し
### データモデル統合
- sessions.user_id → users.id の外部キー追加
### ワークフロー統合
- 既存のセッション管理に新規のユーザー認証を組み込み
## 実装戦略
### Phase 1: 独立実装
- users テーブル作成
- POST /api/users, POST /api/login 実装
- 既存コードに影響なし
### Phase 2: API統合
- フロントエンドから新規ログインAPIを呼び出し
- Feature Flag で新旧ログインを切り替え
### Phase 3: データ統合
- sessions.user_id → users.id の外部キー追加
- 既存セッションデータを移行
### Phase 4: ワークフロー統合
- 既存のセッション管理に新規ユーザー認証を完全統合
- 旧ログインAPIを廃止
## リスク回避策
- Feature Flag: `use_new_auth` で新旧切り替え
- Blue-Green Deployment: 問題発生時は即座に切り戻し
- カナリアリリース: 5% → 25% → 50% → 100%
## ロールバック計画
1. Feature Flag で旧ログインに切り戻し
2. 外部キー制約を削除
3. 新規テーブルをドロップ（必要に応じて）次のステップ
Gap分析が完了したら、次のステップに進みます：
統合戦略に基づいてタスクを分割
/michi create-tasks {pj-name}段階的に実装
Phase 1から順番に実装し、各Phaseごとに検証します。
/michi dev {pj-name}参照
- アーキテクチャガイド:
docs/master-docs/structure.md - ワークフロー全体:
../references/workflow-guide.md - コマンドリファレンス:
../references/command-reference.md
関連スキル:
create-tasks- タスク分割（統合戦略に基づく）dev- TDD実装（段階的に実装）