スキル receiving-code-review
📦

receiving-code-review

安全

コードレビューフィードバックを技術的検証で処理する

こちらからも入手できます: Cygnusfear,DYAI2025,Cycleaddict,davila7,CodingCossack,obra

コードレビューには感情的なパフォーマンスではなく技術的評価が必要です。このスキルは、実装前にレビューフィードバックを検証するための構造化されたパターンを提供し、社会的な快適さではなく技術的正确性を確保します。

対応: Claude Codex Code(CC)
🥉 74 ブロンズ
1

スキルZIPをダウンロード

2

Claudeでアップロード

設定 → 機能 → スキル → スキルをアップロードへ移動

3

オンにして利用開始

テストする

「receiving-code-review」を使用しています。 レビュアー：レガシーコードを削除

期待される結果:

互換性要件を確認中... ビルドターゲットは 10.15+、この API には 13+ が必要。現在の実装には間違ったバンドル ID があります。オプション：バンドル ID を修正するか、13 以前のサポートを削除するか。どちらを希望しますか？

「receiving-code-review」を使用しています。 レビュアー：データベース、日付フィルター、CSV エクスポートでメトリクス追跡を実装

期待される結果:

コードベースを検索 - このエンドポイントを呼び出すコードなし。YAGNI 原則に従って削除を推奨。知っておくべき予想される使用例はありますか？

「receiving-code-review」を使用しています。 パートナー：項目 1-6 を修正

期待される結果:

項目 1、2、3、6 は理解しています。実装を続ける前に、項目 4 と 5 の明確化が必要です。

セキュリティ監査

安全
v1 • 2/24/2026

All static analysis findings are false positives. The skill file (SKILL.md) is a markdown documentation file containing instructional text, not executable code. Backticks detected are markdown code block delimiters, not shell command execution. No actual cryptographic operations, network calls, or command injection vectors exist in this skill.

1
スキャンされたファイル
214
解析された行数
0
検出結果
1
総監査数
セキュリティ問題は見つかりませんでした
監査者: claude

品質スコア

38
アーキテクチャ
100
保守性
87
コンテンツ
50
コミュニティ
100
セキュリティ
91
仕様準拠

作れるもの

複数項目のレビュー対応

6 件以上のフィードバック項目を受け取った場合、まず不明瞭な項目を明確化し、優先順位の高いもの（ブロッキング問題）から実装し、各変更を個別にテストして早期に回帰を検出する

外部レビュアーへの懐疑的対応

外部レビュアーが十分な文脈なしに変更を提案してきた場合、コードベースの技術的正确性を検証し、破壊的変更がないか確認し、誤った提案には証拠を持って異議を唱える

YAGNI 原則による機能ゲートキーピング

レビュアーがデータベース、フィルター、エクスポート機能付きで「適切に」機能を実装するよう提案した場合、不要な複雑さを追加する前にコードベースを grep して実際の使用状況を確認する

これらのプロンプトを試す

不明瞭なフィードバックの明確化 
1〜6 のコードレビューフィードバックを受け取りました。項目 1、2、3、6 は理解していますが、項目 4 と 5 は不明瞭です。実装前に、項目 4 と 5 で具体的に何が求められているかを明確化する必要があります。
外部レビュアーの提案の検証 
レビュアーが X を Y に変更するよう提案しました。検証します：これはこのコードベースで技術的に正しいですか？既存の機能を壊しますか？現在の実装の理由は何でしたか？続行する前にコードとテストを確認します。
技術的根拠を持って異議を唱える 
X という提案は理解していますが、Z のために Y が壊れます。現在の実装はエッジケース A と B を処理しています。これを変更すると、C と D も更新する必要があります。完全な範囲で進めるべきか、現在のアプローチを維持すべきかどちらですか？
機能リクエストの YAGNI チェック 
完全なデータベースサポート、日付フィルター、CSV エクスポート付きで X を実装するよう提案されました。コードベースを検索しましたが、このエンドポイントを呼び出すコードは見つかりませんでした。YAGNI 原則に従って完全に削除すべきですか、それとも見落としている使用例がありますか？

ベストプラクティス

  • フィードバックのどの部分を実装する前に、常にすべての不明瞭な項目を明確化する
  • 表面のロジックだけでなく、実際のコードベースの動作に対して提案を検証する
  • 防御的または感情的ではなく、具体的な技術的根拠を持って異議を唱える

回避

  • 検証前に「あなたのおっしゃる通りです！」や「素晴らしい指摘です！」と言う
  • コードベースの現実を確認せずにすぐにフィードバックを実装する
  • 各変更を個別にテストせずに複数の項目を一括実装する

よくある質問

レビューフィードバックが不明瞭な場合、どうすればよいですか？
何かを実装する前に、すぐに不明瞭な項目について明確化を求めてください。項目は関連している可能性があり、部分的な理解は間違った実装につながります。
レビュアーの提案にどう異議を唱えればよいですか？
具体的な証拠を用いて技術的推論を使用してください。動作中のテスト、コードの動作、または互換性要件を参照してください。防御的な発言ではなく具体的な質問をしてください。
レビュアーが正しくて私が異議を唱えた場合はどうすればよいですか？
修正を事実として述べてください：「あなたがおっしゃる通りでした - X を確認したところ Y をしていました。現在実装中です。」長い謝罪やなぜ異議を唱えたかの過度な説明は避けてください。
レビュアーにフィードバックを感謝すべきですか？
いいえ。行動は言葉より雄弁です。ただ問題を修正して変更内容を示してください。「ありがとう」と書こうとしたら、それを削除して代わりに修正内容を述べてください。
機能を「適切に」実装するよう提案された場合はどう処理すればよいですか？
まずコードベースを実際の使用方法で grep してください。エンドポイントや機能を呼び出すコードがない場合は、YAGNI 原則に従って削除を提案してください。確認された使用例がある場合にのみ完全に実装してください。
複数項目のフィードバックをどの順序で実装すべきですか？
すべての項目を明確化した後、この順序で実装してください：まずブロッキング問題（破壊的変更、セキュリティ）、次に単純な修正（タイプミス、インポート）、そして複雑な修正（リファクタリング、ロジック）。各修正を個別にテストしてください。

開発者の詳細

作成者

ZhanlinCui

ライセンス

MIT

リポジトリ

https://github.com/ZhanlinCui/Ultimate-Agent-Skills-Collection/tree/main/receiving-code-review

参照

main

ファイル構成

📄 SKILL.md