| name | capture-feedback |
| description | 人間のレビュー指摘・修正・ダメ出しをフィードバックログに記録するスキル。ユーザーがエージェントの成果物を修正した、指摘した、「こうして」「次からはこうやって」「これは違う」と言った、方針を訂正した、あらゆる場面で必ずこのスキルを使用すること。「フィードバックを記録して」「これ覚えておいて」「同じミスをしないで」という明示的依頼でも使用する。うまくいった措辞・進め方・タスク分解など、次回も再現したい成功パターンの記録にも使用する。記録の修正・追記・再分類の依頼にも対応する。 |
Capture Feedback
人間の指摘を .feedback/log/ に構造化して記録する。記録は昇華(promote)の原料であり、記録されない指摘は次のセッションで失われる。だから指摘に気づいたら作業の途中でも即記録する。
手順
- 指摘から「何が問題とされ、どう直すべきとされたか」を1文の要約に整理する。成功パターンなら「何がうまくいき、次回どう再現するか」を要約する
- 誤った出力・行動に関する指摘は、次の基準で根因を1つ選び、
--detail に 根因: <分類> と記録する。根因は責任追及ではなく、再発防止策の反映先を決めるための分類である:
文脈欠落: 判断に必要な事実・規約・バージョン情報が、判断時に読み込まれた文脈へ存在しなかった。情報が参照可能だったのに調べなかった、または提示済み情報を見落とした場合は含めない指示欠陥: 期待する結果、制約、受け入れ条件、手順が指示で欠落・曖昧・矛盾しており、通常の品質基準だけでは一意に判断できなかった。「個別の禁止ルールがなかった」という理由だけで通常の設計・実装ミスをここへ入れない実行誤り: 必要な文脈と十分に明確な指示があったのに、見落とし、指示違反、推論ミス、実装ミスが起きた。単発の失敗は、まずこの分類を検討するモデル限界: 十分な文脈、明確な指示、利用可能なツール、妥当な再試行を与えても、同種の失敗を安定して避けられない。単発の見落としだけでは選ばず、再現または反復の証拠を必要とする未判定: 証拠が不足している、または複数の原因を切り分けられない。無理に他の分類へ寄せず、必要な追加確認を detail に残す
- signal は根因と分けて決める: 誤った出力・行動は根因にかかわらず
failure、不足していた前提情報の提供は context、有効だった指示の言い回しは instruction、有効だった進め方・タスク分解は workflow。--signal <種> で明示する。省略した場合、CLI は根因行があれば failure、根因行がなく category が workflow なら workflow、それ以外は instruction と推論する
- カテゴリを選ぶ:
style / architecture / testing / naming / workflow / domain
- 記録する:
bash "${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-}}/scripts/feedback.sh" add \
--category <cat> \
--summary "<1文要約>" \
--detail "<文脈: どのファイル/作業で、何を指摘されたか>" \
--source human \
[--signal <context|instruction|workflow|failure>]
- 出力に「openエントリが3件以上」の通知が出たら、feedback-curator エージェント(
agents/feedback-curator.md)による昇華をユーザーに提案する
curator は、指摘の扱いを次の3つから選ぶ。新しい原則なら promote、既存ルールと同じ原則の再発なら merge --into、一般化できない一回限りの指摘なら close --reason を使う。
判断基準
- 記録する: 再発しうる指摘(スタイル、設計方針、テスト方針、用語、進め方)、および次回も再現したい成功パターン(有効だった措辞・進め方・タスク分解)
- 記録しない: そのタスク限りの指示（「この行を削除して」など、将来に一般化できないもの）。迷った場合は記録する。不要な記録は promote の判断時に除外できるが、記録しなかった指摘は後から復元できない
なぜ手書きせずCLIを使うか
frontmatterの形式が揃っていないと list / promote が壊れる。logファイルを直接作成・編集しない。
