hrt-adversarial-authoring

hrt-adversarial-authoring

コンテキストをまたいだ敵対的な作成：1つのサブエージェントが草案を作成し、さらに2つのサブエージェントが、それぞれ作成者の推論を知らず、与えられた入力のみをもとに、直交する2つの観点から草案に異議を唱えてから承認します。

このスキルは2つの呼び出し元で共有されます。呼び出し時の指示では、作成する成果物を必ず指定してください。この選択によって、草案の内容、2つのレビュー用チェックリスト、および以下の解決対象が決まります。呼び出し元が異なっても、プロセスの他の部分は変わりません。

パラメーター（呼び出し元が設定）

• artifact：specs または design。（proposal はここではレビューしません。根拠となるのはユーザー自身のインタビュー回答であり、hrt-artifact-lint とユーザーによる確認によってチェックされます。）
• content_sections：草案作成サブエージェントが作成するセクション。
  • specs：proposal の Capabilities セクションに記載された機能ごとに1つの spec ファイルを作成します。specs フェーズのフォーマットルールに従い、#### Scenario に WHEN/THEN の内容を含む ### Requirement ブロックを記述します。
  • design：design フェーズのフォーマットルールに従い、Context、Goals/Non-Goals、Decisions、Shape / Seams（変更によって呼び出し可能なコードが追加される場合）、Risks/Trade-offs、Migration Plan、Open Questions を記述します。
• grounding_inputs：草案作成サブエージェントが参照してよい成果物。
  • specs：proposal.md、openspec/specs/ にある既存の specs（機能名の参考用）。
  • design：proposal.md、specs/**/*.md。

プロセス

1. 草案作成。 指定された artifact の grounding_inputs と content_sections のみを渡して、サブエージェントを起動します。作成するのは草案のみで、自己レビューや曖昧さを残すプレースホルダーは含めません。文章は、後から適用するのではなく、執筆時点で plain-language-writing スキルの ARTIFACT ルールに必ず従います。出力形式：## Draft（成果物の内容）に続けて、## Author Notes（執筆中に作成者が記録した未解決の質問や前提）を記述します。

2. Lint。 オーケストレーションを行うセッションが hrt-artifact-lint スキルを実行し、すべての ERROR を直接修正します（決定的で、正しい修正が1つずつあります）。これにより、レビュー担当者は grep/count の構造に注意を払わずに済みます。WARN 行はコンテキストとしてレビュー担当者に渡します。

3. レビュー — 2つのサブエージェントがそれぞれ直交する観点からレビューし、同時に起動します。互いの出力も Author Notes も参照しません。 各サブエージェントには lint 後の草案と、作成者に渡されたものと同じ grounding_inputs を渡します。ただし、## Author Notes に記載されている内容以外の作成者の推論は渡しません。担当範囲を守ってください。Critic は内容、論理、意思決定の質を担当し、Auditor は構造に関する判断を担当します。lint は数と形式を担当します。重複したり、担当範囲を越えたりしないでください。

   Thin-design のショートカット（artifact: design のみ）。 lint 後の草案で Shape / Seams の本文が厳密に "no new code surface" であり、かつ Decisions の項目が最大1つで、却下した代替案の理由説明を含まない場合は、Destructive Critic のみを実行し、Structural Auditor は省略します。このように内容が薄い design.md には、Auditor の判断チェックの対象がありません。合意による自動解決には2人のレビュアーが必要なため、この場合は Critic の指摘事項がすべてユーザーに提示されます。このショートカットは specs には適用されません。 結果ゲート（両レビュアー）。 指摘を ## Required Changes に含めるのは、未修正のままの場合に読者や実装者が具体的に直面すること（主張の誤読、ビルドの阻害、やり直しの強制、未テストの要件）を明示している場合に限ります。そのような結果を示さない批評（「前提が薄い」「読みにくい」など）は ## Suggested Improvements に回します（ブロッキングではなく、項目ごとの質問もありません）。

   • 破壊的批評者（内容と論理。チェックリストは artifact によって異なります）。各指摘では、事実が真であればその指摘を覆す具体的な事実を1つ挙げてください。それがない指摘は、報告できる段階にありません。
     • specs：すべての主張は proposal.md にたどり着けますか？根拠となる入力で裏付けられていない主張はありませんか？スコープがそこから逸脱していませんか？著者は自信過剰だと仮定し、妥当性を確認するのではなく、欠落や誤りを探してください。前提は proposal.md ですでに確定しています。再び議論の対象にしないでください。実際に前提に誤りがある場合は、## Risks and Open Questions に記載し、Required Changeにはしません。
     • design：これは追跡可能性の確認ではなく、意思決定の質を評価するレビューです。Decisionが正しいかどうかは、その根拠が妥当かどうかで決まり、ソース文書との照合では決まりません。前提、問題、目標は上流ですでに確定しています。再び議論の対象にしないでください。実際に前提に誤りがある場合は、## Risks and Open Questions に一度だけ記載します。Decisionごとに、妥当な代替案が正当な理由なく退けられていませんか？Risk/Trade-offごとに、緩和策は実際に十分ですか？想定される障害モードが漏れていませんか（事前検証：本番で失敗すると仮定し、原因をさかのぼって考えます）。seamごとに、テストする境界として適切ですか？テストが実装の詳細に依存していませんか？既存のより上位の境界で、すでにカバーされていませんか？新しいモジュールまたは seam を作るDecisionについては、著者が検討していない構造的に異なる形を1つ挙げ、それが劣るかどうかを述べてください。そのような代替案がないDecisionについては、指摘は不要です。
   • 構造監査者（リンターでは判断できない構造上の判断を確認します。ハッシュタグ数、チェックボックス形式、セクションの有無、Covers: の存在は再確認しません。これらは手順2のlintが担当します）。確認するまでは欠落があるものとみなし、何も見つからないのはまれであるべきです。監査者による指摘はすべて UNANCHORED（意図の解釈に基づくもの）です。
     • specs：すべての要件は本当にテスト可能ですか？測定可能な動詞、単位、または条件を備え、単に記載されているだけでなく、意味のあるものですか？すべての #### Scenario は、本当に WHEN/THEN の動作を示していますか？それとも、実装の詳細をシナリオのように見せていますか？MODIFIED要件には、更新後の内容がすべて含まれていますか？それとも詳細が欠落していますか？
     • design：空欄または N/A の Migration Plan は、本当に該当しないものですか？それとも実際に必要なデプロイやロールバックの手順を隠していますか？各Decisionの「検討した代替案」の根拠には、実際の考察がありますか？それとも単なる代替案ですか？「新しいコード面なし」というスキップ行は、本当にコード変更がない場合のものですか？各seamのシグネチャは、実在する境界を示していますか？それとも作り上げられたものですか？seamは mattpocock の to-spec ルールに従います。テストは利用可能な最上位のエントリーポイントに接続し、seamは少ないほどよいです（理想は1つ）。内部の協調コンポーネントをテストするseamや、1つの上位seamでカバーできる複数のseamを指摘してください。
   • 各レビュアーの出力形式：## Review Summary、## Required Changes（各項目に、grep/countを伴う ANCHORED または UNANCHORED のタグを付けます。監査者の指摘はすべて UNANCHORED です。各項目は結果ゲートを通過する必要があります）、## Suggested Improvements（ブロッキングではない改善案、および結果ゲートを通過しない実際の指摘）、## Risks and Open Questions。

4. 解決。 オーケストレーションを行うセッションでは、両レビュアーの Required Changes を統合します（同じ場所に対する同じ指摘のみ重複としてまとめます。LLMの判断でレビュアー間の見解を裁定してはいけません）。統合した各指摘を次のように分類します。

   • 自動解決（ユーザーに確認せず直接修正）できるのは、次のいずれかに該当する場合です。（a）ANCHORED — 修正前に自分でgrep/countを再実行して確認します。（b）両レビュアーが独立して同じ指摘を挙げた（実際の重複）場合 — 2つの独立した観点からの一致は、単独のレビュアーによる「これは安全です」という自己申告の代わりになります。変更内容を記録してください。
   • 個別の回答が必要なのは、それ以外の指摘のうち、次のいずれかに該当するものです。（i）proposal.md ですでに確定したスコープを変更する。（ii）一方向の変更である（データ移行や破壊的なスキーマ変更、保存データの削除、公開済みAPIまたはイベント契約の変更、他のコードが読み取る設定やフラグの削除、手作業で元に戻す必要がある手順）。（iii）重大度が高いセキュリティ上のトレードオフである。該当するものはすべて1つのメッセージにまとめて提示します。各項目では、まずトレードオフを中立的に述べ、次に推奨案を示します。ユーザーが推奨案を見る前にトレードオフを検討できるようにしてください。ユーザーは各項目に個別に回答します。単なる「ok」ではこれらを了承したことになりません。確認または調整された内容だけを適用してください。
   • ダイジェスト：それ以外のすべて（単独のレビュアーによるその他すべてのUNANCHOREDの指摘、Suggested Improvements、Risks and Open Questions、Author Notes）です。個別の回答が必要な指摘を解決した後、1つのメッセージで提示します。各項目には、推奨する解決策とその理由を1行で記載します。「ok」で全項目が了承されます。例外がある場合は、ユーザーに明示してもらいます。Suggested Improvements は重要度の高い順に最大5件まで提示し、残りがある場合はその件数を伝えてください。片方のレビュアーだけが挙げたUNANCHOREDの指摘は、どれほど機械的に見えても自動解決しません。「ok」を待つため、ダイジェストに含めます。
   • 両方のメッセージは、plain-language-writing スキルのCOMMSルールに従う必要があります。
   • 「後回しにする」／「逸脱を受け入れる」は、実際の代替案ではありません。修正しない場合の選択肢がそれしかない指摘は、ユーザーの判断を求めるべきではありません。適切な修正案がすでにあっても、経験豊富な著者が別の対応策を選ぶ可能性があるなら、その指摘を自動解決できるわけではありません。
   • design では、既存の方針どおり specs よりもユーザーの判断を優先します。スコープに近いANCHOREDの指摘も同様です（これらは個別の回答が必要です）。意思決定の質に関する判断の信頼性は、決定論的なlintチェックより明らかに低いためです。破壊的批評者によるseamの境界の質に関する確認はUNANCHOREDであり、ダイジェストに回します。ただし、すでにテストが依存しているseamを変更する場合は、個別の回答が必要です。

5. 最終化。 Required Changes の解決後、フェーズのテンプレートを使用して、（必要に応じて調整した）ドラフトから成果物を作成します。 dark.md が存在する場合、呼び出し元はステップ 4 でユーザーに表示されるはずの指摘に hrt-dark-mode-routing スキルを適用します。

フォールバック

サブエージェントを起動できない場合は、敵対的なオーサリングを完了できなかったことを伝え、シングルパスのオーサリングを続行するかユーザーに確認してください。レビュー手順を黙って省略してはいけません。hrt-artifact-lint を実行できない場合は、そのチェックを手作業で構造監査担当者が行います。その旨を伝え、省略してはいけません。