wuyining0130/c-room

目的

技術方案ができたら、次はコードを書く番です。従来のやり方では、開発者が自分で技術方案を読み、既存のコードを調べ、ファイルを一つずつ書いていきます。問題は、技術方案の中でインターフェース設計、DDL、変更範囲、タスク分割がすでに明確になっているにもかかわらず、開発者がこれらの情報を手動でコードに翻訳しなければならないことです。このプロセスは非常に繰り返しが多く、エラーが発生しやすいです（パラメータ名の typo、インターフェースパスの不一致、あるサービスの変更漏れなど）。

この skill は、技術方案、PRD、プロトタイプ、コーディング知識ベースを読み込み、技術方案のタスク分割に従って、対象リポジトリに直接コードファイルを生成/修正します。「スキャフォールド」や「テンプレートコード」を生成するのではなく、完全なビジネスロジックを含む実装コードを生成し、すぐに CR に提出できます。

中核となる能力は coding-knowledge の深い活用にあります。コーディング知識ベースのシンボルインデックス、コールチェーン、DDL、コーディング規約を通じて、生成されたコードは命名スタイル、レイヤー構造、例外処理方法においてプロジェクトの既存コードと一貫性を持ちます。つまり、プロジェクトの古参メンバーが書いたように見え、外注先が納品したようには見えません。

入力

• requirements/{モジュール名}/tech-design.md（主な入力。インターフェース設計、DDL、タスク分割、変更範囲を含む）
• requirements/{モジュール名}/prd-draft.md（受け入れ基準、ビジネスルール、境界条件）
• requirements/{モジュール名}/prototype/（フロントエンドページ構造の参考）
• coding-knowledge/（中核的な参考資料——コードスタイル、アーキテクチャパターン、シンボルインデックス、コールチェーン、DDL パターン、コーディング規約）
• 対象コードリポジトリのパス（ユーザーが指定、または tech-design の変更範囲から抽出）

ワークフロー

Phase 0: 入力の読み込み、コンテキストの構築

0.1 tech-design.md の読み込み

以下の情報を抽出し、後続の生成の信頼できるソースとします。

• 変更影響範囲（どのリポジトリが関係するか、どのファイルを新規追加/修正する必要があるか）
• インターフェース設計（API 一覧、リクエストパラメータ、レスポンス構造、エラーコード）
• データベース変更（DDL）
• 開発タスク分割（T-01, T-02... 依存関係を含む）
• インタラクションシーケンス図（サービス間の呼び出し関係）
• 再利用インターフェースのパラメータ説明（パラメータと動作の違いを区別）

0.2 prd-draft.md の読み込み

以下の情報を抽出し、ビジネスロジックの完全性を確保します。

• 機能一覧と受け入れ基準（生成されたコードがすべての機能ポイントをカバーしていることを確認）
• ビジネスルールと境界条件（コードに対応するバリデーションロジックがあることを確認）
• エラー処理要件（具体的なエラーメッセージ）

0.3 coding-knowledge の深い読み込み（中核ステップ）

これが code-gen と通常の AI コード生成との最大の違いです。「ざっと読んで概要を把握する」のではなく、コードレイヤーごとに具体的なコーディングパターンを抽出します。

第1層: 基本規約（必読）

coding-knowledge/infra/ 配下のファイルを読み込み、グローバルなコーディング制約を抽出します。

• code-quality.md → 命名規約（キャメルケース vs スネークケース、プレフィックス/サフィックスの慣例）、コメントスタイル、例外処理パターン、ログ規約
• その他のインフラストラクチャ規約 → ミドルウェアの使用方法（MQ プロデューサー/コンシューマーパターン、キャッシュ操作）

第2層: リポジトリアーキテクチャ（関係するリポジトリごとに読み込み）

tech-design にリストされた各リポジトリについて、coding-knowledge/repos/{repo}/ 配下のファイルを読み込みます。

• architecture.md → パッケージ構造とレイヤー分割の慣例。新規ファイル作成時に、どのパッケージに配置するか、クラス名をどう命名するかを決定します。「本サービスは担当しない」という説明に特に注意——そのサービスに属さないロジックを書かないようにします。
• symbols.md → 既存のクラスとメソッドのシグネチャインデックス。これは「スタイル学習」の入り口です。ここから同種の既存実装（既存の Controller、Service など）を見つけ、後続の Phase 1 で完全なソースコードを Read します。
• database-schema.md → 既存テーブルの実際の DDL。新規テーブル作成時に、フィールド命名変換ルール（例: create_time vs createdAt）、インデックス命名規約（例: idx_ プレフィックス）、文字セットとエンジン設定を参照します。
• call-chains.md → 実際のクロスサービス呼び出しコード。tech-design がクロスサービス呼び出しを含む場合、ここからプロジェクトが実際に使用している呼び出し方法（Feign Client？RestTemplate？WebClient？gRPC stub？）と、エラー処理やタイムアウト設定の書き方を学びます。

第3層: ビジネスドメイン（必要に応じて読み込み）

tech-design がクロスサービス連携を含む場合、coding-knowledge/business/domains/{domain}/ を読み込みます。

• cross-service.md → クロスリポジトリの呼び出し関係とデータフロー

0.4 スタイル学習（重要なステップ）

symbols.md から 2〜3 個の同種の既存実装ファイルを見つけ、Read ツールで完全なソースコードを読み込みます。目的は、シグネチャだけでなく、プロジェクトのコーディングパターンを学習することです。

具体的な方法:

生成するコードレイヤー	symbols.md から見つける参照オブジェクト	学習ポイント
Entity/Model	同じリポジトリの既存の Entity クラス	アノテーションの使用方法、フィールド命名変換、基底クラスの継承、監査フィールドの処理
Mapper/Repository	同じリポジトリの既存の Mapper/Repository	MyBatis XML vs アノテーション、カスタムクエリメソッドの命名パターン、ページネーション実装
Service	同じリポジトリの既存の Service クラス	トランザクションアノテーションの使用方法、例外のスロー方法、依存性注入スタイル（コンストラクタ vs @Autowired）
Controller	同じリポジトリの既存の Controller クラス	統一戻り値ラッパー、パラメータバリデーションアノテーション、権限アノテーション、Swagger アノテーションスタイル
フロントエンド API 層	同じプロジェクトの既存の API ファイル	axios のラップ方法、リクエスト/レスポンスインターセプター、エラー処理
フロントエンドページ	同じプロジェクトの既存のリストページ/フォームページ	コンポーネントライブラリの使用方法、状態管理方法、検索条件のレイアウト

スタイル学習の成果物は暗黙の「コーディングチェックリスト」 です。ユーザーに出力する必要はありませんが、Phase 2 でコードを生成する際には常に従わなければなりません。例えば:

• 「このプロジェクトの Controller はすべて @RestController + @RequestMapping を使用し、@Controller + @ResponseBody は使用しない」
• 「Service 層の例外は throw new BusinessException(ErrorCode.XXX) で統一し、error code を返さない」
• 「すべてのクエリメソッドは listXxx/getXxx と命名し、queryXxx/findXxx とは命名しない」

Phase 1: 生成計画（ユーザー確認）

コードを書き始める前に、必ずユーザーに計画を提示し、確認を得なければなりません。

Phase 0 の分析結果に基づき、構造化された生成計画を出力します:

## コード生成計画

### コードスタイル参考
- バックエンド参考: {symbols.md から特定した参照 Controller/Service ファイルパス}
- フロントエンド参考: {既存ページから特定した参照コンポーネントパス}
- コーディング規約: {coding-knowledge/infra/code-quality.md の主要な制約}

### バックエンド（{リポジトリ名}）
| 番号 | 操作 | ファイルパス | 説明 | 対応タスク |
|------|------|--------------|------|----------|
| 1 | 新規 | {architecture.md から導出した正確なパッケージパス}/XxxEntity.java | エンティティクラスを新規作成 | T-01 |
| 2 | 新規 | {パッケージパス}/XxxMapper.java | Mapper インターフェースを新規作成 | T-01 |
| 3 | 修正 | {symbols.md から特定した正確なファイルパス}:L{行番号} | メソッド createXxx() を新規追加 | T-02 |
| 4 | 新規 | {パッケージパス}/XxxController.java | CRUD インターフェースを新規作成 | T-03 |

### フロントエンド（{リポジトリ名}）
| 番号 | 操作 | ファイルパス | 説明 | 対応タスク |
|------|------|--------------|------|----------|
| 1 | 新規 | src/api/xxx.js | API 呼び出し層 | T-05 |
| 2 | 新規 | src/pages/xxx/index.vue | リストページ（prototype/list.html を参照） | T-05 |
| 3 | 新規 | src/pages/xxx/form.vue | 新規/編集フォーム | T-05 |

### データベース
- tech-design の DDL を実行（database-schema.md を参照してスタイルの一貫性を確認済み）

### 注意事項
- {ユーザーに確認が必要な事項}

計画中のファイルパスは正確なパスでなければなりません。推測ではなく、architecture.md（パッケージ構造）と symbols.md（既存ファイルの位置）から導出されたものです。既存ファイルを修正する操作には、行番号を記載します。

ユーザーが確認してから Phase 2 を開始します。

Phase 2: 依存関係の順序に従ってコードを生成

生成原則: 依存関係に従い、下位層から上位層へ生成し、参照関係が正しいことを確認します。各ファイルは生成後すぐに書き込みます。

バックエンドの生成順序

Entity → Mapper/Repository → Service → Controller → 設定/その他 の順序に従います:

1. Entity/Model 層

• tech-design の DDL に従ってエンティティクラスを生成
• Phase 0.4 で学んだパターン: フィールドアノテーションの方法（JPA @Column か MyBatis-Plus @TableField か）、基底クラスの継承（BaseEntity の有無）、監査フィールド（createTime/updateTime の処理方法）、論理削除フィールド
• database-schema.md からの参考: フィールド命名変換ルール（データベースの create_time → Java の createTime の具体的な方法。@TableField("create_time") を使用するプロジェクトもあれば、グローバル設定で自動変換するプロジェクトもある）

2. Mapper/Repository 層

• Entity に対応するデータアクセスインターフェースを生成
• Phase 0.4 で学んだパターン: MyBatis XML vs アノテーション、BaseMapper<T> の継承有無、カスタムクエリメソッドの命名規則、ページネーションの実装方法（PageHelper？MyBatis-Plus IPage？）
• tech-design で言及されたカスタムクエリメソッドを含む

3. Service 層

• ビジネスロジックを実装。tech-design の各インターフェースの処理フローに対応
• Phase 0.4 で学んだパターン: トランザクションアノテーションの使用方法（@Transactional の伝播レベルの習慣）、例外処理方法（カスタム BusinessException？統一 ErrorCode 列挙型？）、依存性注入スタイル（コンストラクタ注入 vs @Autowired）、ログ出力の習慣
• PRD 受け入れ基準からバリデーションロジックを導出: 各受け入れ条件に対応するバリデーションブランチ
• クロスサービス呼び出し: call-chains.md からプロジェクトが実際に使用している呼び出し方法を見つけ、そのコードパターンをそのまま踏襲する（新しい呼び出し方法を独自に考案しない）

4. Controller 層

• インターフェースパス、パラメータ、レスポンス構造は tech-design のインターフェース設計に厳密に従う
• Phase 0.4 で学んだパターン: 統一戻り値ラッパークラス（Result<T>？ResponseEntity<T>？）、パラメータバリデーションアノテーション（@Valid + JSR 303 か手動バリデーションか）、権限アノテーション（@PreAuthorize？カスタム @Permission？）、Swagger/OpenAPI アノテーションスタイル
• エラーコードは tech-design で定義されたビジネスエラーコードを使用

5. 設定/その他

• MQ Consumer/Producer（tech-design に関連する場合）—— call-chains.md から既存の MQ コードの書き方を見つける
• メニュー/権限設定ファイル（必要な場合）
• 新規の定数/列挙型クラス

フロントエンドの生成順序

API 呼び出し層 → ルーティング設定 → ページコンポーネント の順序に従います:

1. API 呼び出し層

• tech-design のインターフェース一覧に従って API メソッドを生成
• Phase 0.4 で学んだパターン: axios のラップ方法（統一 request 関数？各 API が独立したファイル？）、リクエスト/レスポンスインターセプター処理
• メソッド名とパラメータ名は tech-design のインターフェース番号に対応

2. ルーティング設定

• 新規ページのルーティング登録
• 既存のルーティングファイルの編成方法を参考にする

3. ページコンポーネント

• prototype/ のページ構造を参考: プロトタイプのテーブル列の順序、検索条件のレイアウト、モーダルウィンドウの構造がそのままコンポーネントコードを導きます
• プロジェクトの実際の技術スタックのコンポーネントライブラリを使用（coding-knowledge または package.json から Element UI / Ant Design / 自社開発コンポーネントなどを特定）
• テーブル列の定義は tech-design のインターフェースレスポンスフィールドから導出
• フォームフィールドとバリデーションルールは tech-design のインターフェースリクエストパラメータから導出

各ファイルの生成フロー

1. 新規ファイルの場合:
   • 対象ディレクトリが存在することを確認（ls でチェック）
   • Write ツールで作成
2. 修正ファイルの場合:
   • まず Read でファイルの完全な内容を読み込む
   • Edit で正確に修正（周辺コードを再フォーマットしない）
3. 生成後すぐにファイルシステムに書き込む（最後にまとめて書き込まない）

Phase 3: レポート生成

requirements/{モジュール名}/ ディレクトリに code-gen-report.md を生成します:

---
title: "{モジュール名} — コード生成レポート"
tech_design_version: "{tech-design バージョン}"
date: "{生成日}"
---

# {モジュール名} — コード生成レポート

## 1. 生成概要

| リポジトリ | 新規ファイル | 修正ファイル | 対応タスク |
|------------|-------------|-------------|----------|
| {リポジトリ名} | {N} 個 | {M} 個 | T-01 ~ T-03 |

## 2. コーディングスタイル参考

| コードレイヤー | 参照した既存ファイル | 学習した主要なパターン |
|----------------|---------------------|---------------------|
| Controller | {ファイルパス} | 統一戻り値 Result<T>、@Valid を使用したバリデーション |
| Service | {ファイルパス} | コンストラクタ注入、BusinessException による例外処理 |
| Entity | {ファイルパス} | BaseEntity の継承、@TableField アノテーション |

## 3. ファイル一覧

### {リポジトリ名}

#### 新規ファイル
| ファイルパス | 説明 | 対応 tech-design タスク |
|--------------|------|----------------------|
| src/.../XxxEntity.java | エンティティを新規作成 | T-01 |

#### 修正ファイル
| ファイルパス | 修正内容 | 対応 tech-design タスク |
|--------------|----------|----------------------|
| src/.../XxxService.java | メソッド createXxx() を新規追加 | T-02 |

## 4. 要件カバレッジチェック

| PRD 機能 | インターフェース番号 | コードファイル | 受け入れ基準カバレッジ |
|----------|---------------------|---------------|----------------------|
| F-01 | API-01, API-02 | XxxController.java | 全件カバー |
| F-02 | API-03 | XxxService.java | 一部カバー（Q-01 未確定項目は未実装） |

## 5. 未カバー項目

{tech-design にはあるが今回生成しなかったタスクとその理由}

## 6. 注意事項

{開発者が手動で処理する必要がある事項。例:}
- 設定センターに追加が必要な設定項目
- 手動実行が必要な DDL
- 手動確認が必要なビジネスロジック
- coding-knowledge で発見された tech-design との不整合

Phase 4: サマリー出力

生成完了後、ユーザーに以下の情報を通知します:

1. コード生成レポートの場所
2. 新規/修正ファイルの数（リポジトリごとに集計）
3. 対応する tech-design タスクのカバレッジ状況
4. 手動で処理が必要な事項
5. /code-review を使用して生成されたコードをレビューすることを推奨

出力ディレクトリ

requirements/{モジュール名}/
├── prd-draft.md              ← PRD 最終稿（入力）
├── review/                   ← prd-review の成果物
├── prototype/                ← proto-gen の成果物
├── tech-design.md            ← tech-design の成果物（入力）
└── code-gen-report.md        ← 本 skill の成果物

実際のコード変更は、対象リポジトリのディレクトリに直接書き込まれます（requirements/ 配下ではありません）。

他の skill との関係

coding-knowledge-init                         ← 第ゼロステップ：プロジェクトマップ
  生成 coding-knowledge/
        ↓ (参考)
project-import → knowledge-init → prd-draft → prd-review → proto-gen
                                                                ↓
                                              tech-design → code-gen → code-review
                                                             ↑
                                                     coding-knowledge/
                                                     (深い活用)

• 前置: tech-design の技術方案が主要な入力です。coding-knowledge-init のコーディング知識ベースは中核的な参考資料です。
• 後続: 生成されたコード変更は code-review によってレビューされます。
• tech-design との関係: tech-design は「何をするか」（インターフェース設計、DDL、タスク分割）を定義し、code-gen は「どうやって実行するか」（実際のコードを生成）を実行します。tech-design のインターフェース番号（API-XX）とタスク番号（T-XX）は code-gen の直接的なインデックスです。
• coding-knowledge との関係: coding-knowledge は code-gen の「コーディングメンター」です。
  • symbols.md はプロジェクト内のクラスやメソッド、同種の参考コードを探す場所を教えてくれます
  • architecture.md は新しいコードをどのパッケージに配置し、どのレイヤー構造に従うかを教えてくれます
  • database-schema.md はテーブル作成のスタイルを教えてくれます
  • call-chains.md はクロスサービス呼び出しの書き方を教えてくれます
  • infra/code-quality.md は従うべき規約を教えてくれます
  • coding-knowledge がなくてもコードを生成することは可能ですが、その効果は「古参メンバーが書いたコード」から「インターンが書いたコード」に格下げされます

既存コードの修正 vs 新機能追加

AI は tech-design の変更範囲に基づいて、各ファイルが「既存コードの修正」か「新規ファイルの追加」かを自動的に判断し、異なる生成戦略を採用します。

既存コード修正時の鉄則

変更が必要な箇所だけを変更し、変更すべきでない箇所には手を付けない。 これは既存コードの修正において最も一般的で深刻な問題です。AI が既存コードを読み解いた後、「ついでに」周辺のロジックをリファクタリングし、結果として回帰バグを引き起こします。

具体的な要件:

• まず Read で既存ファイル全体を読み込み、コンテキストを理解してから作業を始める
• Edit で正確に修正し、Write でファイル全体を上書きしない
• 既存の変数/メソッド名を変更しない。たとえ命名が良くないと思っても——それは別の要件です
• 既存コードのフォーマットを調整しない（インデント、空行、import 順序）。ただし、自分が新規追加したコードと直接隣接する部分は除く
• 既存のロジックを「最適化」しない——tech-design に「createOrder メソッドに新しいバリデーションを追加する」と書いてあれば、バリデーションだけを追加し、createOrder の他のロジックは変更しない
• 新規メソッドを追加する際は、挿入位置に注意: プロジェクトの既存のメソッド配置の慣習（例: CRUD 順、public が先、private が後）に従い、適切な位置に挿入する

判断基準

シグナル	判断	生成戦略
tech-design に「修正：XxxService:L120」と記載	既存コードの修正	Read → Edit で正確に修正
tech-design に「新規：{パッケージパス}/XxxController.java」と記載	新規ファイル	Write でファイル全体を作成
tech-design に「メソッド createXxx() を新規追加」と記載	既存ファイルに新規追加	Read → Edit で適切な位置に挿入

生成原則

スタイルの一貫性が最優先：生成されたコードは、プロジェクトの既存コードの自然な延長線上にあるように見えなければなりません。方法は、「規約を読んで感覚で書く」のではなく、以下の手順に従います:

1. symbols.md から同種の既存実装ファイルを見つける
2. 完全なソースコードを Read し、コーディングパターンを抽出する
3. 新しいコードはこれらのパターンを厳密に模倣する——同じアノテーションの組み合わせ、同じメソッド命名、同じ例外処理方法

tech-design は信頼できるソース：インターフェースパス、パラメータ名、レスポンス構造、エラーコードは tech-design を基準とし、独自に解釈しない。tech-design に問題があると思われる場合（例: パラメータタイプが不適切）、レポートの「注意事項」にその旨を記載しますが、コードは tech-design に従って生成します。

coding-knowledge はコーディングメンター：「ここはどう書くべきか」という疑問が生じた場合、最初にとるべきアクションは coding-knowledge を調べることです。一般的な知識に基づいて推測してはいけません。例えば:

• 「このプロジェクトのページネーションはどう実装する？」 → symbols.md のページネーション関連メソッドを調べる
• 「クロスサービス呼び出しはどの方法を使う？」 → call-chains.md を調べる
• 「例外はどうスローする？」 → code-quality.md と参考 Service の実装を調べる

既存コードを壊さない：既存ファイルを修正する場合、必要な箇所にのみコードを追加/修正し、周辺コードを再フォーマットしたりリファクタリングしたりしない。Edit ツールを使用して正確に修正し、Write でファイル全体を上書きしない。

ビジネスロジックは完全に：メソッドシグネチャと TODO コメントだけを生成するのではなく、完全なビジネスロジックを含むコードを生成する。バリデーションルールは PRD の受け入れ基準から導出し、処理フローは tech-design のシーケンス図から導出する。

分割して生成し、すぐに書き込む：Phase 2 の順序に従ってファイルごとに生成し、各ファイルは生成後すぐに書き込む。最後にまとめて出力してはいけない——途中でエラーが発生しても、既に書き込まれたファイルには影響しない。

よくある落とし穴

スタイル学習をスキップしていきなり生成する：プロジェクト内の既存の Controller を Read せずに新しい Controller を生成した結果、まったく異なるアノテーションの組み合わせや戻り値ラッパーを使用してしまう。Phase 0.4 のスタイル学習は省略できない。

symbols.md だけを見てソースコードを読まない：symbols.md にはシグネチャのインデックスしかなく、メソッド内部のコーディングパターン（トランザクションの使用方法、例外のスロー方法、ログ出力方法）はわからない。2〜3 個の参考ファイルの完全なソースコードを Read しなければならない。

インターフェースパラメータが tech-design と一致しない：tech-design には knowledgeType と書いてあるのに、コードには knowledge_type や type と書いてしまう。tech-design のパラメータ名に厳密に従わなければならない。

修正ファイルの漏れ：tech-design では 3 つのファイルを修正する必要があるのに、code-gen は 2 つしか修正しなかった。Phase 1 の計画リストは tech-design の変更範囲を完全にカバーしなければならない。

フロントエンドコードがプロトタイプを参考にしない：prototype/ のページ構造は PRD の可視化表現です。フロントエンドコードはプロトタイプのレイアウトとコンポーネント構造を参考にし、自分でページを再設計してはいけません。

シグネチャだけを生成し、実装を書かない：生成された Service メソッドの本体がすべて // TODO: implement になっている。この skill の価値は完全なビジネスロジック実装を生成することにあり、開発者が自分で埋めるための空白を残すことではありません。

既存コード修正時に「ついでに」リファクタリングする：既存のメソッドを修正する際、必要なロジックだけを追加し、変数名を変更したり、コードフォーマットを調整したり、周辺ロジックを最適化したりしてはいけない。これらの「改善」は回帰バグの主な原因です。

既存コード修正時に既存ロジックを重複実装する：tech-design に「既存のフローに新しいバリデーションステップを追加する」とあるのに、code-gen がフロー全体を（既存のロジックも含めて）書き直してしまう。増分コードのみを書き、既存のロジックは一切変更してはいけない。

coding-knowledge の「担当しない」という注釈を無視する：architecture.md に「本サービスは XXX を担当しない」と書いてあるのに、そのロジックをコードに含めてしまう。コードを生成する前に、サービスの責務の境界を確認しなければならない。

クロスサービス呼び出し方法の不一致：プロジェクトの既存コードは Feign Client を使用して他のサービスを呼び出しているのに、生成されたコードは RestTemplate を使用している。call-chains.md または参照コードから実際の呼び出し方法を学ばなければならない。