ntaksh42 Harness Design — エージェント/ハーネス/Loop設計の診断・設計支援
AI出力向上のためのハーネスエンジニアリングの体系的知識を使い、エージェント設計を 診断（レビュー） または 新規設計 する。一次情報源はAnthropic公式エンジニアリング記事・ OpenAI GPT-5ガイド・マルチエージェント研究に基づく。
モード判定
ユーザーの依頼から、まず2モードのどちらかを判定する（両方なら設計→診断の順）。
- 診断モード: 既存のプロンプト/エージェント/ハーネス/ループ設計が対象にある。 「レビュー」「診断」「改善点」「なぜ失敗する」「もっと良くしたい」等。
- 設計モード: まだ作っていないものを作りたい。 「作りたい」「設計して」「どう組むべき」「どんな構成がいい」等。
判定が曖昧なら AskUserQuestion で1問だけ確認する。
共通の進め方
- 対象を把握する（コードがあれば必ず読む。プロンプト・ツール定義・ループ構造・eval有無を確認）
- 要件を1〜3点に絞る（タスクの時間軸＝数分か数時間か、並列性、外部I/Oの有無、信頼境界）
references/checklist.mdの観点で評価/提案する（全部を機械的に並べず、対象に効く観点を選ぶ）- 指摘は具体・実装可能に。各指摘に「現状→問題→具体的修正」を付ける。
- 推奨は survey でなく 推奨案を1つ 出す（CLAUDE.md の行動指針に従う）。
診断モードの出力形式
## 診断: <対象>
要件の理解: <時間軸/並列性/信頼境界 を1-2行>
### 重大（出力品質・信頼性に直結）
- [観点] 現状 → 問題 → 修正
### 改善（効率・コスト・保守性）
- [観点] 現状 → 問題 → 修正
### 良い点（維持すべき設計）
- ...
ハルシネーション禁止。コードを読んでいない指摘はしない。「○○が無いように見える」は 確認してから書く。
設計モードの出力形式
## 設計: <作りたいもの>
### 1. ループパターン
推奨: <ReAct / Plan-Execute / Reflexion混成 / マルチエージェント> — 理由
### 2. コンテキスト戦略
<compaction / note-taking / just-in-time検索 のどれを軸にするか> — 理由
### 3. ツール設計
<必要なツールと、命名・粒度・トークン効率の方針>
### 4. 検証ループ / eval
<生成と評価の分離、trajectory vs output、停止条件>
### 5. 状態・メモリ
<永続化の方法、セッション再開、ハンドオフ成果物>
### 6. 権限・セキュリティ
<lethal trifecta 該当チェック、Rule of Two、human-in-the-loop境界>
### 最小構成での第一歩
<まず作るべき最小ハーネス。"最も単純に機能するもの"から始める>
重要な設計原則（常に効かせる）
- ハーネスは暫定的補完: モデルができないことだけを補う。過剰な足場を組まない。
- 最も単純に機能するものを採用: マルチエージェントは単一の~15倍トークン。並列独立の 高価値タスク以外では単一エージェントを推奨する。
- 生成と評価を分離: 自己評価は甘くなる。
- コンテキストは希少資源: context rot を避け、最小限の高シグナルトークンを設計する。
- 構成変更（prompt/param/topology）はモデル交換と同等の効果を持つ。
詳細な観点チェックリストと一次情報源は references/checklist.md を参照（必要時に読む）。