mcpField
S
self-learning-feedback

self-learning-feedback

github.com/proftraderエージェントワークフロー042 回インストール35 週間前に更新
リポジトリ

self-learning-feedback について

self-learning-feedbackは、タスク完了後にフィードバックを集め、以後の出力に反映するエージェントスキルです。タスクの文脈ごとに評価を記録し、改善が必要な場合の反復手順を定めています。

主な機能

  1. 01タスク完了後のフィードバック依頼
  2. 02文脈別の連続評価記録
  3. 03構造化された改善質問
  4. 04深刻度に応じた反復上限
  5. 05改善指摘後の評価カウンターリセット

活用シーン

  1. 01個別タスクの完了後に評価を収集
  2. 02定期 cron job の品質シグナルを追跡
  3. 03改善依頼を後続の出力に反映

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/proftrader/openclaw-self-learning-skill --skill self-learning-feedback

インストール後、Claude Code で/self-learning-feedbackを入力して読み込まれたか確認します。

同梱ファイルreference.md

詳細

自己学習型フィードバック

目的

このスキルを使用すると、ユーザーの作業を妨げずに、タスクや cron ジョブの完了後に再帰的な学習を行えます。

デフォルト値

  • GOOD_APPROVAL_TARGET = 10
  • SLIGHT_MAX_ITERATIONS = 5
  • MEDIUM_MAX_ITERATIONS = 10
  • SEVERE_MAX_ITERATIONS = 20

ユーザーが異なるしきい値（たとえば、良好評価 20 回）を明示的に求めた場合は、GOOD_APPROVAL_TARGET のみを更新します。

起動するタイミング

明確な完了時点で起動します。

  • 個別のタスクが完了した。
  • cron ジョブの実行と応答が完了した。

リクエストからタスクの種類／コンテキスト（たとえば、cron ジョブ名、レポートの種類、コマンド、目標）を特定し、良好評価カウンターと問題のシグネチャーを適切な範囲に設定します。

次の場合は起動しません。

  • タスクの途中。
  • 自然な完了時点に達する前の、複数ステップから成るプロセスの途中。
  • 同じ完了イベントに対して複数回。

邪魔にならないフィードバックの依頼

完了後、短いフィードバックを 1 回求めます。

タスクが完了しました。よかったですか、それとも改善が必要ですか？

依頼は 1～3 行に収めます。

フィードバックに応じた分岐

分岐 A：ユーザーが「よかった」と答えた場合
  1. 同じターン内で、次のように尋ねます。この出力のどこがよかったですか？
  2. ユーザーからの肯定的な評価（品質、形式、スタイル、速度、明瞭さなど）を記録します。
  3. このタスクの種類／コンテキスト（同じ cron ジョブ、同じレポートの種類、同じコマンドなど）の、連続する良好評価カウンターを 1 増やします。前回のタスクでユーザーが「改善が必要」と答えていた場合、そのコンテキストのカウンターはすでにリセットされています。目標に向けてカウントするのは、連続した「よかった」の回答のみです。
  4. カウンターが GOOD_APPROVAL_TARGET に達するまで、同じタスクの種類が完了するたびに、この学習動作を繰り返します。
  5. 目標に達したら、パターンを学習済みとして扱い、フィードバックを求める頻度を減らします。
    • タスクの種類が変わった場合、品質が低下した場合、または定期的な再調整が必要な場合にのみ、「どこがよかったか」を尋ねます。
  6. カウンターのリセット：ユーザーがこのタスクの種類／コンテキストについて「改善が必要」と答えた場合、そのコンテキストの良好評価カウンターを 0 にリセットし、次の「よかった」から新たに連続回数を数えます。
分岐 B：ユーザーが「改善が必要」と答えた場合

まず選択式の質問をし、その後、自由記述による詳細化を行う構造化された学習ループを実施します。

  1. 次の 3 つの観点で、改善の意図を確認します。
    • 改善が必要な理由。
    • どのように改善すべきか。
    • 変更すべきコンテキストやスタイル。
  2. 可能であれば、例を尋ねます。
  3. 深刻度を分類し、反復の上限を設定します。
  4. Web 調査と反復的な推論によって問題を解決します。
  5. 次回の類似する出力に改善を適用します。
  6. 完了後、再度フィードバックを求めます。

選択式の質問テンプレート

利用可能な場合は AskQuestion を使用します。

改善が必要な理由

選択肢：

  • 結果が不正確、または不完全
  • 形式や構成が不適切
  • 遅すぎる、または非効率
  • トーンやスタイルが不適切
  • コンテキストや前提が不足
  • その他（ユーザーが指定）
どのように改善すべきか

選択肢：

  • 詳細や深さを増やす
  • 詳細を減らして簡潔にする
  • 構成や順序を変える
  • 方法やツールを変える
  • 検証やチェックを強化する
  • その他（ユーザーが指定）
どのコンテキストやスタイルを改善すべきか

選択肢：

  • コードのスタイルや規約
  • 出力形式（markdown、JSON、表、文章）
  • 用語や専門分野の言葉遣い
  • 長さや範囲の境界
  • 想定読者や期待されるトーン
  • その他（ユーザーが指定）

続けて次のように尋ねます。

希望する出力やスタイルの例があれば、共有してください。

重大度指標と反復回数の制御

ユーザーの「なぜ／どのように／何を」から問題を分類します（不明確な場合は簡潔に確認します）。

  • 軽微：表現／書式／スタイルの微調整 → 最大5回
  • 中程度：構造／深さ／方法の変更 → 最大10回
  • 重大：根本的な問題または繰り返し発生する失敗 → 最大20回

問題のシグネチャ（なぜ + どのように + 何を + コンテキスト）ごとに学習ループを追跡します。1回の反復とは、学習を適用 → 改訂版を提示 → 再度「良いですか、それとも改善が必要ですか？」と尋ねる、1回のサイクルです。その後、ユーザーが「良い」と答えた場合、その改善課題は完了となります（そのタスクには「良い」という承認の流れが適用されます）。同じ問題について再び「改善が必要」と答えた場合は、次の反復として数えます。

  • 上限未満の場合：反復的な改善を続けます（適用 → 再度フィードバックを尋ねます）。
  • 上限に達した場合：学んだことを要約し、その問題についての反復を停止して、通常のフィードバック依頼を続けます（以降のタスクでも「良いですか、それとも改善が必要ですか？」と尋ねます）。

「なぜ・どのように・何を」の明示要件

改善を実施する際は、必ず以下を明示します。

  • なぜこの変更が必要なのか。
  • どのように変更するのか（具体的な手順）。
  • 適用するコンテキスト／スタイル上の制約。

外部の参照情報によって正確性が向上する場合は、ウェブ検索を使用します。前提を検証し、改善するために反復的に考えます。

UX の安全ルール

  • フィードバックを何度も求めないでください。
  • ユーザーが進行中のワークフローを中断しないでください。
  • 質問は簡潔で予測しやすいものにしてください。
  • UI や製品の変更を求めないでください。これは会話上の振る舞いのレイヤーです。

簡潔な出力形式

タスクの完了後：

  1. 完了を伝える一文。
  2. フィードバックを尋ねる質問を1つ。
  3. ユーザーが「改善が必要」を選んだ場合に限り、任意で追加のフォローアップブロックを1つ。

追加リソース

詳細な質問セットと記入例：reference.md

コメント

Markdown 対応