coordination

調整

対象ごとに 1 つ起動されるサブエージェントとして実行します。コーディネーターは独自のコンテキスト内でエンゲージメントの状態を保持し、さらにサブサブエージェントへ思考を委譲することはありません。すべてのアクションの前に考えます。

親オーケストレーター（メインセッション）は、このワークフローをインラインで実行してはなりません。メインセッションで P1-P5 を実行していることに気付いた場合は、skills/hackthebox/SKILL.md（または該当するプラットフォームスキル）で起動ステップを省略しており、記録管理の規律が無効になっています。

原則（ルール 0）

まずソースコードを確認します。 実行担当のバッチを実行する前に、アクセス可能なソース（アプリケーションコード、設定、スクリプト、共有コンテンツ）をすべて読みます。答えはすべて、すでに手元にあるデータに含まれています。読まずに推測することが、最もよくある失敗の原因です。

ワークフロー

P0: Ingest scope
 ↓
P1: Recon + read source code → write attack-chain.md → run preflight-checklist
 ↓
┌→ P2: Think — read chain + experiments.md, write 3 hypotheses (≥1 [wildcard]), pick 1-2 to test
│  P2b: Research (conditional) — see reference/creative-research.md
│  P3: Execute — spawn 1-2 executors with CHAIN_CONTEXT [+ RESEARCH_BRIEF]
│  P4: Integrate — materialize each candidate; **validate it now** (interleaved, strict per-finding,
│      fresh blind agents) → CONFIRMED | REJECTED | CURE→re-validate | DROPPED; update chain, revise theory
│      Coverage flips only on VALID (coverage-by-VALID); REJECTED/DROPPED classes stay pending → keep searching
│      No progress 1 batch → consider P2b · goal_attempts ≥ 3 on any conceptual goal → P4b
└─ loop (max 30 experiments; mandatory skeptic at experiments 5, 15, 25)

P4b: Reset — re-read all recon + source + chain. Creative Research (mandatory). Fresh theory.
P5: Engagement-thoroughness validation + Report (validated/ = VALID/REPAIRED only; drop-entirely, no gaps section)

手順

1. 偵察 + ソースコード — アクセス可能なコードをすべて読みます（formats/reconnaissance.md を参照）。事前チェックリスト（reference/preflight-checklist.md）を実行します。
2. 検討 — attack-chain.md に仮説を 3 つ書き、そのうち 1 つ以上に [wildcard] のタグを付けます。起動する仮説を 1～2 個選びます。
3. テスト — バッチごとに実行担当を 1～2 個起動し、次のバッチに進む前に結果を統合します。
4. 検証（並行して実施） — INTEGRATE が候補を生成したら、即座に新しいブラインドエージェントで検証します（発見事項ごとに厳密な修正／却下ループを実施し、CONFIRMED | REJECTED | CURE | DROPPED のいずれかにします）。ループの最後に、エンゲージメント全体を対象とする検証担当を実行します（reference/validator-role.md を参照）。
5. 報告 — {OUTPUT_DIR}/artifacts/validated/ にある VALID／REPAIRED の発見事項（そのすべて。これは処理上保証されています）を、formats/transilience-report-style/SKILL.md に従って Transilience PDF にまとめます。

attack-chain.md

{OUTPUT_DIR}/attack-chain.md。バッチごとに更新します。セクションは services、surface、theory（仮説 3 つ + 選択した仮説）、tested、next です。箇条書きで、最大 50 行とし、古い項目は 1 行にまとめます。

記録管理

experiments.md の台帳、tools/ のログ、EXPERIMENT_ID の注入、概念目標のカウントについては、reference/bookkeeping.md を参照してください。

創造的な調査（P2b）

発動条件：P4b のリセット（必須）、いずれかの目標で goal_attempts ≥ 3、新しいエラークラス、ソースコードが読み取れない、すべての実行担当が否定的な結果を返した、P2 で仮説がない、1 バッチ進展がない。reference/creative-research.md を参照してください。ほとんどのバッチでは P2b を省略します。

起動

役割ごとのコピー＆ペースト可能な起動パターンについては、reference/spawning-recipes.md を参照してください。コンテキストの契約については reference/context-injection.md を、役割の境界については reference/role-matrix.md を参照してください。

役割

役割	ファイル	コンテキスト	タイミング
実行担当（探索）	reference/executor-role.md	攻撃チェーン全体 + スキル	偵察／広範な調査
実行担当（悪用）	reference/executor-role.md	攻撃チェーン全体 + スキル + シナリオ	理論を確認した後
懐疑担当	reference/skeptic-role.md	experiments.md + 偵察情報（攻撃チェーンなし）	experiments が 5、15、25 件に達した時に必須
検証担当（発見事項）	reference/validator-role.md	証拠のみ（ブラインド）	並行して実施 — 候補が生成された瞬間ごとに実施し、修正ラウンドごとに新しい担当を起動
実行担当（修正）	reference/executor-role.md	名前を指定した failed_checks + missing_evidence のみ（理論なし）	DEMOTED 判定の場合、再検証の前に実施
検証担当（エンゲージメント）	reference/validator-role.md	OUTPUT_DIR のみ（ブラインド）	ループの最後に 1 回実施

ルール

1. 自律的に動作すること。 コーディネーターは AskUserQuestion を呼び出してはいけません。資格情報が不足している場合は、python3 tools/env-reader.py を実行してください。NOT_SET が返された場合は、status=BLOCKED を設定して明確なブロッカーを出力し、処理を終了してください。質問するのは親オーケストレーターの役割です。
2. 行動する前に考えること。 各バッチの前に、攻撃チェーンの仮説を3つ（ワイルドカードを1つ以上含む）attack-chain.md に記述してください。却下した仮説も記録します。これが探索木になります。
3. 各バッチのエグゼキューターは最大1～2つです。 偵察では、より多く使用できます。
4. チェーンのコンテキストと、具体的な PATT_URL をエグゼキューターに渡してください。 PATT マップ全体は渡しません。
5. 実験の上限は30回です。
6. 概念上の目標に対する goal_attempts が3以上になったら、P4b リセットを実行します。 文字列としての手法ではなく、目標ごとに数えます。「この証明書で認証する」という目標を追う PKINIT 証明書のバリエーションが5つある場合、これは1つの目標に対する5回分として数えます。goal 列については reference/bookkeeping.md を参照してください。
7. 実験5、15、25回目には、必ず懐疑的な検証役を設けてください（reference/skeptic-role.md を参照）。
8. 出力はすべて OUTPUT_DIR に保存します。
9. 複数のフラグがあるエンゲージメントでは、フラグを順番に進めてください。 まずユーザー foothold を確保します。通常、そこから root への経路が続きます。
10. 部分的な完了を成功状態として扱ってはいけません。 複数のフラグがあるエンゲージメントは、すべてのフラグが提出されるまで未完了です。status=FAILED_partial は一時的なマーカーであり、最終的な結果にはなりません。
11. フェーズ3（スキルの更新＋Slack＋キュー）は、親オーケストレーターのみが実行します。 コーディネーターは PHASE3_SUMMARY を出力して終了します。
12. ライブラリ内部の調査にはソースを使用します。 ライブラリ API（Impacket、ldap3、pyasn1）を使用する Python コードを書く前に、ソースを読んでください。CLI ツール（secretsdump.py、ticketer.py、getST.py）を優先してください。
13. バックグラウンドコマンドの実行規律を守ってください。 トンネル／リレー／リスナーを起動する前に、そこから得られる具体的な結果を明示してください。
14. レポートの必須条件。 検証済みの所見がある場合は、Transilience PDF レポートが必須です。formats/transilience-report-style/pentest-report.md を読んでください。
15. 検証の完全性を確保してください。 バリデーターの実行後、検証済みの各所見に evidence/validation/validation-summary.md があることを確認してください。証拠がないものにはフラグを立てます。

トークンの使用規律

• 内部出力（チェーン、ログ、レポート）には、散文ではなく箇条書きを使用します。
• エグゼキューターへのプロンプトには、関連するスキルファイル1～2個と、具体的な PATT_URL を含めます。
• attack-chain.md は最大50行、bookkeeping はミッションのトークンの最大10％に抑えます。
• ユーザー向けの出力（レポート、要約）は詳細に記述します。

参照資料

reference/principles.md · reference/preflight-checklist.md · reference/role-matrix.md · reference/bookkeeping.md · reference/spawning-recipes.md · reference/context-injection.md · reference/creative-research.md · reference/executor-role.md · reference/skeptic-role.md · reference/validator-role.md · reference/VALIDATION.md · reference/ATTACK_INDEX.md · reference/OUTPUT_STRUCTURE.md · reference/GIT_CONVENTIONS.md · formats/INDEX.md