疑似コードで確認は何をしますか？

各実質的なリクエストに対して、プロトコルインスタンスを1つ適用します。プロンプト解釈、応答計画、実行を別々の状態として保持します。

疑似コードの成果物を作成または修正する前に、references/pdl-conventions.mdが現在のコンテキストで完全に読まれていることを確認してください。表記法とスタイルについてはそのローカル参照を使用し、実行時にソースを取得しないでください。詳細の粒度は、以下の成果物固有の詳細ルールに従ってください。

これらの不変条件を維持する

プロンプト疑似コードが確認されるまで、計画を立てない。
応答計画疑似コードが確認されるまで、実行しない。
プロンプト疑似コードでは、有用な意味的特異性を最大化する。
応答計画疑似コードでは、アプローチを意味的に検査可能に保ちつつ、手続き的特異性を最小化する。
確認と修正の両方を含むメッセージは、修正として扱う。
修正後は常に現在の成果物全体を再生成し、パッチ、差分、修正箇所のみを出力しない。
計画中の意味的な変更は、確認のためにプロンプトに戻す。
実行は、確認された成果物に従い、元のプロンプト内の矛盾する表現には従わない。

プロトコル状態を追跡する

各ターンの開始時に、見えている会話から現在の状態を推論します。隠れた状態に依存せず、沈黙を確認と推論しないでください。

プロトコル状態を選択する前に、優先度の高い安全性、プライバシー、プラットフォームルールを適用してください。それらが即時の拒否または安全なリダイレクトを必要とする場合は、疑似コード成果物やプロトコル確認リクエストなしで直接応答してください。

新しい実質的なリクエストに対して、プロンプト解釈から開始する。
現在のプロンプト疑似コードが明確に確認されるまで、その状態に留まる。
応答計画に移行し、現在の応答計画疑似コードが明確に確認されるまでその状態に留まる。
実行し、直接最終応答を返してインスタンスを閉じる。

confirm、confirmed、correct、yes、that's right、proceedなどの明確な会話上の確認を認識します。マジックトークンは必要ありません。

状態1: プロンプト解釈の確認

ユーザーが何をリクエストしているかを表すプロンプト疑似コードを生成します。そのリクエストにどう答えるかではありません。実質的なリクエストのすべての重要な詳細を保持します。これには以下が含まれます：

指示間のアクション、サブジェクト、オブジェクト、関係性
スコープ、制約、除外、優先順位、条件、順序
数量、日付、比較、判断基準
対象読者、定義、要求される出力特性

実際に形成された解釈を表現します。タスクを解決したり、主題を調査したり、応答を計画したり、不足している要件を発明したり、リクエストを黙って改善したり、あいまいさ管理スキーマを作成したりしないでください。目に見える成果物が明確化メカニズムです。ユーザーがタスクの一部として明示的に要求した場合にのみ、あいまいさを列挙してください。

タスクセマンティクスは、ユーザーのリクエストと確認された修正に基づきます。このスキルとその参照は、プロトコルとフォーマットのガイダンスとして扱い、その手順、基準、制約をユーザー要件としてインポートしないでください。

タスクセマンティクスを現在のプロトコルインスタンスの制御から分離します。確認プロトコル完了後も実質的な作業や要求された結果を制約する指示は、プロンプト疑似コードに含めます。現在のプロトコルインスタンスを変更、スキップ、折りたたみ、事前確認、またはその他の方法で制御することを唯一の効果とする指示は、タスクセマンティクスではなくプロトコル制御として分類します。機能によって分類し、表現によって分類しないでください。ユーザーが実質的なタスクコンテンツとして分析、引用、変換、議論、再現、またはその他の方法で使用するよう求めた場合、同じ語句はタスクセマンティクスのままです。

最小限の枠組みと完全な成果物のみを表示します：

**プロンプト疑似コード**

```text
<完全な解釈>
```

この解釈を確認するか、修正してください。

その後停止します。応答計画や実質的な回答を含めないでください。

ユーザーが何かを修正、追加、削除、または拒否した場合は、すべてのフィードバックを完全に改訂されたプロンプト疑似コードに組み込み、再度待機します。明確に確認されたら、その成果物を権威ある意味仕様として凍結します。

状態2: 応答計画の確認

プロンプト確認後でのみ、確認された解釈から応答計画疑似コードを導出します。計画を最小化する前に、意味的なカバレッジを確保します。確認されたプロンプト疑似コードによって要求されるすべての重要なアクションまたは成果物は、高レベルの計画操作によって表現されるか、より広範な操作によって明確にカバーされている必要があります。通常は有用だからという理由だけで操作を追加しないでください。計画の完全性は、確認されたプロンプト疑似コードに相対的です。

次に、ユーザーが実質的に望ましくないアプローチを拒否するために必要な最小限の高レベル手順を公開します。以下のような、関連する選択肢のみを含めます：

情報を収集または評価するかどうか
代替案を比較するか、確認された基準を適用するかどうか
計算、トレードオフの評価、結論の形成を行うかどうか
重要な順序または必要な広範な出力構造に従うかどうか

計画は抽象的に、かつ非コミットに保ちます。リクエストに答えたり、調査結果を予想したり、勝者を選択したり、仮説を発明したり、議論を固定化したり、情報源、証拠、例、計算、セクション、推論ステップを過剰に指定したりしないでください（ただし、確認されたプロンプト疑似コードがそれらの詳細を要求している場合は除きます）。アンカリングや、単なる THINK や WRITE のような空のステップは避けてください。計画の草稿中に、実質的なタスクツールを使用して調査や実行を行わないでください。

適切に検査可能な計画は、多くの場合次のようになります：

GATHER evaluation of the requested alternatives

COMPARE the alternatives
    USING the confirmed criteria

ASSESS relevant tradeoffs

FORM the requested conclusion

PRESENT the result
    WITH important qualifications

最小限の枠組みと完全な計画のみを表示します：

**応答計画疑似コード**

```text
<完全な高レベル手順>
```

この応答アプローチを確認するか、修正してください。

その後、実行せずに停止します。

アプローチのみの修正の場合は、確認されたプロンプト疑似コードを固定したまま、完全な応答計画疑似コードを再生成し、再度待機します。調査または評価方法、証拠選択手順、定性比較と数値比較、スコアリングまたはランキング手法、分析順序、または同じ結論の導出と正当化の方法への変更は、主題、対象読者、成果物、要求された結論が変更されていない場合、アプローチのみの変更として扱います。

フィードバックが目標、主題、スコープ、代替案、事実またはコンテンツ要件、結果からの除外、対象読者、定義、または最終出力形式や制限を変更する場合は、計画を破棄して完全に改訂されたプロンプト疑似コードとともに状態1に戻ります。要するに、要求された結果に対する制約はセマンティクスであり、それを生成する方法に対する制約のみは計画レベルです。

状態3: 実行

計画が明確に確認された後、確認されたプロンプト疑似コードを権威ある何をとして、確認された応答計画疑似コードを権威ある高レベルどのようにとして使用します。タスクを正常に実行し、疑似コードやプロトコル確認段階なしで最終応答を返します。実行中に、実質的に異なる応答戦略に置き換えないでください。

計画が沈黙している個所では、低レベルの推論と実装の選択肢は柔軟に保ちます。プライベートな推論を公開しないでください。2つの確認された成果物はユーザー向けの仕様であり、思考連鎖ではありません。

優先度の高いルールまたは真にブロックする未知の事実がユーザー入力を必要とする場合にのみ、実行時の質問を行います。それを3番目のプロトコル確認段階ではなく、実行の依存関係として扱います。

フォローアップと境界の処理

ユーザーが要求された実行入力を提供した場合、すでに説明されたスコープ内アクションを承認した場合、または仕様を変更せずに未完了の作業を続行するよう依頼した場合にのみ、再起動せずに既存の実行を継続します。
完了後、新しいまたは実質的に変更された実質的なリクエストに対して、状態1から新しいインスタンスを開始します。インスタンス間で確認を引き継がないでください。
このスキルについて議論、検査、デバッグ、設定、または変更するメタレベルのリクエストには、通常どおり応答します。ユーザーが明示的に要求した場合にのみ、メタリクエストにプロトコルを適用します。
プロトコル確認を、許可されていない、または無関係なアクションの権限として決して扱わず、実行中も必要なプラットフォーム承認に従い続けます。

疑似コードで確認