Aaalexy/craft-codex-prompts

Craft Codex Prompts

目的

不完全なコンテキストを、推論された解釈を事実として扱わずに別のCodex会話が実行できるタスクパッケージに変換します。ソースの忠実性、限定された権限、テスト可能な完了、および低いプロンプトオーバーヘッドに最適化します。

操作を選択

• Draft: ファイル、プロジェクトコンテキスト、または大まかなリクエストからプロンプトを構築します。
• Review: 既存のプロンプトの弱点を診断し、修正バージョンを作成します。
• Handoff: 以前の作業、結果、未解決の問題を次の実行可能なプロンプトに変換します。
• Knowledge loop: ナレッジベースで使用可能な、現在の状態、決定、未解決の問題、およびハンドオフ更新を作成します。

ユーザーがプロンプトのみを要求した場合は、プロンプトと重要な前提条件のみを返します。再利用可能なワークフローを要求した場合は、完全なタスクパッケージを返します。

ワークフロー

1. ソースと権限の確立

許可されており有用な場合、ドラフトを作成する前に、ユーザー提供のファイルとアクセス可能なプロジェクト資料を読み取り専用で検査します。プロンプトを準備しているだけの間は、ソースプロジェクトを変更しないでください。

入力を分類します：

• 一次的な事実: 現在のファイル、リポジトリの状態、明示的なユーザーステートメント、信頼できるプロジェクトドキュメント。
• 派生コンテキスト: 要約、以前のアシスタントの結論、レポート、コピーされたチャット。
• 未知のもの: 欠落しているファイル、未検証のランタイム状態、未解決の選択、外部依存関係。

派生コンテキストは手がかりとして扱い、証明としては扱いません。実行中の会話は、一次ソースに対してこれを検証する必要があることを明示的に述べてください。

ある会話に添付されたファイルが別の会話で利用可能であると想定しないでください。実行中の会話が受け取らなければならないすべてのファイルまたは正確なワークスペースに名前を付けてください。

2. タスクタイプの特定

最も近いタスクタイプを選択します：

• 回答または説明；
• 検査またはレビュー；
• 診断；
• 変更または構築；
• 調査または比較；
• アーティファクトの作成；
• 外部アクションの実行。

一致する権限の境界を維持します。分析または診断のリクエストは編集を許可しません。変更または構築のリクエストは、通常、範囲内の実装と検証を許可しますが、無関係なリファクタリング、公開、メッセージング、コミット、プッシュ、または破壊的なアクションは許可しません。

一致するタスクパターンについては task-blueprints.md を参照してください。

3. 安定したルールとタスクの差分を分離する

永続的なプロジェクトルールは、AGENTS.md、PROJECT_BRIEF.md、または CODEX_TASK_CONTRACT.md などのプロジェクトコントラクトに配置します。現在のプロンプトは、今回変更された内容に焦点を当てます。

安全上重要であるか、見逃される可能性が高い場合にのみ、安定したルールをタスクプロンプトで繰り返します。

4. 曖昧さを適切に解決する

回答がスコープ、ソースの選択、不可逆的な動作、外部への影響、または受け入れ基準を実質的に変更する場合にのみ、明確化の質問をします。それ以外の場合は、最も安全で合理的な仮定を選択し、ラベルを付けます。

欠落しているソース、サポートされていない機能、または外部ブロッカーを、確信を持った表現の背後に隠さないでください。

5. タスクパッケージを構成する

関連する場合、以下のセクションを作成します：

1. 成果: 1つの具体的な最終状態。
2. 真実のソース: 正確なファイル、パス、データ、またはユーザーの決定。
3. 現在の状態: 検証済みまたは明確に属性付けられた事実のみ。
4. スコープ: 許可された読み取り、編集、システム、およびアーティファクト。
5. 非目標: 可能性はあるが許可されていない拡張。
6. 隣接チェック: 同じ欠陥を露呈する可能性のある下流の表面。
7. 実行ガイダンス: 正確性に影響する制約であり、推測による実装の詳細ではない。
8. 受け入れ: 観察可能なチェックと期待される証拠。
9. ブロッカーと停止条件: 推測ではなく報告を必要とする条件。
10. デリバリー: 変更されたファイル、アーティファクト、証拠、制限事項、および次のハンドオフ。

実装が含まれる場合は、L1-L4検証ラダーを使用します：

• L1: 構文、インポート、スキーマ、または静的検証；
• L2: 単体テスト、サービス、または焦点を絞った回帰テスト；
• L3: 実際のファイルまたはエンドツーエンドのデータパス検証；
• L4: 実際のUI、パッケージ化されたランタイム、デバイス、本番環境に近い、または人間による受け入れ。

より低いレベルをより高いレベルの証明として提示しないでください。

このソース忠実性条項を、タスクに適応させて含めてください：

このプロンプトは、リポジトリの状態の証明ではなく、実行ブリーフとして扱ってください。その主張を現在のワークスペースと一次ファイルに対して検証してください。それらが矛盾する場合は、ソース資料を保持し、矛盾を報告し、ユーザーが別の決定をしない限り、一次ソースに従ってください。

6. プロンプトを実行可能に保つ

• 成果から始めます。
• 直接的な指示と具体的な名詞を使用します。
• 形容詞よりもファイル名、パス、数、期待されるアーティファクトを優先します。
• 正確な文言自体が証拠でない限り、生のチャットをコピーしないでください。
• ユーザーがその選択を固定しない限り、検査前にアーキテクチャを規定しないでください。
• 禁止事項は現実的な障害モードに限定します。
• Codexが報告のみ、診断、実装、または実装と検証のどれを行うべきかを明記します。
• コンパクトな完了フォーマットで終了します。

7. 配信前に監査する

6つのチェックに対して内部でプロンプトをスコアリングします：

• 忠実性: 各事実の主張はソースにトレースできますか？
• 権限: 読み取り、編集、外部アクション、禁止アクションは明確ですか？
• 完全性: 可能性のある隣接するコンシューマと障害パスはカバーされていますか？
• テスト可能性: 完了は観察可能な証拠で示せますか？
• 実現可能性: 利用できないツール、ランタイム制限、人的依存関係は露呈していますか？
• 簡潔さ: すべての指示は実行または検証を変更しますか？

1つのステータスを返します：

• READY: 利用可能なコンテキストで実行可能；
• READY_WITH_ASSUMPTIONS: 限定された前提条件をリストした後に実行可能；
• NEEDS_INPUT: 1つ以上の重要な選択肢が欠落している；
• BLOCKED_SOURCE_MISSING: 必要な一次資料が利用できない。

見かけ上の厳密さを向上させるためだけにプロンプトを膨らませないでください。

8. ナレッジループを閉じる

ユーザーがObsidianまたは別のナレッジベースで作業をアーカイブする場合、obsidian-loop.md を参照してください。不変の生のチャットを現在のプロジェクトの真実から分離してください。実行後、トランスクリプトのみに依存するのではなく、現在の状態、決定、未解決の問題、およびハンドオフを更新してください。

デフォルトの出力

ユーザーが別のフォーマットを要求しない限り、以下を返します：

## TASK_BRIEF
[検証済み事実、前提条件、未知のもの、ソース]

## MAIN_PROMPT
[コピー準備完了のプロンプト]

## PROMPT_STATUS
[READY, READY_WITH_ASSUMPTIONS, NEEDS_INPUT, または BLOCKED_SOURCE_MISSING]
[短い説明と必要な添付ファイル]

プロンプトレビューの場合、MAIN_PROMPT の前に短い KEY_GAPS セクションを追加します。非公開の思考連鎖を公開せず、簡潔で決定に関連する理由を提供します。