cawplan-internal-qa-coding-humaninputs

CawPlan 内部 QA — 人間の入力を 1 件分類する

タスク

content（必須）と、任意でその入力に対応する assistant_message（このターンの AI の返信）および prev_message（直前のアシスタントの返信の最後の段落。直前の人間のターンではありません）が与えられたら、references/CATEGORY_TAXONOMY.md と references/TOPIC_TAXONOMY.md を使って分類します。CawPlan API への呼び出しはなく、cawplan の認証も不要です。これは検索ではなく、uid.core-product の現在の分類ルールに基づく純粋な推論チェックです。

ワークフロー

1. このセッションですでに読んでいない場合は、references/CATEGORY_TAXONOMY.md、references/TOPIC_TAXONOMY.md、および references/PRODUCTION_CLASSIFY_PROMPT.md（本番環境の完全なスナップショット）を読みます。キュレーション済みのドキュメントとスナップショットに相違がある場合は、スナップショットに従います。
2. new_feature は最後の手段となるトピックです。 複数のトピックが当てはまりそうな場合は、これを選ばず、より具体的なトピックを優先します（何かがどのように表示されるかに関する内容はすべて design_ui。新しいノード／パネル／画面であっても、何を表示するかが依頼内容なら同様です。配線や、外部システムが保持する必要のあるフィールドは integration_api、そのほか security、infra、refactor、bug、investigation）。新しい画面やフィールドであることだけを理由に new_feature にすることはありません。
3. assistant_message は、本番環境と同じ方法で、読み取る前に前処理します。 切り詰め前の生テキストをそのまま使って判断しないでください。
   • リテラルの \n／\t エスケープと改行コードを、実際の空白に正規化します。
   • [REDACTED] プレースホルダー（アップロード時の秘匿化。保持すべき [Done]／[QA Testing] などの実際の角括弧付きテキストではありません）を削除します。
   • 各段落内の Markdown のノイズ（表の罫線、--- の水平線、見出し／太字のマーカー、絵文字）を削除します。
   • 空行で段落に分割し、最初の3段落だけを残します。
   • 段落を \n\n で結合し、約1200ルーンで上限を設けます（超える場合は先頭を切り詰めて ... を付けます）。これは ClassifyAssistantSnippet／AISessionClassifyAssistantMaxRunes を再現するものです。
4. 提供されている場合は、prev_message も前処理します（手順2と同じ段落分割と段落ごとのサニタイズを行いますが、最後の段落だけを使用し、約500ルーンを上限とします）。これは ClassifyPrevAssistantTail／AISessionClassifyPrevMaxRunes を再現するものです。省略されている場合は、prev を空として扱います。「commit & push」「直接改」などの短い追加指示は、これがないと曖昧な場合があります。
5. 本番環境とまったく同じようにカテゴリを判定します（CATEGORY_TAXONOMY.md を参照）。
   • 主なシグナル：content。 必ず最初に読みます。
   • prev： 短く単独の追加指示（通常は漢字12文字以下、または英単語6語以下）に限り、decision（人がアシスタントの提案した具体的なアクションを名指しする、または繰り返す）と approval（一般的な許可：「直接改」「できます」「do it」）を区別するためにのみ使用します。それ以外のカテゴリでは prev を使用しないでください。また、以前の人間の要件として扱わないでください。
   • assistant_message： content が意図を示す語句のない単独の引き継ぎ（URL、ファイルパス、スクリーンショットのパス、ログのパス）である場合に限り、カテゴリ判定に使用します。アシスタントがすでに行ったことや確認したことからカテゴリを推測しないでください。
6. タクソノミーの中から明確に当てはまるカテゴリをすべて判定し、参考ドキュメントの優先順位（高い順）に並べます。正確な snake_case の末端カテゴリ名（direction_constraint、rejection_rollback、question_clarification、other_meta など）を使用し、direction／rejection／question／other のように短縮しないでください。リストを埋めるためだけに副次カテゴリを追加しないでください。当てはまるカテゴリが1つだけの場合、リストの要素も1つです。
7. 並べ替えたリストの最初の要素を主要カテゴリとします。
8. content と前処理済みの assistant_message だけを使い、TOPIC_TAXONOMY.md からトピックを必ず1つだけ選びます。トピック判定に prev_message は絶対に使用しないでください。ASKING と CHANGING の区別、単独の commit & push → git_ops、および参考ドキュメントにある Slack 関連の強いヒントを適用します。
9. 短い topic_reason の文を1つと、TOPIC_TAXONOMY.md に従った topic_confidence（0.0～1.0）を、本番環境の形式に合わせて記述します。

出力

報告内容：

• category — 主カテゴリ（categories の最初の要素にあたる単一の値）。
• categories — 優先順位順のカテゴリ一覧（単一の値の場合もあります）。
• topic — TOPIC_TAXONOMY.md の17トピック一覧から選んだ値を1つ。
• topic_reason — トピックを選んだ理由を説明する短い文。
• topic_confidence — 0.0～1.0の浮動小数点数（トピック選択の確信度）。
• 主カテゴリを選んだ理由を説明する短い文。判断の根拠となった content、prev_message、または準備済みの assistant_message の具体的なフレーズを引用します。これにより、呼び出し側がすでに保存されているクラウドカテゴリなどと異なる判断をした場合でも、不透明にならず、確認できるようになります。

参考資料

• references/PRODUCTION_CLASSIFY_PROMPT.md — uid.core-product からエクスポートされたプロンプト全体
• references/CATEGORY_TAXONOMY.md — 厳選されたカテゴリの振り分けと例
• references/TOPIC_TAXONOMY.md — 厳選されたトピックの振り分けと例

プロンプト公開後の同期スナップショット：

node skills/cawplan-internal-qa-coding-humaninputs/scripts/sync-classify-prompt-from-core-product.mjs