📦 その他コミュニティ

flow-receiving-review

コードレビューの指摘に対し、鵜呑みにせず技術的な根拠に基づいて検証し、納得してから実装することで、質の高い開発につなげるSkill。

📜 元の英語説明(参考)

Handle code review feedback with technical rigor. Don't blindly agree - verify before implementing.

🇯🇵 日本人クリエイター向け解説

一言でいうと

コードレビューの指摘に対し、鵜呑みにせず技術的な根拠に基づいて検証し、納得してから実装することで、質の高い開発につなげるSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux

mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o flow-receiving-review.zip https://jpskill.com/download/18692.zip && unzip -o flow-receiving-review.zip && rm flow-receiving-review.zip

🪟 Windows (PowerShell)

$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/18692.zip -OutFile "$d\flow-receiving-review.zip"; Expand-Archive "$d\flow-receiving-review.zip" -DestinationPath $d -Force; ri "$d\flow-receiving-review.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)

1. 下の青いボタンを押して flow-receiving-review.zip をダウンロード
2. ZIPファイルをダブルクリックで解凍 → flow-receiving-review フォルダができる
3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
4. Claude Code を再起動

⬇ .zip でダウンロード(推奨) ⬇ .skill 形式(上級者用) 元のソース ↗

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
- · macOS / Linux: ~/.claude/skills/
- · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →

最終更新: 2026-05-18
取得日時: 2026-05-18
同梱ファイル: 1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

Flow Receiving Review - コードレビューのフィードバックの処理

鉄の掟

実装する前にフィードバックを検証する - 盲目的に同意しない

概要

コードレビューのフィードバックを受け取る際は、技術的な厳密さを維持してください。レビュー担当者が間違っていることもあります。あなたの仕事は以下のとおりです。

フィードバックを理解する
それが正しいことを検証する
その後、実装する（または反論する）

プロセス

ステップ 1: フィードバックを理解する

各コメントについて:
  1. 完全に読む - ざっと読まない
  2. 懸念事項を特定する:
     - バグですか？
     - スタイルの好みですか？
     - パフォーマンスの問題ですか？
     - セキュリティ上の懸念ですか？
  3. 不明な場合 → 明確化を求める
     - 「なぜ X が問題なのか詳しく説明していただけますか？」
     - 「これは具体的にどのようなシナリオに対応するものですか？」

ステップ 2: フィードバックを検証する

変更を実装する前に:
  1. フィードバックは技術的に正しいですか？
     - 提案された変更は実際に問題を修正しますか？
     - 新たな問題を引き起こす可能性はありますか？

  2. プロジェクトの標準に準拠していますか？
     - Constitution を確認する
     - 既存のパターンを確認する

  3. 証拠はありますか？
     - 問題を再現できますか？
     - 提案された修正は機能しますか？

フィードバックが間違っていると思われる場合:
  → 黙って反対しない
  → 盲目的に実装しない
  → 分析結果を返信する

ステップ 3: 適切に対応する

フィードバックが正しい場合:
  → 承認する: 「ご指摘ありがとうございます。修正します」
  → 修正を実装する
  → 修正が機能することを確認する

フィードバックが不明確な場合:
  → 質問する: 「X が意味することについて、詳しく説明していただけますか？」
  → 意図を推測しない

フィードバックが間違っていると思われる場合:
  → 自分の推論を説明する
  → 証拠を提供する
  → 「X を検討しましたが、Z のため Y にしました。どう思いますか？」

フィードバックが好みの場合 (バグではない場合):
  → トレードオフについて議論する
  → プロジェクトの標準が存在する場合はそれに従う

合理化の防止

言い訳	現実
「レビュー担当者の方がよく知っている」	レビュー担当者は間違いを犯します。検証してください。
「言われたとおりにすればいい」	盲目的な従順 = 質の低いコード。
「議論したくない」	技術的な議論 ≠ 口論。
「変更する方が早い」	間違った変更はより多くの時間を浪費します。
「反論すると拒否される」	優れたレビュー担当者は厳密さを評価します。

レッドフラッグ - 中止

もしあなたが以下のような状況に陥っていることに気づいたら:

理解していない変更を実装している
間違っていると思うフィードバックに同意している
明確にするための質問をしていない
動作確認せずに変更を加えている

中止。まず理解する。次に検証する。最後に実装する。

レスポンステンプレート

フィードバックに同意する場合

ご指摘ありがとうございます！おっしゃる通り [issue] ですね。[file] を [fix] に更新しました。
[test/command] を実行して検証済みです。

明確化を求める場合

正しく理解しているか確認させてください。[interpretation] を提案されているということでしょうか？
もしそうなら、[concern] について疑問に思っています。詳しく説明していただけますか？

丁寧に反対する場合

[suggestion] を検討しましたが、[current approach] を採用しました。なぜなら:
1. [Reason 1]
2. [Reason 2]

トレードオフは [X] です。[alternative] についてどう思いますか？

証拠を要求する場合

[issue] を再現するのに苦労しています。以下を共有していただけますか？
- 再現手順
- 期待される動作と実際の動作
- 環境の詳細

flow-review との統合

このスキルは、レビュー担当者からのフィードバックを処理する際に /flow-review で使用されます。

レビューを受け取った後:
  1. このスキルをロードする
  2. 3 ステップのプロセスを使用して各コメントを処理する
  3. 適切に対応する
  4. EXECUTION_LOG.md で変更を追跡する

相互参照

flow-review.md - 2 段階レビューコマンド
spec-reviewer.md - 仕様準拠エージェント
code-quality-reviewer.md - 品質レビューエージェント

[PROTOCOL]: 変更時はこのヘッダーを更新し、CLAUDE.md を確認してください

📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Flow Receiving Review - 处理代码审查反馈

The Iron Law

VERIFY FEEDBACK BEFORE IMPLEMENTING - DON'T BLINDLY AGREE

Overview

When receiving code review feedback, maintain technical rigor. Reviewers can be wrong. Your job is to:

Understand the feedback
Verify it's correct
Then implement (or push back)

The Process

Step 1: Understand the Feedback

For each comment:
  1. Read completely - don't skim
  2. Identify the concern:
     - Is it a bug?
     - Is it a style preference?
     - Is it a performance issue?
     - Is it a security concern?
  3. If unclear → ASK for clarification
     - "Could you elaborate on why X is problematic?"
     - "What specific scenario does this address?"

Step 2: Verify the Feedback

Before implementing ANY change:
  1. Is the feedback technically correct?
     - Does the suggested change actually fix the issue?
     - Could it introduce new problems?

  2. Does it align with project standards?
     - Check Constitution
     - Check existing patterns

  3. Is there evidence?
     - Can you reproduce the issue?
     - Does the suggested fix work?

If feedback seems wrong:
  → Don't silently disagree
  → Don't blindly implement
  → Respond with your analysis

Step 3: Respond Appropriately

If feedback is correct:
  → Acknowledge: "Good catch, fixing now"
  → Implement the fix
  → Verify the fix works

If feedback is unclear:
  → Ask: "Could you clarify what you mean by X?"
  → Don't guess the intent

If feedback seems incorrect:
  → Explain your reasoning
  → Provide evidence
  → "I considered X, but Y because Z. What do you think?"

If feedback is a preference (not a bug):
  → Discuss trade-offs
  → Defer to project standards if they exist

Rationalization Prevention

Excuse	Reality
"Reviewer knows better"	Reviewers make mistakes. Verify.
"Just do what they say"	Blind compliance = poor code.
"Don't want to argue"	Technical discussion ≠ argument.
"It's faster to just change it"	Wrong changes waste more time.
"They'll reject if I push back"	Good reviewers appreciate rigor.

Red Flags - STOP

If you find yourself:

Implementing changes you don't understand
Agreeing with feedback you think is wrong
Not asking clarifying questions
Making changes without verifying they work

STOP. Understand first. Verify second. Implement third.

Response Templates

Agreeing with Feedback

Good catch! You're right that [issue]. I've updated [file] to [fix].
Verified by running [test/command].

Asking for Clarification

I want to make sure I understand correctly. Are you suggesting [interpretation]?
If so, I'm wondering about [concern]. Could you elaborate?

Respectfully Disagreeing

I considered [suggestion], but I went with [current approach] because:
1. [Reason 1]
2. [Reason 2]

The trade-off is [X]. What do you think about [alternative]?

Requesting Evidence

I'm having trouble reproducing [issue]. Could you share:
- Steps to reproduce
- Expected vs actual behavior
- Environment details

Integration with flow-review

This skill is used in /flow-review when processing reviewer feedback:

After receiving review:
  1. Load this skill
  2. Process each comment using the 3-step process
  3. Respond appropriately
  4. Track changes in EXECUTION_LOG.md

Cross-Reference

flow-review.md - Two-stage review command
spec-reviewer.md - Spec compliance agent
code-quality-reviewer.md - Quality review agent

[PROTOCOL]: 变更时更新此头部，然后检查 CLAUDE.md