Skip to content

Instantly share code, notes, and snippets.

@rz7d
Last active September 9, 2025 18:07
Show Gist options
  • Save rz7d/e6a79113ef58852582845c9f5ecc56a4 to your computer and use it in GitHub Desktop.
Save rz7d/e6a79113ef58852582845c9f5ecc56a4 to your computer and use it in GitHub Desktop.
rev 系プロンプトが便利だったので Codex CLI prompts/ 向けの classmethod/tsumiki quick and dirtyな移植 ※本家推奨 → https://github.com/classmethod/tsumiki

MIT License

Copyright (c) 2025 makotan

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

rev-design

目的

既存のコードベースから技術設計文書を逆生成する。実装されたアーキテクチャ、データフロー、API仕様、データベーススキーマ、TypeScriptインターフェースを分析し、設計書として文書化する。

前提条件

  • 分析対象のコードベースが存在する
  • docs/reverse/ ディレクトリが存在する(なければ作成)
  • 可能であれば事前に rev-tasks.md を実行済み

実行内容

  1. アーキテクチャの分析

    • プロジェクト構造からアーキテクチャパターンを特定
    • レイヤー構成の確認(MVC、Clean Architecture等)
    • マイクロサービス構成の有無
    • フロントエンド/バックエンドの分離状況
  2. データフローの抽出

    • ユーザーインタラクションの流れ
    • API呼び出しの流れ
    • データベースアクセスパターン
    • 状態管理の流れ
  3. API仕様の抽出

    • エンドポイント一覧の生成
    • リクエスト/レスポンス構造の分析
    • 認証・認可方式の確認
    • エラーレスポンス形式
  4. データベーススキーマの逆生成

    • テーブル定義の抽出
    • リレーションシップの分析
    • インデックス設定の確認
    • 制約条件の抽出
  5. TypeScript型定義の整理

    • エンティティ型の抽出
    • API型の抽出
    • 共通型の整理
    • 型の依存関係分析
  6. コンポーネント設計の分析

    • UIコンポーネント階層
    • Propsインターフェース
    • 状態管理の設計
    • ルーティング設計
  7. ファイルの作成

    • docs/reverse/{プロジェクト名}-architecture.md - アーキテクチャ概要
    • docs/reverse/{プロジェクト名}-dataflow.md - データフロー図
    • docs/reverse/{プロジェクト名}-api-specs.md - API仕様
    • docs/reverse/{プロジェクト名}-database.md - DB設計
    • docs/reverse/{プロジェクト名}-interfaces.ts - 型定義集約

出力フォーマット例

architecture.md

# {プロジェクト名} アーキテクチャ設計(逆生成)

## 分析日時
{実行日時}

## システム概要

### 実装されたアーキテクチャ
- **パターン**: {特定されたアーキテクチャパターン}
- **フレームワーク**: {使用フレームワーク}
- **構成**: {発見された構成}

### 技術スタック

#### フロントエンド
- **フレームワーク**: {React/Vue/Angular等}
- **状態管理**: {Redux/Zustand/Pinia等}
- **UI ライブラリ**: {Material-UI/Ant Design等}
- **スタイリング**: {CSS Modules/styled-components等}

#### バックエンド
- **フレームワーク**: {Express/NestJS/FastAPI等}
- **認証方式**: {JWT/Session/OAuth等}
- **ORM/データアクセス**: {TypeORM/Prisma/Sequelize等}
- **バリデーション**: {Joi/Yup/zod等}

#### データベース
- **DBMS**: {PostgreSQL/MySQL/MongoDB等}
- **キャッシュ**: {Redis/Memcached等 or なし}
- **接続プール**: {実装されているか}

#### インフラ・ツール
- **ビルドツール**: {Webpack/Vite/Rollup等}
- **テストフレームワーク**: {Jest/Vitest/Pytest等}
- **コード品質**: {ESLint/Prettier/SonarQube等}

## レイヤー構成

### 発見されたレイヤー

{実際のディレクトリ構造}


### レイヤー責務分析
- **プレゼンテーション層**: {実装状況}
- **アプリケーション層**: {実装状況}
- **ドメイン層**: {実装状況}
- **インフラストラクチャ層**: {実装状況}

## デザインパターン

### 発見されたパターン
- **Dependency Injection**: {実装されているか}
- **Repository Pattern**: {実装されているか}
- **Factory Pattern**: {使用箇所}
- **Observer Pattern**: {使用箇所}
- **Strategy Pattern**: {使用箇所}

## 非機能要件の実装状況

### セキュリティ
- **認証**: {実装方式}
- **認可**: {実装方式}
- **CORS設定**: {設定状況}
- **HTTPS対応**: {対応状況}

### パフォーマンス
- **キャッシュ**: {実装状況}
- **データベース最適化**: {インデックス等}
- **CDN**: {使用状況}
- **画像最適化**: {実装状況}

### 運用・監視
- **ログ出力**: {実装状況}
- **エラートラッキング**: {実装状況}
- **メトリクス収集**: {実装状況}
- **ヘルスチェック**: {実装状況}

dataflow.md

# データフロー図(逆生成)

## ユーザーインタラクションフロー

### 認証フロー
\`\`\`mermaid
sequenceDiagram
    participant U as ユーザー
    participant F as フロントエンド
    participant B as バックエンド
    participant D as データベース
    
    U->>F: ログイン情報入力
    F->>B: POST /auth/login
    B->>D: ユーザー検証
    D-->>B: ユーザー情報
    B-->>F: JWTトークン
    F-->>U: ログイン完了
\`\`\`

### データ取得フロー
\`\`\`mermaid
flowchart TD
    A[ユーザーアクション] --> B[Reactコンポーネント]
    B --> C[useQueryフック]
    C --> D[Axios HTTP Client]
    D --> E[API Gateway/Express]
    E --> F[コントローラー]
    F --> G[サービス層]
    G --> H[リポジトリ層]
    H --> I[データベース]
    I --> H
    H --> G
    G --> F
    F --> E
    E --> D
    D --> C
    C --> B
    B --> J[UI更新]
\`\`\`

## 状態管理フロー

### {使用されている状態管理ライブラリ} フロー
\`\`\`mermaid
flowchart LR
    A[コンポーネント] --> B[Action Dispatch]
    B --> C[Reducer/Store]
    C --> D[State更新]
    D --> A
\`\`\`

## エラーハンドリングフロー

\`\`\`mermaid
flowchart TD
    A[エラー発生] --> B{エラー種別}
    B -->|認証エラー| C[リダイレクト to ログイン]
    B -->|ネットワークエラー| D[リトライ機能]
    B -->|バリデーションエラー| E[フォームエラー表示]
    B -->|サーバーエラー| F[エラートースト表示]
\`\`\`

api-specs.md

# API仕様書(逆生成)

## ベースURL
\`{発見されたベースURL}\`

## 認証方式
{発見された認証方式の詳細}

## エンドポイント一覧

### 認証関連

#### POST /auth/login
**説明**: ユーザーログイン

**リクエスト**:
\`\`\`typescript
{
  email: string;
  password: string;
}
\`\`\`

**レスポンス**:
\`\`\`typescript
{
  success: boolean;
  data: {
    token: string;
    user: {
      id: string;
      email: string;
      name: string;
    }
  };
}
\`\`\`

**エラーレスポンス**:
\`\`\`typescript
{
  success: false;
  error: {
    code: string;
    message: string;
  }
}
\`\`\`

#### POST /auth/logout
**説明**: ユーザーログアウト

**ヘッダー**:
\`\`\`
Authorization: Bearer {token}
\`\`\`

### {その他のエンドポイント}

## エラーコード一覧

| コード | メッセージ | 説明 |
|--------|------------|------|
| AUTH_001 | Invalid credentials | 認証情報が無効 |
| AUTH_002 | Token expired | トークンが期限切れ |
| VALID_001 | Validation failed | バリデーションエラー |

## レスポンス共通形式

### 成功レスポンス
\`\`\`typescript
{
  success: true;
  data: T; // 型は endpoint によって変動
}
\`\`\`

### エラーレスポンス
\`\`\`typescript
{
  success: false;
  error: {
    code: string;
    message: string;
    details?: any;
  }
}
\`\`\`

database.md

# データベース設計(逆生成)

## スキーマ概要

### テーブル一覧
{発見されたテーブル一覧}

### ER図
\`\`\`mermaid
erDiagram
    USERS {
        uuid id PK
        varchar email UK
        varchar name
        timestamp created_at
        timestamp updated_at
    }
    
    POSTS {
        uuid id PK
        uuid user_id FK
        varchar title
        text content
        timestamp created_at
        timestamp updated_at
    }
    
    USERS ||--o{ POSTS : creates
\`\`\`

## テーブル詳細

### users テーブル
\`\`\`sql
{実際のCREATE TABLE文}
\`\`\`

**カラム説明**:
- \`id\`: {説明}
- \`email\`: {説明}
- \`name\`: {説明}

**インデックス**:
- \`idx_users_email\`: email カラムの検索用

### {その他のテーブル}

## 制約・関係性

### 外部キー制約
{発見された外部キー制約}

### ユニーク制約
{発見されたユニーク制約}

## データアクセスパターン

### よく使用されるクエリ
{コードから発見されたクエリパターン}

### パフォーマンス考慮事項
{発見されたインデックス戦略}

interfaces.ts

// ======================
// エンティティ型定義
// ======================

export interface User {
  id: string;
  email: string;
  name: string;
  createdAt: Date;
  updatedAt: Date;
}

export interface Post {
  id: string;
  userId: string;
  title: string;
  content: string;
  createdAt: Date;
  updatedAt: Date;
  user?: User;
}

// ======================
// API型定義
// ======================

export interface LoginRequest {
  email: string;
  password: string;
}

export interface LoginResponse {
  success: boolean;
  data: {
    token: string;
    user: User;
  };
}

export interface ApiResponse<T = any> {
  success: boolean;
  data?: T;
  error?: {
    code: string;
    message: string;
    details?: any;
  };
}

// ======================
// コンポーネントProps型
// ======================

export interface LoginFormProps {
  onSubmit: (data: LoginRequest) => void;
  loading?: boolean;
  error?: string;
}

// ======================
// 状態管理型
// ======================

export interface AuthState {
  user: User | null;
  token: string | null;
  isAuthenticated: boolean;
  loading: boolean;
}

// ======================
// 設定型
// ======================

export interface AppConfig {
  apiBaseUrl: string;
  tokenStorageKey: string;
  supportedLanguages: string[];
}

分析アルゴリズム

1. ファイル走査・パターンマッチング

  • AST解析による関数・クラス・インターフェース抽出
  • 正規表現による設定ファイル解析
  • ディレクトリ構造からのアーキテクチャ推定

2. API仕様の自動生成

  • Express/NestJS ルート定義の解析
  • FastAPI スキーマ定義の解析
  • TypeScript型定義からのリクエスト/レスポンス推定

3. データベーススキーマの抽出

  • マイグレーションファイルの解析
  • ORM モデル定義の解析
  • SQL ファイルの解析

実行コマンド例

# フル分析(全設計書生成)
echo "$(cat ~/.codex/prompts/rev-design.md)" | codex exec -

# 特定の設計書のみ生成
echo "$(cat ~/.codex/prompts/rev-design.md) --target architecture" | codex exec -
echo "$(cat ~/.codex/prompts/rev-design.md) --target api" | codex exec -
echo "$(cat ~/.codex/prompts/rev-design.md) --target database" | codex exec -

# 特定のディレクトリを分析
echo "$(cat ~/.codex/prompts/rev-design.md) --path ./backend" | codex exec -

# 出力形式指定
echo "$(cat ~/.codex/prompts/rev-design.md) --format markdown,openapi" | codex exec -

実行後の確認

  • 生成された設計書ファイルの一覧を表示
  • 抽出されたAPI数、テーブル数、型定義数等の統計情報を表示
  • 不足している設計要素や推奨改善点を提示
  • 次のリバースエンジニアリングステップ(要件定義生成等)を提案

rev-requirements

目的

既存のコードベースから要件定義書を逆生成する。実装された機能を分析し、EARS(Easy Approach to Requirements Syntax)記法を用いて機能要件、非機能要件、ユーザーストーリーを抽出・文書化する。

前提条件

  • 分析対象のコードベースが存在する
  • docs/reverse/ ディレクトリが存在する(なければ作成)
  • 可能であれば事前に rev-tasks.md および rev-design.md を実行済み

実行内容

  1. 機能の特定と分析

    • UI コンポーネントから画面機能を抽出
    • API エンドポイントからビジネス機能を特定
    • データベーススキーマからデータ要件を推定
    • テストコードから期待動作を確認
  2. ユーザーストーリーの逆算

    • 実装された機能からユーザーの意図を推定
    • WHO(ユーザー種別)の特定
    • WHAT(実現したいこと)の抽出
    • WHY(得られる価値)の推定
  3. EARS記法による要件分類

    • 通常要件(SHALL): 標準的な機能実装から抽出
    • 条件付き要件(WHEN/IF-THEN): 条件分岐ロジックから抽出
    • 状態要件(WHERE): 状態管理実装から抽出
    • オプション要件(MAY): 設定可能機能から抽出
    • 制約要件(MUST): バリデーション・制限ロジックから抽出
  4. 非機能要件の推定

    • パフォーマンス要件:実装されたキャッシュ、最適化から推定
    • セキュリティ要件:認証・認可実装から抽出
    • ユーザビリティ要件:UI/UX実装から抽出
    • 運用要件:ログ、監視実装から抽出
  5. Edgeケースの特定

    • エラーハンドリング実装から異常系要件を抽出
    • バリデーション実装から境界値要件を抽出
    • テストケースから想定されるエラーケースを抽出
  6. 受け入れ基準の生成

    • 実装されたテストから受け入れ基準を逆算
    • 未実装のテストケースを推奨事項として提示
  7. ファイルの作成

    • docs/reverse/{プロジェクト名}-requirements.md として保存

出力フォーマット例

# {プロジェクト名} 要件定義書(逆生成)

## 分析概要

**分析日時**: {実行日時}
**対象コードベース**: {パス}
**抽出要件数**: {機能要件数}個の機能要件、{非機能要件数}個の非機能要件
**信頼度**: {分析の信頼度} % (実装カバレッジに基づく)

## システム概要

### 推定されたシステム目的
{実装された機能から推測されるシステムの目的}

### 対象ユーザー
{UIコンポーネントや機能から推定されるユーザー種別}

## ユーザーストーリー

### ストーリー1: ユーザー認証
- **である** 未登録・既存ユーザー **として**
- **私は** システムに安全にログイン **をしたい**
- **そうすることで** 個人的な情報やサービスにアクセスできる

**実装根拠**: 
- `LoginForm.tsx` - ログインフォーム実装
- `POST /auth/login` - 認証API実装
- `useAuth` フック - 認証状態管理

### ストーリー2: {その他のストーリー}

{実装された機能から推定される追加のユーザーストーリー}

## 機能要件(EARS記法)

### 通常要件

#### REQ-001: ユーザー認証
システムは有効なメールアドレスとパスワードでのユーザーログインを提供しなければならない。

**実装根拠**: 
- `auth.service.ts:login()` メソッド
- `POST /auth/login` エンドポイント
- JWTトークン発行実装

#### REQ-002: セッション管理
システムはログイン後のユーザーセッションを管理しなければならない。

**実装根拠**:
- JWT トークンによるセッション管理
- `useAuth` フックでの状態管理
- ローカルストレージでのトークン永続化

### 条件付き要件

#### REQ-101: 認証失敗時の処理
無効な認証情報が提供された場合、システムは適切なエラーメッセージを表示しなければならない。

**実装根拠**:
- `auth.controller.ts` のエラーハンドリング
- `LoginForm.tsx` のエラー表示実装

#### REQ-102: トークン期限切れ時の処理
JWTトークンが期限切れの場合、システムはユーザーを再ログインページにリダイレクトしなければならない。

**実装根拠**:
- `axios.interceptors` での401エラーハンドリング
- 自動ログアウト機能の実装

### 状態要件

#### REQ-201: ログイン状態での表示
ユーザーがログイン状態にある場合、システムは認証済みユーザー向けのUIを表示しなければならない。

**実装根拠**:
- `useAuth` フックでの認証状態確認
- 認証状態による条件分岐レンダリング

### オプション要件

#### REQ-301: ログイン状態の記憶
システムはユーザーのログイン状態を記憶してもよい。

**実装根拠**:
- ローカルストレージでのトークン保存
- 自動ログイン機能の実装

### 制約要件

#### REQ-401: パスワード要件
システムはパスワードに最小8文字の制約を設けなければならない。

**実装根拠**:
- フロントエンドバリデーション実装
- `yup` スキーマでの制約定義

#### REQ-402: レート制限
システムはログイン試行に対してレート制限を設けなければならない。

**実装根拠**:
- `express-rate-limit` ミドルウェアの実装

## 非機能要件

### パフォーマンス

#### NFR-001: ログイン応答時間
システムは通常のログイン処理を2秒以内に完了しなければならない。

**実装根拠**:
- データベースインデックス設定
- 効率的なクエリ実装

#### NFR-002: 同時ユーザー数
システムは同時に100ユーザーのアクセスを処理できなければならない。

**推定根拠**:
- 接続プール設定
- サーバー構成

### セキュリティ

#### NFR-101: 認証トークン暗号化
システムはJWTトークンを適切に暗号化しなければならない。

**実装根拠**:
- `jsonwebtoken` ライブラリの使用
- 秘密鍵による署名実装

#### NFR-102: HTTPS通信
システムは本番環境でHTTPS通信を強制しなければならない。

**実装根拠**:
- SSL設定ファイル
- HTTPS リダイレクト実装

### ユーザビリティ

#### NFR-201: レスポンシブデザイン
システムはモバイルデバイスでも利用可能でなければならない。

**実装根拠**:
- CSS メディアクエリの実装
- レスポンシブUIコンポーネント

#### NFR-202: アクセシビリティ
システムは基本的なアクセシビリティ要件を満たさなければならない。

**実装根拠**:
- ARIA属性の使用
- セマンティックHTML構造

### 運用性

#### NFR-301: ログ出力
システムは重要な操作をログに記録しなければならない。

**実装根拠**:
- `winston` ログライブラリの使用
- 構造化ログの実装

#### NFR-302: エラー追跡
システムは発生したエラーを追跡可能でなければならない。

**実装根拠**:
- エラーハンドリング実装
- ログ出力による追跡機能

## Edgeケース

### エラー処理

#### EDGE-001: ネットワーク障害
ネットワーク接続が不安定な場合のリトライ処理

**実装根拠**:
- `axios` のリトライ設定
- エラートースト表示

#### EDGE-002: サーバーダウン
バックエンドサーバーが利用できない場合の処理

**実装根拠**:
- フォールバック機能
- エラーページ表示

### 境界値

#### EDGE-101: 最大文字数制限
入力フィールドの最大文字数制限

**実装根拠**:
- フォームバリデーション実装
- データベース制約

#### EDGE-102: 空文字・null値処理
空文字やnull値に対する適切な処理

**実装根拠**:
- バリデーション実装
- デフォルト値設定

## 受け入れ基準

### 実装済み機能テスト

- [x] ユーザーログイン機能
  - [x] 有効な認証情報でのログイン成功
  - [x] 無効な認証情報でのログイン失敗
  - [x] エラーメッセージの適切な表示
- [x] セッション管理機能
  - [x] ログイン状態の維持
  - [x] ログアウト機能
  - [x] トークン期限切れ処理

### 推奨追加テスト

- [ ] **パフォーマンステスト**
  - [ ] ログイン応答時間測定
  - [ ] 同時アクセス負荷テスト
- [ ] **セキュリティテスト**
  - [ ] SQLインジェクション対策テスト
  - [ ] XSS対策テスト
  - [ ] CSRF対策テスト
- [ ] **アクセシビリティテスト**
  - [ ] スクリーンリーダー対応テスト
  - [ ] キーボード操作テスト

## 推定されていない要件

### 不明確な部分

以下の要件は実装から推定が困難なため、ステークホルダーとの確認が必要:

1. **ビジネス要件**
   - システムの使用目的の詳細
   - 対象ユーザーの詳細な属性
   - 収益モデルや事業目標

2. **運用要件**
   - バックアップ・復旧要件
   - SLA(サービスレベル合意)
   - 監視・アラート要件

3. **法的・コンプライアンス要件**
   - データ保護規則への準拠
   - 業界固有の規制要件

### 推奨される次ステップ

1. **ステークホルダーインタビュー** - 推定された要件の確認
2. **ユーザビリティテスト** - 実際のユーザビリティ要件の確認
3. **パフォーマンステスト** - 非機能要件の検証
4. **セキュリティ監査** - セキュリティ要件の詳細検証

## 分析の制約事項

### 信頼度に影響する要因

- **コメント不足**: 開発者の意図を推定で補完
- **テストカバレッジ**: {%}% - 未テスト部分の要件は推定
- **ドキュメント不足**: 外部仕様書が存在しない
- **レガシーコード**: 古い実装パターンによる推定の難しさ

### 推定の根拠

- **強い根拠**: 実装 + テスト + 明確な動作
- **中程度の根拠**: 実装 + 部分的テスト
- **弱い根拠**: 実装のみ、推定で補完

要件抽出アルゴリズム

1. 機能要件の抽出プロセス

1. APIエンドポイント → ビジネス機能要件
2. UIコンポーネント → ユーザーインターフェース要件
3. データベーススキーマ → データ要件
4. バリデーション実装 → 制約要件
5. 条件分岐 → 条件付き要件

2. 非機能要件の推定プロセス

1. 設定ファイル + ライブラリ → パフォーマンス・セキュリティ要件
2. UI実装パターン → ユーザビリティ要件
3. ログ・監視実装 → 運用要件
4. テスト実装 → 品質要件

3. ユーザーストーリーの逆算プロセス

1. 画面遷移フロー → ユーザージャーニー
2. フォーム・入力項目 → ユーザーアクション
3. データの CRUD操作 → ユーザーニーズ
4. 権限・ロール実装 → ユーザー種別

実行コマンド例

# フル分析(全要件抽出)
echo "$(cat ~/.codex/prompts/rev-requirements.md)" | codex exec -

# 特定の要件カテゴリのみ抽出
echo "$(cat ~/.codex/prompts/rev-requirements.md) --target functional" | codex exec -
echo "$(cat ~/.codex/prompts/rev-requirements.md) --target non-functional" | codex exec -
echo "$(cat ~/.codex/prompts/rev-requirements.md) --target user-stories" | codex exec -

# 信頼度フィルタ
echo "$(cat ~/.codex/prompts/rev-requirements.md) --confidence high" | codex exec -
echo "$(cat ~/.codex/prompts/rev-requirements.md) --confidence medium" | codex exec -

# 特定のディレクトリを分析
echo "$(cat ~/.codex/prompts/rev-requirements.md) --path ./src" | codex exec -

# 出力形式指定
echo "$(cat ~/.codex/prompts/rev-requirements.md) --format markdown,json" | codex exec -

実行後の確認

  • 抽出された要件数(機能要件・非機能要件)を表示
  • 分析の信頼度と根拠の強さを報告
  • 推定が困難な要件や確認が必要な項目を提示
  • ステークホルダー確認のための質問リストを生成
  • 次の推奨アクション(テスト追加、ドキュメント整備等)を提案

rev-specs

目的

既存のコードベースから包括的なテストケースと仕様書を逆生成する。実装されたビジネスロジック、API動作、UI コンポーネントの動作を分析し、不足しているテストケースを特定・生成し、仕様書として文書化する。

前提条件

  • 分析対象のコードベースが存在する
  • docs/reverse/ ディレクトリが存在する(なければ作成)
  • 可能であれば事前に rev-requirements.md, rev-design.md を実行済み

実行内容

  1. 既存テストの分析

    • 単体テスト(Unit Test)の実装状況確認
    • 統合テスト(Integration Test)の実装状況確認
    • E2Eテスト(End-to-End Test)の実装状況確認
    • テストカバレッジの測定
  2. 実装コードからテストケースの逆生成

    • 関数・メソッドの引数・戻り値からのテストケース生成
    • 条件分岐からの境界値テスト生成
    • エラーハンドリングからの異常系テスト生成
    • データベース操作からのデータテスト生成
  3. API仕様からテストケースの生成

    • 各エンドポイントの正常系テスト
    • 認証・認可テスト
    • バリデーションエラーテスト
    • HTTPステータスコードテスト
  4. UI コンポーネントからテストケースの生成

    • コンポーネントレンダリングテスト
    • ユーザーインタラクションテスト
    • 状態変更テスト
    • プロパティ変更テスト
  5. パフォーマンス・セキュリティテストケースの生成

    • 負荷テストシナリオ
    • セキュリティ脆弱性テスト
    • レスポンス時間テスト
  6. テスト仕様書の生成

    • テスト計画書
    • テストケース一覧
    • テスト環境仕様
    • テスト手順書
  7. ファイルの作成

    • docs/reverse/{プロジェクト名}-test-specs.md - テスト仕様書
    • docs/reverse/{プロジェクト名}-test-cases.md - テストケース一覧
    • docs/reverse/tests/ - 生成されたテストコード

出力フォーマット例

test-specs.md

# {プロジェクト名} テスト仕様書(逆生成)

## 分析概要

**分析日時**: {実行日時}
**対象コードベース**: {パス}
**テストカバレッジ**: {現在のカバレッジ}%
**生成テストケース数**: {生成数}個
**実装推奨テスト数**: {推奨数}個

## 現在のテスト実装状況

### テストフレームワーク
- **単体テスト**: {Jest/Vitest/pytest等}
- **統合テスト**: {Supertest/TestContainers等}
- **E2Eテスト**: {Cypress/Playwright等}
- **コードカバレッジ**: {istanbul/c8等}

### テストカバレッジ詳細

| ファイル/ディレクトリ | 行カバレッジ | 分岐カバレッジ | 関数カバレッジ |
|---------------------|-------------|-------------|-------------|
| src/auth/ | 85% | 75% | 90% |
| src/users/ | 60% | 45% | 70% |
| src/components/ | 40% | 30% | 50% |
| **全体** | **65%** | **55%** | **75%** |

### テストカテゴリ別実装状況

#### 単体テスト
- [x] **認証サービス**: auth.service.spec.ts
- [x] **ユーザーサービス**: user.service.spec.ts
- [ ] **データ変換ユーティリティ**: 未実装
- [ ] **バリデーションヘルパー**: 未実装

#### 統合テスト
- [x] **認証API**: auth.controller.spec.ts
- [ ] **ユーザー管理API**: 未実装
- [ ] **データベース操作**: 未実装

#### E2Eテスト
- [ ] **ユーザーログインフロー**: 未実装
- [ ] **データ操作フロー**: 未実装
- [ ] **エラーハンドリング**: 未実装

## 生成されたテストケース

### API テストケース

#### POST /auth/login - ログイン認証

**正常系テスト**
```typescript
describe('POST /auth/login', () => {
  it('有効な認証情報でログイン成功', async () => {
    const response = await request(app)
      .post('/auth/login')
      .send({
        email: '[email protected]',
        password: 'password123'
      });
    
    expect(response.status).toBe(200);
    expect(response.body.success).toBe(true);
    expect(response.body.data.token).toBeDefined();
    expect(response.body.data.user.email).toBe('[email protected]');
  });

  it('JWTトークンが正しい形式で返される', async () => {
    const response = await request(app)
      .post('/auth/login')
      .send(validCredentials);
    
    const token = response.body.data.token;
    expect(token).toMatch(/^[A-Za-z0-9-_]+\.[A-Za-z0-9-_]+\.[A-Za-z0-9-_]+$/);
  });
});

異常系テスト

describe('POST /auth/login - 異常系', () => {
  it('無効なメールアドレスでエラー', async () => {
    const response = await request(app)
      .post('/auth/login')
      .send({
        email: 'invalid-email',
        password: 'password123'
      });
    
    expect(response.status).toBe(400);
    expect(response.body.success).toBe(false);
    expect(response.body.error.code).toBe('VALIDATION_ERROR');
  });

  it('存在しないユーザーでエラー', async () => {
    const response = await request(app)
      .post('/auth/login')
      .send({
        email: '[email protected]',
        password: 'password123'
      });
    
    expect(response.status).toBe(401);
    expect(response.body.error.code).toBe('INVALID_CREDENTIALS');
  });

  it('パスワード間違いでエラー', async () => {
    const response = await request(app)
      .post('/auth/login')
      .send({
        email: '[email protected]',
        password: 'wrongpassword'
      });
    
    expect(response.status).toBe(401);
    expect(response.body.error.code).toBe('INVALID_CREDENTIALS');
  });
});

境界値テスト

describe('POST /auth/login - 境界値', () => {
  it('最小文字数パスワードでテスト', async () => {
    // 8文字(最小要件)
    const response = await request(app)
      .post('/auth/login')
      .send({
        email: '[email protected]',
        password: '12345678'
      });
    
    expect(response.status).toBe(200);
  });

  it('最大文字数メールアドレスでテスト', async () => {
    // 255文字(最大要件)
    const longEmail = 'a'.repeat(243) + '@example.com';
    const response = await request(app)
      .post('/auth/login')
      .send({
        email: longEmail,
        password: 'password123'
      });
    
    expect(response.status).toBe(400);
  });
});

UIコンポーネントテストケース

LoginForm コンポーネント

レンダリングテスト

import { render, screen } from '@testing-library/react';
import { LoginForm } from './LoginForm';

describe('LoginForm', () => {
  it('必要な要素が表示される', () => {
    render(<LoginForm onSubmit={jest.fn()} />);
    
    expect(screen.getByLabelText('メールアドレス')).toBeInTheDocument();
    expect(screen.getByLabelText('パスワード')).toBeInTheDocument();
    expect(screen.getByRole('button', { name: 'ログイン' })).toBeInTheDocument();
  });

  it('初期状態でエラーメッセージが非表示', () => {
    render(<LoginForm onSubmit={jest.fn()} />);
    
    expect(screen.queryByText(//)).not.toBeInTheDocument();
  });
});

ユーザーインタラクションテスト

import { render, screen, fireEvent, waitFor } from '@testing-library/react';
import userEvent from '@testing-library/user-event';

describe('LoginForm - ユーザーインタラクション', () => {
  it('フォーム送信時にonSubmitが呼ばれる', async () => {
    const mockSubmit = jest.fn();
    render(<LoginForm onSubmit={mockSubmit} />);
    
    await userEvent.type(screen.getByLabelText('メールアドレス'), '[email protected]');
    await userEvent.type(screen.getByLabelText('パスワード'), 'password123');
    await userEvent.click(screen.getByRole('button', { name: 'ログイン' }));
    
    expect(mockSubmit).toHaveBeenCalledWith({
      email: '[email protected]',
      password: 'password123'
    });
  });

  it('バリデーションエラー時に送信されない', async () => {
    const mockSubmit = jest.fn();
    render(<LoginForm onSubmit={mockSubmit} />);
    
    await userEvent.click(screen.getByRole('button', { name: 'ログイン' }));
    
    expect(mockSubmit).not.toHaveBeenCalled();
    expect(screen.getByText('メールアドレスは必須です')).toBeInTheDocument();
  });
});

サービス層テストケース

AuthService 単体テスト

import { AuthService } from './auth.service';
import { UserRepository } from './user.repository';

jest.mock('./user.repository');

describe('AuthService', () => {
  let authService: AuthService;
  let mockUserRepository: jest.Mocked<UserRepository>;

  beforeEach(() => {
    mockUserRepository = new UserRepository() as jest.Mocked<UserRepository>;
    authService = new AuthService(mockUserRepository);
  });

  describe('login', () => {
    it('有効な認証情報でユーザー情報とトークンを返す', async () => {
      const mockUser = {
        id: '1',
        email: '[email protected]',
        hashedPassword: 'hashed_password'
      };
      
      mockUserRepository.findByEmail.mockResolvedValue(mockUser);
      jest.spyOn(authService, 'verifyPassword').mockResolvedValue(true);
      jest.spyOn(authService, 'generateToken').mockReturnValue('mock_token');

      const result = await authService.login('[email protected]', 'password');

      expect(result).toEqual({
        user: { id: '1', email: '[email protected]' },
        token: 'mock_token'
      });
    });

    it('存在しないユーザーでエラーをスロー', async () => {
      mockUserRepository.findByEmail.mockResolvedValue(null);

      await expect(
        authService.login('[email protected]', 'password')
      ).rejects.toThrow('Invalid credentials');
    });
  });
});

パフォーマンステストケース

負荷テスト

describe('パフォーマンステスト', () => {
  it('ログインAPI - 100同時接続テスト', async () => {
    const promises = Array.from({ length: 100 }, () =>
      request(app).post('/auth/login').send(validCredentials)
    );

    const startTime = Date.now();
    const responses = await Promise.all(promises);
    const endTime = Date.now();

    // 全てのリクエストが成功
    responses.forEach(response => {
      expect(response.status).toBe(200);
    });

    // 応答時間が5秒以内
    expect(endTime - startTime).toBeLessThan(5000);
  });

  it('データベース - 大量データ検索性能', async () => {
    // 1000件のテストデータを作成
    await createTestData(1000);

    const startTime = Date.now();
    const response = await request(app)
      .get('/users')
      .query({ limit: 100, offset: 0 });
    const endTime = Date.now();

    expect(response.status).toBe(200);
    expect(endTime - startTime).toBeLessThan(1000); // 1秒以内
  });
});

セキュリティテスト

describe('セキュリティテスト', () => {
  it('SQLインジェクション対策', async () => {
    const maliciousInput = "'; DROP TABLE users; --";
    
    const response = await request(app)
      .post('/auth/login')
      .send({
        email: maliciousInput,
        password: 'password'
      });

    // システムが正常に動作し、データベースが破損していない
    expect(response.status).toBe(400);
    
    // ユーザーテーブルが依然として存在することを確認
    const usersResponse = await request(app)
      .get('/users')
      .set('Authorization', 'Bearer ' + validToken);
    expect(usersResponse.status).not.toBe(500);
  });

  it('XSS対策', async () => {
    const xssPayload = '<script>alert("XSS")</script>';
    
    const response = await request(app)
      .post('/users')
      .set('Authorization', 'Bearer ' + validToken)
      .send({
        name: xssPayload,
        email: '[email protected]'
      });

    // レスポンスでスクリプトがエスケープされている
    expect(response.body.data.name).not.toContain('<script>');
    expect(response.body.data.name).toContain('&lt;script&gt;');
  });
});

E2Eテストケース

Playwright/Cypress テストシナリオ

// ユーザーログインフロー E2Eテスト
describe('ユーザーログインフロー', () => {
  it('正常なログインからダッシュボード表示まで', async () => {
    await page.goto('/login');
    
    // ログインフォーム入力
    await page.fill('[data-testid="email-input"]', '[email protected]');
    await page.fill('[data-testid="password-input"]', 'password123');
    await page.click('[data-testid="login-button"]');
    
    // ダッシュボードへリダイレクト
    await page.waitForURL('/dashboard');
    
    // ユーザー情報表示確認
    await expect(page.locator('[data-testid="user-name"]')).toContainText('テストユーザー');
    
    // ログアウト機能確認
    await page.click('[data-testid="logout-button"]');
    await page.waitForURL('/login');
  });

  it('ログイン失敗時のエラー表示', async () => {
    await page.goto('/login');
    
    await page.fill('[data-testid="email-input"]', '[email protected]');
    await page.fill('[data-testid="password-input"]', 'wrongpassword');
    await page.click('[data-testid="login-button"]');
    
    // エラーメッセージ表示確認
    await expect(page.locator('[data-testid="error-message"]'))
      .toContainText('認証情報が正しくありません');
  });
});

テスト環境設定

データベーステスト設定

// テスト用データベース設定
beforeAll(async () => {
  // テスト用データベース接続
  await setupTestDatabase();
  
  // マイグレーション実行
  await runMigrations();
});

beforeEach(async () => {
  // 各テスト前にデータをクリーンアップ
  await cleanupDatabase();
  
  // 基本テストデータ投入
  await seedTestData();
});

afterAll(async () => {
  // テスト用データベース切断
  await teardownTestDatabase();
});

モック設定

// 外部サービスのモック
jest.mock('./email.service', () => ({
  EmailService: jest.fn().mockImplementation(() => ({
    sendEmail: jest.fn().mockResolvedValue(true)
  }))
}));

// 環境変数のモック
process.env.JWT_SECRET = 'test-secret';
process.env.NODE_ENV = 'test';

不足テストの優先順位

高優先度(即座に実装推奨)

  1. E2Eテストスイート - ユーザーフロー全体の動作保証
  2. API統合テスト - バックエンドAPI全体のテスト
  3. セキュリティテスト - 脆弱性対策の検証

中優先度(次のスプリントで実装)

  1. パフォーマンステスト - 負荷・応答時間テスト
  2. UIコンポーネントテスト - フロントエンド動作保証
  3. データベーステスト - データ整合性テスト

低優先度(継続的改善として実装)

  1. ブラウザ互換性テスト - 複数ブラウザでの動作確認
  2. アクセシビリティテスト - a11y対応確認
  3. 国際化テスト - 多言語対応確認

### test-cases.md

```markdown
# {プロジェクト名} テストケース一覧(逆生成)

## テストケース概要

| ID | テスト名 | カテゴリ | 優先度 | 実装状況 | 推定工数 |
|----|----------|----------|--------|----------|----------|
| TC-001 | ログイン正常系 | API | 高 | ✅ | 2h |
| TC-002 | ログイン異常系 | API | 高 | ✅ | 3h |
| TC-003 | E2Eログインフロー | E2E | 高 | ❌ | 4h |
| TC-004 | パフォーマンス負荷テスト | パフォーマンス | 中 | ❌ | 6h |

## 詳細テストケース

### TC-001: ログインAPI正常系テスト

**テスト目的**: 有効な認証情報でのログイン機能を検証

**事前条件**:
- テストユーザーがデータベースに存在する
- パスワードが正しくハッシュ化されている

**テスト手順**:
1. POST /auth/login にリクエスト送信
2. 有効なemail, passwordを含むJSONを送信
3. レスポンスを確認

**期待結果**:
- HTTPステータス: 200
- success: true
- data.token: JWT形式のトークン
- data.user: ユーザー情報

**実装ファイル**: `auth.controller.spec.ts`

### TC-002: ログインAPI異常系テスト

**テスト目的**: 無効な認証情報での適切なエラーハンドリングを検証

**テストケース**:
1. 存在しないメールアドレス
2. 無効なパスワード
3. 不正なメール形式
4. 空文字・null値
5. SQLインジェクション攻撃

**期待結果**:
- 適切なHTTPステータスコード
- 統一されたエラーレスポンス形式
- セキュリティ脆弱性がない

**実装状況**: ✅ 部分的実装

テストコード生成アルゴリズム

1. 静的解析によるテストケース抽出

1. 関数シグネチャ解析 → 引数・戻り値のテストケース
2. 条件分岐解析 → 分岐網羅テストケース
3. 例外処理解析 → 異常系テストケース
4. データベースアクセス解析 → データテストケース

2. 動的解析によるテスト生成

1. API呼び出しログ → 実際の使用パターンテスト
2. ユーザー操作ログ → E2Eテストシナリオ
3. パフォーマンスログ → 負荷テストシナリオ

3. テストカバレッジギャップ分析

1. 現在のカバレッジ測定
2. 未テスト行・分岐の特定
3. クリティカルパスの特定
4. リスクベース優先順位付け

実行コマンド例

# フル分析(全テストケース生成)
echo "$(cat ~/.codex/prompts/rev-specs.md)" | codex exec -

# 特定のテストカテゴリのみ生成
echo "$(cat ~/.codex/prompts/rev-specs.md) --type unit" | codex exec -
echo "$(cat ~/.codex/prompts/rev-specs.md) --type integration" | codex exec -
echo "$(cat ~/.codex/prompts/rev-specs.md) --type e2e" | codex exec -

# 特定のファイル/ディレクトリを対象
echo "$(cat ~/.codex/prompts/rev-specs.md) --path ./src/auth" | codex exec -

# テストコードの実際の生成と出力
echo "$(cat ~/.codex/prompts/rev-specs.md) --generate-code" | codex exec -

# カバレッジレポートと合わせて分析
echo "$(cat ~/.codex/prompts/rev-specs.md) --with-coverage" | codex exec -

# 優先度フィルタリング
echo "$(cat ~/.codex/prompts/rev-specs.md) --priority high" | codex exec -

実行後の確認

  • 現在のテストカバレッジと不足部分の詳細レポート表示
  • 生成されたテストケース数と推定実装工数を表示
  • 優先順位付けされた実装推奨リストを提示
  • テスト環境の設定要件と推奨ツールを提案
  • CI/CD パイプラインへの統合案を提示

rev-tasks

目的

既存のコードベースを分析し、実装されている機能を特定してタスク一覧として整理する。実装済みの機能から逆算してタスクの構造、依存関係、実装詳細を抽出し、文書化する。

前提条件

  • 分析対象のコードベースが存在する
  • docs/reverse/ ディレクトリが存在する(なければ作成)
  • TypeScript/JavaScript、Python、その他のコードを分析可能

実行内容

  1. コードベースの構造分析

    • ディレクトリ構造の把握
    • 設定ファイルの確認(package.json、tsconfig.json、requirements.txt等)
    • 依存関係の分析
  2. 機能コンポーネントの特定

    • フロントエンドコンポーネント
    • バックエンドサービス/コントローラー
    • データベース関連(モデル、マイグレーション)
    • ユーティリティ関数
    • ミドルウェア
  3. API エンドポイントの抽出

    • REST API エンドポイント
    • GraphQL リゾルバー
    • WebSocket ハンドラー
    • ルーティング定義
  4. データベース構造の分析

    • テーブル定義
    • リレーションシップ
    • マイグレーションファイル
    • インデックス設定
  5. UI/UX実装の分析

    • 画面コンポーネント
    • 状態管理の実装
    • ルーティング
    • スタイリング手法
  6. テスト実装の確認

    • 単体テストの存在
    • 統合テストの存在
    • E2Eテストの存在
    • テストカバレッジ
  7. タスクの逆算と整理

    • 実装された機能をタスクとして分解
    • タスクIDの自動割り当て
    • 依存関係の推定
    • 実装工数の推定
  8. ファイルの作成

    • docs/reverse/{プロジェクト名}-discovered-tasks.md として保存
    • 発見されたタスクを構造化して文書化

出力フォーマット例

# {プロジェクト名} 発見タスク一覧

## 概要

**分析日時**: {分析実行日時}
**対象コードベース**: {パス}
**発見タスク数**: {数}
**推定総工数**: {時間}

## コードベース構造

### プロジェクト情報
- **フレームワーク**: {使用フレームワーク}
- **言語**: {使用言語}
- **データベース**: {使用DB}
- **主要ライブラリ**: {主要な依存関係}

### ディレクトリ構造
```
{ディレクトリツリー}
```

## 発見されたタスク

### 基盤・設定タスク

#### DISCOVERED-001: プロジェクト初期設定

- [x] **タスク完了** (実装済み)
- **タスクタイプ**: DIRECT
- **実装ファイル**: 
  - `package.json`
  - `tsconfig.json`
  - `.env.example`
- **実装詳細**:
  - {発見された設定内容}
- **推定工数**: {時間}

#### DISCOVERED-002: データベース設定

- [x] **タスク完了** (実装済み)
- **タスクタイプ**: DIRECT
- **実装ファイル**: 
  - `src/database/connection.ts`
  - `migrations/001_initial.sql`
- **実装詳細**:
  - {発見されたDB設定内容}
- **推定工数**: {時間}

### API実装タスク

#### DISCOVERED-101: ユーザー認証API

- [x] **タスク完了** (実装済み)
- **タスクタイプ**: TDD
- **実装ファイル**: 
  - `src/auth/auth.controller.ts`
  - `src/auth/auth.service.ts`
  - `src/auth/jwt.strategy.ts`
- **実装詳細**:
  - ログイン/ログアウト機能
  - JWT トークン発行
  - 認証ミドルウェア
- **APIエンドポイント**:
  - `POST /auth/login`
  - `POST /auth/logout`
  - `POST /auth/refresh`
- **テスト実装状況**:
  - [x] 単体テスト: `auth.service.spec.ts`
  - [x] 統合テスト: `auth.controller.spec.ts`
  - [ ] E2Eテスト: 未実装
- **推定工数**: {時間}

### UI実装タスク

#### DISCOVERED-201: ログイン画面

- [x] **タスク完了** (実装済み)
- **タスクタイプ**: TDD
- **実装ファイル**: 
  - `src/components/Login/LoginForm.tsx`
  - `src/components/Login/LoginForm.module.css`
  - `src/hooks/useAuth.ts`
- **実装詳細**:
  - ログインフォーム
  - バリデーション機能
  - エラーハンドリング
- **UI/UX実装状況**:
  - [x] レスポンシブデザイン
  - [x] ローディング状態
  - [x] エラー表示
  - [ ] アクセシビリティ: 部分的実装
- **テスト実装状況**:
  - [x] コンポーネントテスト: `LoginForm.test.tsx`
  - [ ] E2Eテスト: 未実装
- **推定工数**: {時間}

## 未実装・改善推奨事項

### 不足しているテスト

- [ ] **E2Eテストスイート**: 主要ユーザーフローのテスト
- [ ] **パフォーマンステスト**: API応答時間テスト
- [ ] **セキュリティテスト**: 認証・認可テスト

### コード品質改善

- [ ] **TypeScript型安全性**: 一部でany型の使用
- [ ] **エラーハンドリング**: 統一的なエラー処理
- [ ] **ログ出力**: 構造化ログの実装

### ドキュメント不足

- [ ] **API仕様書**: OpenAPI/Swagger未実装
- [ ] **開発者ガイド**: セットアップ手順書
- [ ] **デプロイ手順書**: 本番環境構築手順

## 依存関係マップ

```mermaid
graph TD
    A[DISCOVERED-001: プロジェクト初期設定] --> B[DISCOVERED-002: データベース設定]
    B --> C[DISCOVERED-101: ユーザー認証API]
    C --> D[DISCOVERED-201: ログイン画面]
    D --> E[未実装: E2Eテスト]
    
    F[未実装: API仕様書] --> G[未実装: 開発者ガイド]
```

## 実装パターン分析

### アーキテクチャパターン
- **実装パターン**: {発見されたパターン}
- **状態管理**: {使用されている状態管理}
- **認証方式**: {実装されている認証方式}

### コーディングスタイル
- **命名規則**: {発見された命名規則}
- **ファイル構成**: {ファイル構成パターン}
- **エラーハンドリング**: {エラー処理パターン}

## 技術的負債・改善点

### パフォーマンス
- {発見されたパフォーマンス課題}

### セキュリティ
- {発見されたセキュリティ課題}

### 保守性
- {発見された保守性課題}

## 推奨次ステップ

1. **不足テストの実装** - 特にE2Eテストスイート
2. **ドキュメント整備** - API仕様書とセットアップガイド
3. **コード品質改善** - TypeScript型安全性とエラーハンドリング
4. **セキュリティ強化** - 認証・認可の詳細レビュー

分析対象ファイルの自動検出

フロントエンド

  • React: *.tsx, *.jsx, *.ts, *.js
  • Vue: *.vue, *.ts, *.js
  • Angular: *.component.ts, *.service.ts, *.module.ts

バックエンド

  • Node.js: *.ts, *.js (Express, NestJS等)
  • Python: *.py (Django, FastAPI等)
  • Java: *.java (Spring Boot等)

データベース

  • SQL: *.sql, migrations/*
  • ORM: モデルファイル、設定ファイル

設定ファイル

  • package.json, tsconfig.json, webpack.config.js
  • requirements.txt, Pipfile, pyproject.toml
  • pom.xml, build.gradle

実行コマンド例

# カレントディレクトリを分析
echo "$(cat ~/.codex/prompts/rev-tasks.md)" | codex exec -

# 特定ディレクトリを分析
echo "$(cat ~/.codex/prompts/rev-tasks.md) --path ./backend" | codex exec -

# 特定の技術スタックに絞って分析
echo "$(cat ~/.codex/prompts/rev-tasks.md) --tech react,nodejs" | codex exec -

# 詳細分析(テストカバレッジ等も含む)
echo "$(cat ~/.codex/prompts/rev-tasks.md) --detailed" | codex exec -

# 出力形式指定
echo "$(cat ~/.codex/prompts/rev-tasks.md) --format json" | codex exec -

実行後の確認

  • 発見されたタスク数と推定工数を表示
  • 実装済み/未実装の機能一覧を表示
  • 技術的負債・改善推奨事項をサマリー表示
  • 次のリバースエンジニアリングステップ(設計書生成等)を提案
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment