| name | feedback-loop |
| description | フィードバックハーネス全体のオーケストレーター。フィードバックの棚卸し・ルール昇華・ハーネス検証・別プロジェクトへの導入を統括する。「フィードバックを整理して」「ルール化して」「一般化して」「ハーネスを点検して」「ハーネスを検証して」「このハーネスを○○プロジェクトに導入して」「フィードバックループを回して」「再実行」「もう一度整理」「前回の結果を更新」「ルールを棚卸しして」「ルールを見直して」「定期審査」などの依頼で必ずこのスキルを使用すること。個別の指摘記録だけなら capture-feedback、作業前のルール適用だけなら apply-feedback を使う。 |
Feedback Loop — オーケストレーター
実行モード: サブエージェント。 各Phaseは単一エージェントの逐次作業であり、チーム通信の利得がオーバーヘッドを上回らないため。Claude Code では Agent、Codex ではサブエージェント機能を使う。データ受け渡しは戻り値ベース(結果収集) + ファイルベース(.feedback/、_workspace/)。
プラグインルートは Codex の PLUGIN_ROOT、Claude Code の CLAUDE_PLUGIN_ROOT の順で解決する。以下のコマンドでスクリプトを呼ぶ場合は ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-}} を使用する。
Phase 0: コンテキスト確認
.feedback/log/ と .feedback/rules.md の現況を確認する- 実行モードを判定する:
- openエントリあり + 整理・昇華の依頼 → キュレーション実行 (Phase 1)
- ハーネス構成の点検・検証の依頼 → QA実行 (Phase 2)
- 別プロジェクトへの導入依頼 → 導入実行 (Phase 3)
- ルールの棚卸し・見直し・定期審査の依頼 → 棚卸し実行 (Phase 4)
- 数字・レポートの依頼(「調子は」「初回通過率」「振り返りの議題」等) → stats/report 実行(
bash "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-}}/scripts/feedback.sh" stats / report --last。振り返り実施後は report --last --mark で基点を更新する)
- 脆弱性監査の依頼(「監査して」「脆弱性チェック」等)、または report で監査期限切れを指摘された → 監査実行(
bash "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-}}/scripts/audit.sh"。ネットワークを使うため Stop フックでは走らない)
_workspace/ に前回レポートあり + 部分修正依頼 → 該当Phaseのみ再実行
Phase 1: キュレーション (フィードバック → ルール)
環境のサブエージェント機能で feedback-curator を呼び出す（定義: agents/feedback-curator.md — 定義ファイルの作業原則を prompt に含める）。Claude Code では Agent と model: "opus"、Codex では継承モデルを使う:
- 入力: openエントリ一覧 + 既存rules.md + ユーザーの直近指摘
- 期待出力: promote/merge/close の実行結果と判断の要約、および次の構造化契約。候補が無い場合も
automation_candidates: [] を出す
automation_candidates:
- candidate: "機械的に検出したい失敗"
evidence: "対象entry IDと再現・反復の証拠"
recommended_check: "追加するlint・テスト・チェックの案"
human_decision: pending
human_decision は承認前には必ず pending とする。
- 完了後、rules.mdの差分と反映提案をユーザーに提示する。提案の採否はユーザーが決める(curator は共有アーティファクトを直接編集しない)
Phase 2: ハーネスQA
環境のサブエージェント機能で harness-qa を呼び出す（定義: agents/harness-qa.md）。Claude Code では Agent と model: "opus"、Codex では継承モデルを使う:
- 入力: 検証対象(直近の変更、または全体)
- 期待出力: 境界面クロス比較のPASS/FAIL/SKIPレポート + 修正案
- レポートは
_workspace/qa_report_{日付}.md に保存する
- FAILがあれば修正し、修正部分のみ再QAする(漸進的QA)
Phase 3: 別プロジェクトへの導入
bash "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-}}/scripts/init.sh" <対象プロジェクトパス> を実行する(導入先にはまだ scripts/ が無い — それを作るのが init.sh である)- 対象プロジェクトの既存 CLAUDE.md / AGENTS.md がある場合、init.shは追記モードで動く — 出力を確認し重複記載があれば整理する
- 導入後、対象プロジェクトで
bash scripts/check.sh を1回実行してスタック検出を確認する
Phase 4: 棚卸し (ルールの定期審査)
更新されないルールは安定するのではなく負債になる。目安は四半期に1回、またはルールが実践と乖離したと感じたとき。
- まず
bash "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-}}/scripts/feedback.sh" stats を実行する — 再発候補と open 滞留が機械的に出る。以下の調査はその裏取りとして行う
- 再発候補は「判定結果」ではなく「調査対象」である。 CLI が出せるのは同カテゴリ・同時期という機械的な条件までで、同じ原則の再発かどうかは本文の意味を読まないと決まらない(添えられた数値は文字の重なりで、読む順のヒントに過ぎない)。候補ごとに出典エントリと候補エントリの本文を実際に読み、次の3つに振り分ける:
- 真の再発 — 同じ原則が守られずに再び起きた。「ルールが効いていない」兆候として feedback-curator の再発原則(
merge --rule での文言強化)を適用する。文章ルールで既に2回失敗しているなら、文言強化より lint・テストなど機械的検出への移行を優先して検討する
- 別主題 — カテゴリが同じだけで原則が異なる。候補から外し、レポートに「偽陽性として除外」と理由を1行残す
- 判断保留 — 情報が足りない。無理に寄せず、確認したい点を明記して次回へ送る
.feedback/rules.md の各ルールについて調べる:
- 昇華日からの経過(出典の日付)と、現在のコード・運用との矛盾(陳腐化)
- ルール本文が主張する仕組み(共通関数・検査・手順)が実際に存在するかをコードで確認する。本文が正しく実装が追いついていない場合があり、文言を実態へ合わせると欠陥を仕様として追認することになる
- 仕組みが存在したら、そこで止めずにその検査が当該欠陥のケースを実際に判定しているかをアサーションまで読んで確認する。ファイル名・冒頭コメントの主張と実際の検証範囲はずれる — テストが「ある」ことと、その欠陥を「捕まえる」ことは別である。判断に迷ったら欠陥を再注入して落ちるか試す(2026-08-22 に、pnpm 単独ケースしか見ていないテストを根拠に lockfile 併存の欠陥を現状追認しかけた)
- 各ルールを「維持 / 文言強化 / 退役候補」の3分類でレポートし、ユーザーに提示する
- 退役はユーザーの裁定後にのみ実行する(rules.md の手編集はしない):
bash "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-}}/scripts/feedback.sh" retire <出典id> --reason "<退役理由>"
rules.md からルールが撤去され、出典エントリ(merge済みの分も含む)が retired に更新され、理由が監査痕跡として残る。
エラーハンドリング
- サブエージェント失敗時は1回リトライ。再失敗したらその結果なしで続行し、レポートに欠落を明記する
- rules.mdの矛盾は削除せず両論併記でユーザーに裁定を求める
テストシナリオ
正常フロー: openエントリ2件がある状態で「フィードバックを整理して」→ Phase 0でキュレーション判定 → curatorが1件をpromote・1件をopen維持 → rules.md差分を提示。
エラーフロー: init.sh に渡した対象パスが存在しない → エラーを報告し、正しいパスをユーザーに確認する(勝手にディレクトリを作らない)。
