mcpField
F
feedback-application

feedback-application

github.com/qodex-aiテスト・品質47125 回インストール42 週間前に更新
リポジトリ

feedback-application について

コードレビューのフィードバックを体系的に実装するスキルです。コメントを追跡可能なタスクに分け、プロジェクト規約に沿って変更し、関連テストと lint で検証します。

主な機能

  1. 01フィードバックを個別の要望に分解
  2. 02実行可能な Todo で進捗を管理
  3. 03プロジェクト規約に沿った変更
  4. 04関連テストと lint の実行
  5. 05曖昧さや矛盾する指摘への対応

活用シーン

  1. 01Pull Request のレビューコメントへの対応
  2. 02レビュー提案を実装タスクに変換
  3. 03レビュー後の修正内容の検証

インストール

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

$npx skills add https://github.com/qodex-ai/ai-agent-skills --skill feedback-application

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

詳細

レビュー フィードバックの実装

コードレビューのフィードバックに基づいて、変更を体系的に処理し、実装します。

使用するタイミング

  • レビュアーのコメントやフィードバックが提供された場合
  • PR のレビュー メモが貼り付けられた場合
  • レビューの提案を実装すると言われた場合
  • 「これらのコメントに対応して」または「フィードバックを実装して」と言われた場合
  • レビュアーからの変更依頼のリストが共有された場合

体系的なワークフロー

1. レビュアーのメモを解析する

個別のフィードバック項目を特定します。

  • 番号付きリスト（1.、2. など）を分割します
  • 箇条書きや番号なしのフィードバックにも対応します
  • 個別の変更依頼を抽出します
  • 曖昧な項目は作業を始める前に確認します
2. Todo リストを作成する

TodoWrite ツールを使用して、実行可能なタスクを作成します。

  • 各フィードバック項目を 1 つ以上の todo にします
  • 複雑なフィードバックは小さなタスクに分割します
  • タスクを具体的かつ測定可能にします
  • 作業を始める前に、最初のタスクを in_progress にします

例：

- Add type hints to extract function
- Fix duplicate tag detection logic
- Update docstring in chain.py
- Add unit test for edge case
3. 変更を体系的に実装する

各 todo 項目について、次の手順を実施します。

関連するコードを特定する：

  • Grep を使用して関数やクラスを検索します
  • Glob を使用してパターンに一致するファイルを検索します
  • 現在の実装を読みます

変更を加える：

  • 変更には Edit ツールを使用します
  • プロジェクトの規約（CLAUDE.md）に従います
  • 動作を変更する場合を除き、既存の機能を維持します

変更を検証する：

  • 構文が正しいことを確認します
  • 該当する場合は関連するテストを実行します
  • 変更がレビュアーの意図に沿っていることを確認します

ステータスを更新する：

  • 完了したらすぐに todo を completed にします
  • 次の todo に進みます（同時に in_progress にできるのは 1 つだけです）
4. 異なる種類のフィードバックに対応する

コードの変更：

  • 既存のコードの変更には Edit ツールを使用します
  • 型ヒントの規約（PEP 604/585）に従います
  • 一貫したスタイルを維持します

新機能：

  • 必要に応じて Write ツールで新しいファイルを作成します
  • 対応するテストを追加します
  • ドキュメントを更新します

ドキュメント：

  • プロジェクトのスタイルに従って docstring を更新します
  • 必要に応じて Markdown ファイルを変更します
  • 説明は簡潔に保ちます

テスト：

  • クラスではなく関数としてテストを記述します
  • 内容が分かりやすい名前を付けます
  • pytest の規約に従います

リファクタリング：

  • 機能を維持します
  • コード構造を改善します
  • テストを実行してリグレッションがないことを確認します
5. 検証

変更を実装した後、次のことを行います。

  • 影響を受けるテストを実行します
  • リントエラーを確認します：uv run ruff check
  • 変更によって既存の機能が壊れていないことを確認します
6. コミュニケーション

ユーザーに状況を随時伝えます。

  • todo リストをリアルタイムで更新します
  • 曖昧なフィードバックについて確認します
  • 障害や課題を報告します
  • 完了時に変更内容を要約します

エッジケース

フィードバックが矛盾している場合：

  • ユーザーに指示を仰ぎます
  • 矛盾を明確に説明します

破壊的変更が必要な場合：

  • 実装前にユーザーに知らせます
  • 影響と代替案について相談します

変更後にテストが失敗した場合：

  • todo を完了にする前にテストを修正します
  • 関連するすべてのテストが合格することを確認します

参照されたコードが存在しない場合：

  • ユーザーに確認を求めます
  • 作業を進める前に、理解が正しいことを確認します

重要なガイドライン

  • 進捗管理には必ず TodoWrite を使用する
  • 各項目の完了後、すぐに todo を completed にする
  • 同時に in_progress にする todo は 1 つだけにする
  • 完了状況をまとめて更新せず、リアルタイムで更新する
  • フィードバックが不明確な場合は質問する
  • 変更がテスト対象のコードに影響する場合はテストを実行する
  • すべてのコード変更で CLAUDE.md の規約に従う
  • 後でコミットを作成する場合は Conventional Commits に従う

コメント

Markdown 対応