- expert/expert-mini/expert-cqrs/expert-cqrs-mini を dual 系にリネーム (「フルスタック」→「フロントエンド+バックエンド」に説明も修正) - expert-supervisor ペルソナを dual-supervisor にリネーム - passthrough, structural-reform ピースを削除 - default-mini, default-test-first-mini を default に統合 - coding-pitfalls ナレッジの主要項目を coding ポリシーに移動し削除 - implement/plan インストラクションにセルフチェック・コーダー指針を追加 - builtin カタログに不足していた terraform, takt-default 系を追加 - deep-research をカテゴリに追加
2.3 KiB
2.3 KiB
タスクを分析し、設計を含めた実装方針を立ててください。
注意: Previous Responseがある場合は差し戻しのため、 その内容を踏まえて計画を見直してください(replan)。
小規模タスクの判断基準:
- 1-2ファイルの変更のみ
- 設計判断が不要
- 技術選定が不要
小規模タスクの場合は設計セクションを省略してください。
やること:
- 参照資料の読み込み(必須・最初に実行)
- タスク指示書の「参照資料」セクションに記載されたファイル・ディレクトリを Read/Glob で実際に開いて内容を確認する
- ディレクトリが指定されている場合は中身を列挙し、該当ファイルを特定してから読む
- 参照資料が存在しない・見つからない場合はその旨を報告し、推測で代用しない
- 指示書に明記されていない別ファイルを「参照資料の代わり」として使うことは禁止
- タスクの要件を理解する
- 参照資料の内容と現在の実装を突き合わせて差分を特定する
- 参照資料が外部実装を指す場合、「バグ修正の手がかり」か「採用すべき設計アプローチ」かを判断する。スコープを参照資料の意図より狭める場合は判断根拠を計画レポートに含めること
- 要件ごとに「変更要/不要」を判定する。「不要」の場合は現行コードの該当箇所(ファイル:行)を根拠として示すこと。根拠なしの「既に正しい」は禁止
- コードを調査して不明点を解決する
- 影響範囲を特定する
- ファイル構成・設計パターンを決定する(必要な場合)
- 実装アプローチを決める
- 実装アプローチがナレッジ・ポリシーの制約に違反しないか照合する
- Coder向けの実装ガイドラインに以下を含めること:
- 参照すべき既存実装パターン(ファイル:行)。同種の処理が既にある場合は必ず示す
- 変更の影響範囲。特に新しいパラメータを追加する場合、配線が必要な全箇所を列挙する
- このタスクで特に注意すべきアンチパターン(該当するものがあれば)