skill-feedback

スキルへのフィードバック

概要

スキルのセッションが完了した後に使用します。

基本原則： 1つのスキルについて、ユーザーが実際に報告した内容を記録し、公開予定の成果物をそのまま表示して、それだけを送信します。

このスキルで作成するフィードバックの送信先は、常に folio-org/folio-eureka-ai-dev です。

使用するタイミング

次の場合に使用します。

• ユーザーが、使い終えたスキルについてフィードバックを残したい場合。
• セッションが完了していて、要約するのに十分なコンテキストがある場合。
• フィードバックの対象が、一般的な製品やリポジトリの問題ではなく、スキルの品質である場合。

次の場合は使用しないでください。

• ユーザーがまだスキルの使用中である場合。
• 報告の対象が、無関係なバグやリポジトリの問題である場合。
• 会話の内容が、後続のチューニング戦略に関するものである場合。

厳守事項

• 1件の報告につき、1つのスキルと1つの完了したセッションを対象にします。
• 自動送信はしないでください。表示した内容について明示的な承認を得てから公開してください。
• 肯定的な報告や、特に大きな問題がないという報告も、完全で有効な報告です。
• 推測は控えめにします。セッションから裏付けられない任意項目は省略してください。
• ユーザーの感情ではなく、実際に確認された摩擦点を記述してください。
• シークレット、トークン、非公開の内部 URL を含めないでください。
• FOLIO モジュールの分類を求めないでください。

クイックリファレンス

ステップ	要件
対象	1つのスキル、1つの完了したセッション
形式	フィールド、列挙値、タイトル、本文の形式には references/report-template.md を使用
情報収集	ユーザーがすでに伝えたフィードバックを使用し、質問は中立的なものを最大1つまで
確認	公開可能な成果物そのものを1回プレビュー
判断	approve、edit、cancel
送信	利用可能な GitHub issue ツール、次に設定済みの gh、最後に手動

このリポジトリに手動で使う GitHub issue テンプレートがある場合は、references/report-template.md と内容をそろえてください。そのテンプレートがなくても、スキルは引き続き動作する必要があります。

ワークフロー

1. 対象のスキルを特定します。ユーザーが明示したスキル名がある場合は、推測よりもそちらを優先します。
2. 候補が複数あり、どれも同程度に当てはまる場合に限り、どのスキルについての報告かを尋ねます。1件の報告につき、スキルは1つにします。
3. セッションを確認し、リスクが低く有用な情報だけを抽出します。たとえば、ユーザーが何をしようとしていたか、セッションで何が作成されたか、修正が繰り返されたか、形式や範囲に問題があったかなどです。
4. 情報収集を完了します（以下を参照）。
5. references/report-template.md を使って報告を作成します。references/example-report.md は文体の参考としてのみ使用します。
6. 公開用プレビューを1回表示し、判断を求めます（以下を参照）。
7. edit の場合は修正し、更新後のプレビュー全体を再度表示して、改めて判断を求めます。
8. cancel の場合は、issue を作成せずに終了します。
9. 承認されたら送信します（以下を参照）。
10. 送信成功が確認できたら、issue の URL と短い確認メッセージを返します。承認・編集・キャンセルの選択肢を繰り返したり、報告全体を再掲したりしないでください。

情報収集

ユーザーがすでに伝えたフィードバックを使用します。フィードバックがまだ明確でない場合は、中立的な質問を1つだけします。「記録したいフィードバックを教えてください。うまくいった点、改善したい点、または特に大きな問題がなかったことなどです。」肯定的な報告に改善提案は必要ありません。通常のやり取りから不満を推測したり、沈黙から満足を推測したりしないでください。

• 改善点はありません は、肯定的な報告や特に大きな問題がないという報告として有効であり、キャンセルではありません。
• 明示的な cancel、これを記録しないでください、または撤回があった場合は、送信せずにワークフローを終了します。
• 任意のメタデータを埋めるためだけに質問してはいけません。
• 裏付けとなる情報がないのに、問題の候補一覧をユーザーに提示してはいけません。

1つのレビュー用成果物

公開プレビューを1つ提示します。リポジトリ（folio-org/folio-eureka-ai-dev）、ラベル（skill-feedback）、正確な issue タイトル、完全な Markdown 本文を表示してください。エージェントが追加した内容と推定したメタデータは、すべてそのプレビューに表示してください。別途「Draft fields」のレビューを追加しないでください。表示したバージョンを承認、編集、キャンセルするか、一度だけ尋ねてください。

自然な言葉で明確に同意した場合は、承認として扱います。ユーザーが approve という単語を入力する必要はありません。タイトル、本文、追加フィールドのいずれかがその後変更された場合は、更新後のプレビュー全体を表示し、再度承認を得てください。変更のない承認済み成果物を別の送信経路に移すだけであれば、会話上で再度承認を得る必要はありません。ただし、実行時の許可プロンプトには引き続き従ってください。

送信

承認後、利用可能な GitHub issue 作成ツールを使用してください。その経路が利用できない場合、または明示的に拒否された場合は、すでに設定済みのローカル gh CLI を試してください。それ以外の場合は、手動で送信できるよう、承認済みの成果物を提示してください。タイムアウトや応答がないことは、作成に失敗した証拠にはなりません。別の書き込みを試みる前に、結果を確認してください。公開前に Submission を読んでください。

作成ルール

• 会話で明示されたスキルの使用を優先してください。
• セッションから複数のスキルが示唆される場合、推測しないでください。
• 複数のスキルへのフィードバックを1つのレポートにまとめないでください。
• 長い会話の抜粋をコピーするのではなく、要約してください。
• シークレット、トークン、非公開 URL、不要な識別情報を含めないでください。
• 価値のない任意のセクションは省略してください。空の見出しや None の埋め草は出力しないでください。

良い例：

• Work context: product-requirement
• Primary feedback type: no-major-issues
• Observed friction signals: repeated scope corrections

悪い例：

• The user was frustrated
• The project was definitely mod-orders
• セクションを空にしないためにでっち上げた改善案の段落

FOLIO の取り扱い

• project_hint には FOLIO のモジュール、イニシアチブ、領域を指定できます。または省略できます。
• FOLIO の用語は、セッション内で確認でき、レポートに役立つ場合にのみ使用してください。
• 作業が FOLIO のコンテキストで行われた場合も、レポートの対象はスキルそのものにしてください。

よくある間違い

• ユーザーがスキルはうまく機能したと報告しているのに、問題を無理に聞き出す。
• 簡潔なフォローアップではなく、聞き取りをアンケートにしてしまう。
• 公開する成果物とは別に、下書きのフィールドをレビューする。
• 編集後にプレビュー全体を再表示せずに送信する。
• 承認済みの短い本文を、定型的な手順として一時ファイルに書き込む。
• 結果が不明確なまま、確認せずに書き込みを再試行する。
• 根拠の乏しい情報から感情や意図を推測する。
• 生の会話の抜粋を issue 本文にコピーする。

完了チェックリスト

issue を作成する前に、以下のすべてを確認してください。

• 対象スキルとユーザーのフィードバックの意図が明確で、レポートが1つのスキルのみを扱っている。
• 苦情も肯定的な結果も捏造していない。
• 任意のメタデータや削除されたメタデータを自動的に追加していない。
• 公開する正確な成果物として、リポジトリ、ラベル、タイトル、本文全体を表示した。
• ユーザーが承認したバージョンが現在のバージョンである。
• 送信した内容が承認済みバージョンと一致している。または、手動での送信や結果が不確かなことを正直に伝えた。
• 非表示の内容や機密情報が含まれていない。