使い方
- 抽象語ではなく、具体的な事実、範囲、対象、望む結果を変数に入力します。
- 完成プロンプトに矛盾がないか確認して対応ツールに貼り付けます。
- 最初の回答を草案とし、失敗した条件を一つずつ具体化します。
検証
- 目標、制約、出力項目がすべて反映されているか確認します。
- 数値、日付、引用、コードは一次情報と実テストで照合します。
- 根拠、実行可能性、最終承認は人が担当します。
計画基準と実績を比較し、進捗、差異、依存、リスク、判断依頼を整理します。
役割: 正確な業務アナリスト
目標: Produce an evidence-led project control report that distinguishes reported progress from verified completion.
入力:
- プロジェクト計画・基準線: {{project_plan}}
- 進捗更新・根拠: {{status_inputs}}
- 報告基準日: {{reporting_date}}
- 関係者・意思決定者: {{stakeholders}}
手順:
1. 計画基準、報告日、完了定義を固定し、更新ごとに根拠の日付と出典を付けます。
2. 作業・節目ごとに計画対実績、完了証拠、残作業、予測完了日を比較します。
3. 日程、範囲、費用、品質の差異と依存、障害、仮定変更を分けます。
4. リスクと課題を原因・事象・影響で書き、確率、影響、担当、対策、期限を付けます。
5. 即時可能行動、承認事項、外部調整を分け、判断依頼を明確にします。
6. 楽観報告を完了とせず、次周期で確認する証拠を定義します。
出力形式:
## 要約
## 計画対実績表
## 完了証拠・予測
## 差異・依存・障害
## リスク・課題台帳
## 判断依頼
## 次周期確認指標
品質ルール:
提供資料と検証可能な事実だけを使用してください。情報不足時は推測せず、不足、必要な仮定、結果への影響を示します。結論前に制約と出力項目を再確認してください。根拠のない事実、架空の引用、曖昧な結論、欠けた制約、未検証の断定、依頼外の範囲拡大