agile-skill-feedback

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

実際の成果物から得られた証拠をもとに、スキルライブラリを改善するためにこのスキルを使用します。一般的なブレインストーミングではなく、プロセスの保守を目的としています。

スラッシュコマンド経由で受け取った初期コンテキスト：$ARGUMENTS

$ARGUMENTS に値が入力されている場合は、観察された事例、成果物のパス、差分、またはフィードバックメモとして使用してください。空の場合は、問題の内容と対象のスキルを尋ねてください。

言語

成果物はユーザーの言語で作成してください。正しい文法と、必要なダイアクリティカルマークや文字体系固有の文字を使用してください。

プロジェクトルート

このスキルが成果物を書き込むパスは、エージェントの現在の作業ディレクトリではなく、プロジェクトルート（作業対象のリポジトリ）からの相対パスです。

• プロジェクト内から実行した場合は、このスキルに記載された相対パスを使用してください。
• 別のディレクトリから実行した場合（兄弟リポジトリから、またはプロジェクトが別の場所にある場合など）は、すべての成果物パスの先頭に<project-root>/を付けてください。
• プロジェクトルートが不明確な場合は、書き込みの前にハーネスの質問ツールを使ってユーザーに確認してください。

プロンプト作成

CLAUDE.md／AGENTS.mdにあるプロジェクト全体の規約（「スキルのプロンプト作成規約」）に従ってください。以下の判断ポイントでは、ハーネスの構造化質問ツール（Claude Code のAskUserQuestion、Codex のask_user_question、または OpenCode のquestion）を使用してください。

判断ポイント	構造化する理由	推奨される選択肢
アクションの分類	判断ルールに影響するため	改善 · 統合 · 分割 · 非推奨化 · 削除 · 作成
承認状況（最終決定時）	取り消しが難しい手順であるため	提案済み · 承認済み · 却下 · 適用済み · 一部適用 · 撤回

自由形式のプロンプト（構造化質問ツールは不要）：

• 証拠の説明
• 変更案の説明
• 根拠とトレードオフ

一時停止なしモード：ユーザーがスキル実行中の確認を明示的に無効にしている場合は、構造化質問をすべて「未解決の質問」（または同等の項目）に記載し、作業を中断せずに進めてください。

目的

• スキルを実際に使用した際に起きたことを記録する
• 適切な対応（改善、統合、分割、非推奨化、削除、作成）を判断する
• スキルの変更を小さく追跡可能なものにし、現実的な成果物で検証する
• 慣性によるプロセスライブラリの肥大化を防ぐ

使用する場面

• スキルまたはテンプレートが、実際のプロジェクトワークフローに対応できなかった場合
• 2つのスキルが重複している、または成果物が重複する形で常に併用されている場合
• スキルが分かりにくい、古くなっている、あまり役に立たない、または範囲が広すぎる場合
• テンプレートに必須項目がない、または質の低い成果物を生み出している場合
• TDD、改善、スプリント計画、ふりかえり、またはステータス報告で、ガイダンスの不足が明らかになった場合
• プロダクトで、スキルライブラリへの変更案を生成したい場合

使用しない場面

• 通常の計画成果物を作成する場合 — 適切なアジャイルスキルを使用してください
• アプリケーションコードをレビューする場合 — /agile-refinementを使用してください
• スプリントのふりかえりを実施する場合 — /agile-retroを使用してください
• アジャイル／プロセスに関するフィードバックがなく、汎用スキルを一から作成する場合 — プラットフォームのスキル作成ツールを使用してください

収集する入力

• 観察された事例：プロジェクト、成果物、ストーリー、スプリント、PR、またはセッション
• 影響を受けたスキル／テンプレート
• スキルが選択されたきっかけ（分かる場合）
• 期待される動作
• 実際に発生した問題や障害
• 証拠：成果物のパス、差分、テスト、レビューでの指摘、ユーザーによる修正、繰り返し発生した手作業
• 影響：混乱、手戻り、検証漏れ、出力の質の低下、プロセスの重複、コンテキストコスト

判断ルール

改善

スキルの選択自体は適切で、指示、テンプレート項目、例、または検証の調整が必要な場合に使用してください。

統合

2つのスキルで使用のきっかけが重複し、成果物が重複する形で頻繁に連続して使用され、それぞれに独自の成果物や検証ゲートを設ける必要がない場合に使用してください。

分割

1つのスキルが、対象読者、テンプレート、リスク、または検証要件の異なる複数の責務を担っている場合に使用してください。

非推奨化または削除

スキルの実用性がほとんどない、ルーティングを混乱させる、別のスキルと重複する、または役に立たなくなったプロセスを維持している場合に使用します。インストール済みのユーザーがまだ依存している可能性がある場合は、削除より先に非推奨化してください。

作成

繰り返し行われるワークフローに既存のスキル内の適切な置き場所がなく、具体例がある場合にのみ使用します。

プロセス

1. 対象の SKILL.md と、関連するローカルテンプレート／リファレンスファイルのみを読みます。
2. 根拠となる成果物または差分を確認します。
3. 対応を分類します。改善、統合、分割、非推奨化、削除、作成のいずれかです。
4. templates/skill-feedback.md に記入します。
5. 実行可能な最小限の変更を提案します。
6. 変更が機能することを証明する成果物、プロンプト、テスト、またはレビューを定めて検証します。
7. チームに影響するワークフローの変更を適用する前に、人間の承認を必須とします。

ルール

• 既存のスキルへの簡潔な変更で問題を解決できる場合、新しいスキルを作成しないでください。
• 隣接するスキルであるという理由だけで統合しないでください。出力と検証が実際に重複する場合にのみ統合します。
• SKILL.md は簡潔に保ちます。再利用可能な詳細は、必要な場合にのみローカルの templates/、references/、または scripts/ に移します。
• テンプレートは、スキルフォルダー内の templates/ に配置してください。
• 監査可能性を保ちます。入手可能な場合は、元のスキルのバージョンまたはコミットを記録してください。
• AI 生成パッチの場合、判明していれば、フィードバック成果物にモデル／プロバイダーと承認状況を記載してください。

保存先

保存場所は、フィードバックの対象によって異なります。

• プロジェクトのプロセス成果物について → planning/<initiative>/skill-feedback/<YYYY-MM-DD>-<slug>.md。
• このスキルリポジトリ内のスキルについて → <skills-repo>/feedback/<YYYY-MM-DD>-<skill>.md。ルートに専用の feedback/ フォルダーができるまでは、samples/<sample>/proposals/skill-feedback-<YYYY-MM-DD>-<slug>.md を使用し、関連する根拠資料（ジャーナル、調査結果）をその隣に置きます。

テンプレート

templates/skill-feedback.md を基本成果物として使用します。テンプレートには以下が含まれます。

• ## Auditability ブロック（元のスキルのバージョン／コミット、モデル／プロバイダー、発生元のセッション、関連する調査結果）。判明している項目を記入してください。
• 拡張された承認用 Status 列挙値：proposed / approved / rejected / applied / partially-applied / withdrawn。正式な承認前にパッチが適用されていた場合は、実態に即して partially-applied を使用し、Partial application notes: サブフィールドに記入してください。

フローとの関係

flowchart LR
    A["Real skill usage"] --> B["Observed friction"]
    B --> C["/agile-skill-feedback"]
    C --> D{Decision}
    D --> E["Refine"]
    D --> F["Merge/Split"]
    D --> G["Deprecate/Remove"]
    D --> H["Create"]
    E --> I["Validate on real artifact"]
    F --> I
    G --> I
    H --> I

このスキルは、プロセスのフィードバックループを閉じます。実際の作業でギャップが明らかになった後に使用するものであり、作業そのものの代わりにはなりません。