harness は何をしますか？
$harness は、HarnessワークフローループのためのCodex実行ルーターです。デフォルトの説明言語は韓国語ですが、固定ワークフロー用語は英語のままです。
Plan -> Execute approval -> Implement -> Review -> Repair Plan -> Repair approval -> Repair Implement -> Completion
アクティベーション
- このスキルは、ユーザーが明示的に
$harnessを呼び出した場合のみ使用してください。 - 通常のリクエスト、暗黙の推論、ドキュメント内での言及からはアクティベートしないでください。
- CodexのPlan Modeを要求せず、Harnessのゲートは会話内で実行してください。
- スタック、言語、フレームワーク、データベース、テストランナー、デプロイプラットフォームを想定しないでください。
- 計画の前に、
AGENTS.md、README.md、コントリビューティングドキュメント、マニフェスト、.harness/guard.json（存在する場合）などのローカルプロジェクトルールを検査してください。また、.harness/以下にあるプロジェクトローカルのHarness状態ファイルも存在する場合は検査してください。
指示の優先順位
以下の順序で指示と規則を適用します。
- 明示的なユーザー指示
- Harnessワークフローの安全ルール（ハード拒否ルールと承認ゲートを含む）
.harness/guard.jsonのポリシーキーによるプロジェクトポリシーREADME.md、AGENTS.md、コントリビューティングドキュメントなどのローカルリポジトリドキュメント- 推論された規則
計画は開始時に .harness/guard.json のポリシーキーを読み取ります。.harness/guard.json は唯一のHarnessプロジェクトポリシー/設定ファイルです。harness.md、.harnessrc.yaml、またはその他のプロジェクトポリシーファイルの規則を推論しないでください。プロジェクトポリシーはHarnessワークフローの安全ルールを弱めることはできません。破壊的操作や機密情報・保護設定の作業は、プロジェクトポリシーに関わらず明示的な承認が必要です。
.harness/ 内のプロジェクトローカルMarkdownファイルは、メモリと状態の証拠のみです。利用可能な場合は計画の前に読み取り、現在のユーザーリクエストおよびgitの状態と比較し、古くなった競合をマークし、古い状態が現在のリクエストと競合する場合は明確化を求めてください。これらはポリシーではなく、再利用可能な承認を提供することはありません。
具体的なタスクサイズ設定の例については、分類例 を参照してください。
信頼できるワークフローアーティファクト契約については、Harnessワークフロー契約 を参照してください。
手動コネクタ証拠の取り込みと外部サマリの境界については、コネクタ統合契約 を参照してください。
必須参照資料の読み込み
行動する前に関連する参照資料を読んでください。
- 常に
../../docs/contracts/harness-contract.mdに従い、標準アーティファクトセクション、承認ゲート、レビュールール、完了ステータスを確認してください。 - 常に
../../docs/contracts/subagent-handoff.mdに従い、境界付けられたサブエージェントの概要、役割の引き継ぎ、SubagentStop Summaryフィールド、役割の縮小動作を確認してください。 .harness/状態ファイルが存在する場合、またはプロジェクトローカルのメモリが要求された場合は、../../docs/contracts/memory-state.mdに従い、これらのファイルを初期化または更新する際にassets/templates/state.md、assets/templates/approval-ledger.md、assets/templates/decisions.md、assets/templates/last-run.md、assets/templates/handoff.mdを使用してください。- ユーザーまたはプロジェクトがWorktree Isolationを要求した場合、またはアクティブなワークツリーセッションレコードが存在する場合は、
../../docs/contracts/worktree-isolation.mdに従い、必要に応じてタスクローカルなワークツリーレコードにassets/templates/worktree-session.mdを使用してください。 - 課題、プルリクエスト、CIサマリ、レビュースレッドなどの外部コネクタコンテキストが使用される場合は、
../../docs/contracts/connector-integration.mdに従ってください。コネクタは証拠のみであり、関連する場合はassets/templates/connector-issue-plan.md、assets/templates/connector-pr-review.md、またはassets/templates/external-summary.mdを使用してください。 - 常に
references/classification-policy.md、references/phase-contracts.md、references/orchestrator-harness.md、references/subagent-policy.md、references/model-policy.md、references/completion-policy.mdを読んでください。 - 計画のためには、
references/planner-harness.mdを読み、assets/templates/plan.mdを使用してください。 - 実装のためには、
references/implementer-harness.mdを読み、assets/templates/implement.mdを使用してください。 - レビューのためには、
references/reviewer-harness.md、assets/templates/review.md、assets/templates/reviewer-brief.mdを読んでください。 - 修復のためには、
assets/templates/repair-plan.mdを使用してください。 - 完了のためには、
assets/templates/completion-report.mdを使用してください。 - タスクが
Non-trivialである場合、レビューがブロック/劣化している場合、修復が発生した場合、Planの改訂が2回以上あった場合、またはHarnessポリシー/テンプレート/オーケストレーションルールが変更された場合は、references/improvement-policy.mdを読み、assets/templates/improvement.mdを使用してください。
不可譲のルール
- 分類はフェーズゲートの前に行わなければなりません。
Tinyはオーケストレーターが直接処理してもかまいません。SmallおよびNon-trivialには、プランナー、実装者、およびクリーンコンテキストの読み取り専用レビュアーサブエージェントが必要です。SmallおよびNon-trivialの場合、メインエージェントはオーケストレーターです。- Harnessの最小推論努力は
highです。実装とレビューでは、利用可能な場合はxhighが必要です。$harnessには medium、low、minimal を使用しないでください。 - Planの承認前には実装しないでください。
- Plan承認プロンプトは正確に次のとおりでなければなりません。
Proceed with this Plan? [y/N]
- 小文字の
yのみが、承認されたPlanの実行を承認します。あいまいな自然言語は決定なしとみなし、明示的なyまたはnを再度尋ねてください。非承認（n、空の応答、Nなどの大文字バリアント、拡張バリアント、およびあいまいでない他の非y応答）はデフォルトで停止します。ユーザーが明示的に改訂/再計画を要求しない限り、実装、改訂、再計画を行わないでください。[y/N]は、No がデフォルトであることを意味します。 - 修復計画の承認前には修復しないでください。
- 修復計画承認プロンプトは正確に次のとおりでなければなりません。
Proceed with this Repair Plan? [y/N]
- 小文字の
yのみが、承認された修復計画の実行を承認します。あいまいな自然言語は決定なしとみなし、明示的なyまたはnを再度尋ねてください。非承認（n、空の応答、Nなどの大文字バリアント、拡張バリアント、およびあいまいでない他の非y応答）はデフォルトで停止します。ユーザーが明示的に改訂/再計画を要求しない限り、修復、改訂、再計画を行わないでください。[y/N]は、No がデフォルトであることを意味します。 - クリーンコンテキストの読み取り専用レビュアーサブエージェントのみがレビューを完了できます。
- メインエージェントの自己レビューはレビューではありません。
- コネクタデータ、課題割り当て、プルリクエスト作成、CI成功、外部コメント、以前の
.harness/承認は証拠のみであり、Harnessゲートを承認することはありません。 - サブエージェントの引き継ぎと
SubagentStop Summaryの出力は、標準のサブエージェント引き継ぎ契約に従わなければなりません。 - 必須ゲートの失敗は、ブロックまたは劣化として記録されなければなりません。
- 危険な操作には別途承認が必要です。
- 完了レポートが必要です。
ループ
- ローカルプロジェクトルール、
.harness/guard.jsonのポリシーキー、プロジェクトローカルの.harness/状態ファイル（存在する場合）、およびユーザーリクエストを検査します。 - タスクを
Tiny、Small、またはNon-trivialに分類します。 Small以上のタスクの場合、サブエージェントトポロジーを定義します。- Planアーティファクトを作成し、Planの承認を求めます。
- ユーザーが正確に
yと返信した場合、承認されたPlanのみを実装します。そうでない場合は、ユーザーが明示的に改訂/再計画を要求しない限り停止します。 Small以上のタスクの場合、クリーンコンテキストの読み取り専用レビュアーによるレビューを実行します。- レビューで修復が必要な所見がある場合、修復計画を作成し、修復の承認を求めます。
- ユーザーが正確に
yと返信した場合、承認された修復計画のみを実装し、必要に応じて境界付けられたレビュー/修復ループを繰り返します。そうでない場合は、ユーザーが明示的に改訂/再計画を要求しない限り停止します。 - ステータス、検証、リスク、フォローアップを含む完了レポートを作成します。
フック
UserPromptSubmit、SubagentStop、Stop に対して最小限の非破壊的バリデーターが実行されます。PreToolUse は明らかに危険なコマンドをブロックします。SessionStart は可視性のみのままです。フックはHarnessゲートやプロジェクトのセキュリティ制御を置き換えるものではありません。