見積作成依頼プロンプト例
# 見積作成
指定された見積対象について、リポジトリ内を調査し、実装見積を作成してください。
## 必須参照
見積フォーマットについては以下を正としてください。
* `estimate-template/format-spec.md`
* `estimate-template/example.txt`
必要に応じて `estimates/*_見積.txt` も参照してください。
ただし、過去見積と `format-spec.md` が矛盾する場合は、`format-spec.md` を優先してください。
## 調査
見積を作成する前に、対象機能に関連する以下を調査してください。
* 既存実装
* 関連クラス・モジュール
* API
* DB
* テスト
* 設定ファイル
* README・設計資料
* 類似機能
見積根拠が不足している場合は、推測で仕様を確定せず、前提条件として明記してください。
## 見積
作業を実装可能な粒度まで分解してください。
各作業について、
* 作業内容
* 実装範囲
* 影響範囲
* 工数
を検討してください。
工数の算出方法および表記は `format-spec.md` に従ってください。
## 出力
最終結果は必ず次のファイルとして作成してください。
`{見積対象}_見積.txt`
チャット上で見積全文を回答するだけで終了せず、必ずファイルを作成してください。
出力後に `format-spec.md` と比較し、形式違反がないことを自己チェックしてください。
要件ベースの見積依頼プロンプト例
# 見積生成
**見積作業を開始する前に、必ず以下の4ファイルをすべて読み終えてください。**
4ファイルの内容を確認し終えるまでは、見積の作成・工数算定・見積ファイルの出力を開始しないでください。
## 参照ファイル
* `開発概要.txt`
* 今回の見積対象となる開発内容・要件・前提情報です。
* 見積内容の根拠として使用してください。
* `format-spec.md`
* 見積ファイルの正式な出力仕様です。
* セクション構成、記載順序、表記方法、工数表現、禁止事項などは必ずこのファイルに従ってください。
* `template.txt`
* 最終的な見積ファイルの骨格です。
* 原則としてこのテンプレートの構造を維持し、必要な内容を埋めてください。
* `example.md`
* 過去の見積に基づく記載例です。
* 作業分解の粒度、説明の詳しさ、表現方法、工数の置き方を参考にしてください。
* ただし、example.mdの案件固有の内容を今回の見積へ流用しないでください。
## 参照優先順位
ファイル間で内容が競合する場合は、以下の優先順位で判断してください。
1. `format-spec.md`
2. `開発概要.txt`
3. `template.txt`
4. `example.md`
`example.md` はあくまで参考例であり、正式な仕様ではありません。
## 見積作成手順
最終ファイルを作成する前に、以下の順序で検討してください。
1. `開発概要.txt` を読み、今回の開発対象・目的・要件を整理する。
2. 実装に必要な作業を、見積可能な粒度まで分解する。
3. 各作業について、実装内容・影響範囲・確認作業・テストなど必要な工程を検討する。
4. `example.md` を参考に、既存見積と同程度の粒度で工数を算出する。
5. `template.txt` に沿って見積内容を配置する。
6. `format-spec.md` に照らして、出力形式を最終確認する。
7. 形式違反があれば修正した上で完成させる。
## 見積時のルール
* `開発概要.txt` に明記されていない仕様を、根拠なく確定事項として扱わないでください。
* 情報不足があっても、見積可能な範囲は合理的な前提を置いて見積してください。
* 仮定した内容は、`format-spec.md` で定められた適切な箇所に前提条件として明記してください。
* 開発概要から明らかに不要な作業を、水増し目的で追加しないでください。
* 一方で、実装に通常必要となる調査、既存影響確認、実装、テスト、レビュー対応等が見積対象に含まれるルールであれば、それらを漏らさないでください。
* 工数の単位、丸め方、合計方法は必ず `format-spec.md` に従ってください。
* example.mdに記載されている工数を、そのまま今回の見積へ転用しないでください。
* 開発内容に応じて個別に工数を判断してください。
## 不明事項の扱い
見積に重大な影響を与える不明事項がある場合でも、可能な限り見積作業を継続してください。
その場合は、
* どのような前提で見積したか
* 前提が変わった場合にどの作業または工数へ影響するか
が分かるように記載してください。
ただし、情報不足により工数算定自体が成立しない項目については、無理に具体的な値を捏造しないでください。
## 出力
最終的な回答は説明文ではなく、`template.txt` と `format-spec.md` に準拠した見積ファイルとして作成してください。
ファイル名は `format-spec.md` に定義された命名規則に従ってください。
出力後、以下を自己チェックしてください。
* 必須セクションがすべて存在する
* セクションの順序が正しい
* 見出し・インデント・改行形式が正しい
* 工数単位・桁・丸め方が正しい
* 個別工数と合計工数に矛盾がない
* example.md固有の案件情報が混入していない
* 開発概要.txtに存在しない内容を事実として断定していない
* format-spec.mdの禁止事項に違反していない
問題がある場合は、修正してから完了してください。
リポジトリを参照性影響範囲も分析する場合の見積依頼プロンプト例
# 見積生成
**見積作業を開始する前に、必ず以下の4ファイルをすべて読み終えてください。**
4ファイルの内容を確認し終えるまでは、見積の作成・工数算定・見積ファイルの出力を開始しないでください。
## 参照ファイル
* `開発概要.txt`
* 今回の見積対象となる開発内容・要件・前提情報です。
* 見積内容の根拠として使用してください。
* `format-spec.md`
* 見積ファイルの正式な出力仕様です。
* セクション構成、記載順序、表記方法、工数表現、禁止事項などは必ずこのファイルに従ってください。
* `template.txt`
* 最終的な見積ファイルの骨格です。
* 原則としてこのテンプレートの構造を維持し、必要な内容を埋めてください。
* `example.md`
* 過去の見積に基づく記載例です。
* 作業分解の粒度、説明の詳しさ、表現方法、工数の置き方を参考にしてください。
* ただし、`example.md` の案件固有の内容を今回の見積へ流用しないでください。
## 参照優先順位
ファイル間で内容が競合する場合は、以下の優先順位で判断してください。
1. `format-spec.md`
2. `開発概要.txt`
3. `template.txt`
4. `example.md`
`example.md` はあくまで参考例であり、正式な仕様ではありません。
---
# 見積作成手順
以下の順序を厳守してください。
## 1. 4ファイルの読み込み
最初に、以下の4ファイルをすべて確認してください。
* `開発概要.txt`
* `format-spec.md`
* `template.txt`
* `example.md`
4ファイルを読み終える前に、見積作業へ進まないでください。
各ファイルについて、内部的に以下を把握してください。
* 今回の開発対象
* 要件
* 制約
* 前提条件
* 出力フォーマット
* 見積項目の粒度
* 工数表記ルール
* 禁止事項
## 2. 開発概要の整理
`開発概要.txt` をもとに、今回の開発内容を整理してください。
最低限、以下を把握してください。
* 開発目的
* 対象機能
* 変更内容
* 新規開発か既存改修か
* 対象画面・API・バッチ・DB・外部連携など
* 明示されている前提条件
* 不明点
* 見積に影響しそうな事項
この時点では、開発概要に記載されていない仕様を事実として補完しないでください。
---
# リポジトリ調査
## 3. 関連実装の探索
`開発概要.txt` の内容を起点として、現在のリポジトリを調査してください。
見積対象に関連しそうな以下のファイルや実装を探索してください。
* 関連するソースコード
* 既存画面
* コンポーネント
* API
* Controller / Handler
* Service
* Domain / Model
* Repository / DAO
* DB定義
* Migration
* バッチ
* ジョブ
* 設定ファイル
* 定数
* 認証・認可処理
* 外部サービス連携
* テストコード
* テストデータ
* README
* 設計資料
* コメント
* 類似機能の既存実装
開発概要に記載された名称だけでなく、関連する機能名・画面名・API名・テーブル名・クラス名なども検索し、影響範囲を確認してください。
## 4. 類似実装の調査
今回の開発内容と類似する既存実装がある場合は確認してください。
類似実装から、以下を把握してください。
* 実装パターン
* 必要となる変更箇所
* ファイル構成
* テスト方法
* 共通処理
* 再利用可能な処理
* 過去の実装との差分
ただし、類似機能だからという理由だけで、今回も完全に同じ実装になるとは仮定しないでください。
## 5. 影響範囲の確認
見積対象の変更によって影響する可能性がある箇所を確認してください。
特に以下を確認してください。
* 呼び出し元
* 呼び出し先
* 共通モジュール
* インターフェース
* 型定義
* DBスキーマ
* API仕様
* 認証・認可
* エラーハンドリング
* ログ
* キャッシュ
* 外部システム
* 既存テスト
* 新規テスト
* 回帰テストが必要な箇所
直接変更するファイルだけではなく、変更によって影響を受ける周辺実装も見積判断に含めてください。
## 6. 開発概要とリポジトリの整合性確認
`開発概要.txt` と現在のリポジトリの実装内容を比較してください。
以下のような差異がないか確認してください。
* 開発概要では存在するとされている機能が、実装上は存在しない
* 開発概要の名称と実際のクラス名・API名・画面名が異なる
* すでに一部実装されている
* 想定より影響範囲が広い
* 想定より既存処理を再利用できる
* 開発概要にはないが、実装上避けられない関連変更がある
差異があった場合は、リポジトリで確認できた事実を見積判断に反映してください。
ただし、開発概要の要求そのものを勝手に変更しないでください。
---
# 見積作成
## 7. 作業項目の分解
4ファイルとリポジトリ調査の結果をもとに、実装に必要な作業を見積可能な粒度まで分解してください。
必要に応じて以下の観点を考慮してください。
* 事前調査
* 設計
* 既存処理の修正
* 新規実装
* DB変更
* API変更
* 画面変更
* 外部連携変更
* 設定変更
* テストコード作成・修正
* 単体テスト
* 結合確認
* 影響確認
* レビュー対応
ただし、実際に必要性が確認できない作業を機械的に追加しないでください。
## 8. 工数算定
各作業項目について工数を算定してください。
工数を判断する際は、以下を考慮してください。
* 実装量
* 既存実装の再利用可否
* 修正対象ファイル数
* 影響範囲
* ロジックの複雑さ
* DB変更の有無
* 外部連携の有無
* テスト範囲
* 調査が必要な範囲
* 既存コードへの理解コスト
* 不確定要素
`example.md` は工数の値そのものではなく、作業分解の粒度や記述方法の参考として使用してください。
`example.md` に記載された工数をそのまま転用しないでください。
工数の単位・丸め方・合計方法は必ず `format-spec.md` に従ってください。
---
# 不明事項・前提条件
## 9. 情報不足への対応
`開発概要.txt` やリポジトリを調査しても確定できない事項がある場合、根拠なく仕様を確定しないでください。
ただし、情報不足があることだけを理由に見積作業全体を停止しないでください。
合理的な前提を置けば見積可能な場合は、
* どのような前提を置いたか
* その前提が変わった場合、どの作業に影響するか
* 工数が増減する可能性があるか
が分かるように、`format-spec.md` に定められた適切な箇所へ記載してください。
工数算定そのものが成立しない事項については、無理に数値を捏造しないでください。
---
# 見積ファイルの生成
## 10. テンプレートへの反映
見積内容が確定したら、`template.txt` を骨格として使用してください。
以下を厳守してください。
* `template.txt` の構造を原則維持する
* 必要な内容だけを埋める
* 独自のセクションを勝手に追加しない
* `format-spec.md` と矛盾する場合は `format-spec.md` を優先する
* `example.md` の案件固有情報を混入させない
## 11. 最終フォーマット確認
出力前に、完成した見積内容を `format-spec.md` と照合してください。
以下をすべて確認してください。
* 必須セクションが存在する
* セクションの順序が正しい
* 見出し形式が正しい
* インデントが正しい
* 改行形式が正しい
* 工数単位が正しい
* 工数の丸め方が正しい
* 個別工数と合計工数が一致している
* ファイル命名規則が正しい
* 禁止事項に違反していない
* `example.md` 固有の情報が混入していない
* `開発概要.txt` に存在しない仕様を事実として断定していない
違反がある場合は、見積ファイルを修正してから完了してください。
---
# 出力
最終的な回答は、見積内容の説明だけで終了せず、必ず見積ファイルを作成してください。
ファイル名・拡張子・内容は `format-spec.md` の定義に従ってください。
チャット上には必要に応じて、以下のような簡潔な完了報告のみを記載してください。
* 作成した見積ファイル名
* リポジトリ調査を実施した旨
* 見積上の重要な前提条件がある場合はその旨
見積の全文をチャット回答として重複出力する必要はありません。
---
# 最重要ルール
以下を必ず守ってください。
1. 4ファイルすべてを読み終える前に見積を開始しない。
2. `開発概要.txt` だけを読んで見積を作らず、必ず関連するリポジトリ実装を調査する。
3. 見積の正式な出力ルールは `format-spec.md` を最優先とする。
4. `template.txt` を出力骨格として使用する。
5. `example.md` は粒度・表現の参考に限定し、案件固有情報や工数を流用しない。
6. リポジトリで確認できない仕様を事実として捏造しない。
7. 不明事項があっても、合理的な前提を明示できる場合は見積を継続する。
8. 最終出力前に `format-spec.md` に対する自己チェックを必ず実施する。