capture-feedback

name	capture-feedback
description	人間のレビュー指摘・修正・ダメ出しをフィードバックログに記録するスキル。ユーザーがエージェントの成果物を修正した、指摘した、「こうして」「次からはこうやって」「これは違う」と言った、方針を訂正した、あらゆる場面で必ずこのスキルを使用すること。「フィードバックを記録して」「これ覚えておいて」「同じミスをしないで」という明示的依頼でも使用する。うまくいった措辞・進め方・タスク分解など、次回も再現したい成功パターンの記録にも使用する。記録の修正・追記・再分類の依頼にも対応する。

Capture Feedback

人間の指摘を .feedback/log/ に構造化して記録する。記録は昇華(promote)の原料であり、記録されない指摘は次のセッションで失われる。だから指摘に気づいたら作業の途中でも即記録する。

手順

1. 指摘から「何が問題とされ、どう直すべきとされたか」を1文の要約に整理する。成功パターンなら「何がうまくいき、次回どう再現するか」を要約する
2. 誤った出力・行動に関する指摘は、次の基準で根因を1つ選び、--detail に 根因: <分類> と記録する。根因は責任追及ではなく、再発防止策の反映先を決めるための分類である:
   • 文脈欠落: 判断に必要な事実・規約・バージョン情報が、判断時に読み込まれた文脈へ存在しなかった。情報が参照可能だったのに調べなかった、または提示済み情報を見落とした場合は含めない
   • 指示欠陥: 期待する結果、制約、受け入れ条件、手順が指示で欠落・曖昧・矛盾しており、通常の品質基準だけでは一意に判断できなかった。「個別の禁止ルールがなかった」という理由だけで通常の設計・実装ミスをここへ入れない
   • 実行誤り: 必要な文脈と十分に明確な指示があったのに、見落とし、指示違反、推論ミス、実装ミスが起きた。単発の失敗は、まずこの分類を検討する
   • モデル限界: 十分な文脈、明確な指示、利用可能なツール、妥当な再試行を与えても、同種の失敗を安定して避けられない。単発の見落としだけでは選ばず、再現または反復の証拠を必要とする
   • 未判定: 証拠が不足している、または複数の原因を切り分けられない。無理に他の分類へ寄せず、必要な追加確認を detail に残す
3. signal は根因と分けて決める: 誤った出力・行動は根因にかかわらず failure、不足していた前提情報の提供は context、有効だった指示の言い回しは instruction、有効だった進め方・タスク分解は workflow。--signal <種> で明示する。省略した場合、CLI は根因行があれば failure、根因行がなく category が workflow なら workflow、それ以外は instruction と推論する
4. カテゴリを選ぶ: style / architecture / testing / naming / workflow / domain
5. 記録する:

bash "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-}}/scripts/feedback.sh" add \
  --category <cat> \
  --summary "<1文要約>" \
  --detail "<文脈: どのファイル/作業で、何を指摘されたか>" \
  --source human \
  [--signal <context|instruction|workflow|failure>]

6. 出力に「openエントリが3件以上」の通知が出たら、feedback-curator エージェント(agents/feedback-curator.md)による昇華をユーザーに提案する

curator は、指摘の扱いを次の3つから選ぶ。新しい原則なら promote、既存ルールと同じ原則の再発なら merge --into、一般化できない一回限りの指摘なら close --reason を使う。

判断基準

• 記録する: 再発しうる指摘(スタイル、設計方針、テスト方針、用語、進め方)、および次回も再現したい成功パターン(有効だった措辞・進め方・タスク分解)
• 記録しない: そのタスク限りの指示（「この行を削除して」など、将来に一般化できないもの）。迷った場合は記録する。不要な記録は promote の判断時に除外できるが、記録しなかった指摘は後から復元できない

なぜ手書きせずCLIを使うか

frontmatterの形式が揃っていないと list / promote が壊れる。logファイルを直接作成・編集しない。