技能 receiving-code-review
🔍

receiving-code-review

安全 🌐 網路存取⚙️ 外部命令

技術的な厳密性を持ってコードレビューを処理する

也可從以下取得: Cygnusfear,DYAI2025,Cycleaddict,CodingCossack,davila7

コードレビューには、検証なしで実装される不明瞭または技術的に疑問のあるフィードバックが含まれていることがよくあります。このスキルは、AIが実装前にフィードバックを技術的に評価し、バグを防止しコード品質を維持することを保証します。

支援: Claude Codex Code(CC)
📊 69 充足
1

下載技能 ZIP

2

在 Claude 中上傳

前往 設定 → 功能 → 技能 → 上傳技能

3

開啟並開始使用

測試它

正在使用「receiving-code-review」。 レビューでレガシーコードを削除するよう指示されています

預期結果:

  • コードベースの実際の使用パターンを確認する
  • 互換性要件を検証する
  • すべてのプラットフォームで削除が安全かどうか特定する
  • 決定に対して技術的な理由を提供する

正在使用「receiving-code-review」。 PR内の1-6項目を修正してください

預期結果:

  • 各項目の理解を明確化する
  • 実装前に不明瞭な項目を特定する
  • 複雑さとリスクによって修正に優先順位を付ける
  • 各変更を個別にテストする

正在使用「receiving-code-review」。 外部レビューアがリファクタリングを提案しています

預期結果:

  • レビューアがコードベースの文脈を理解しているか確認する
  • 提案が既存の機能を壊さないか確認する
  • 使用されていないコードに対してYAGNI原則を検討する
  • 必要に応じて技術的な理由で反論する

安全審計

安全
v5 • 1/17/2026

This skill is a pure documentation file (SKILL.md) containing markdown guidelines for handling code review feedback. All 36 static findings are false positives - the 'external_commands' patterns are markdown pseudocode blocks showing workflow patterns, not executable code. The 'weak cryptographic algorithm' patterns appear to be triggered by the word 'weak' in documentation text. The 'network reconnaissance' findings refer to legitimate grep usage for code analysis. This is a documentation-only skill with zero executable code and no security risk.

2
已掃描檔案
526
分析行數
2
發現項
5
審計總數
審計者: claude 查看審計歷史 →

品質評分

38
架構
100
可維護性
85
內容
21
社群
100
安全
91
規範符合性

你能建構什麼

GitHub PRフィードバックの処理

変更を実装する前に技術的な検証を行い、プルリクエストコメントを処理する

レビュー提案への対応

適切な技術的分析でコードレビューフィードバックを評価し対応する

コード品質基準の維持

コード変更が技術的に健全であり、回帰を引き起こさないことを確認する

試試這些提示

基本的なレビュー対応
このコードレビューフィードバックを受け取りました: '[フィードバック]'。実装する前にこれを理解して検証する手伝いをしてください。
不明瞭なフィードバック
1-6項目のフィードバックを受け取りました。1,2,3,6は理解していますが、4,5が不明瞭です。どのように進むべきですか?
技術的な意見の相違
レビューアは[変更]を提案していますが、これは[機能]を壊す可能性があると思っています。どのように検証して対応すればよいですか?
外部レビューア
外部のレビューアが[変更]を提案しています。実装する前に、これが私たちのコードベースに適合するか確認する必要があります。

最佳實務

  • 実装前に常に実際のコードベースに対してフィードバックを検証する
  • 進む前に不明瞭な項目について明確化をリクエストする
  • 回帰を避けるために各修正を個別にテストする

避免

  • 検証せずにフィードバックを盲目的に実装する
  • 素晴らしい意見ですのような表面的な同意の言葉を使用する
  • 各機能をテストせずに複数の修正をまとめて行う

常見問題

なぜありがとうや素晴らしい意見ですと言えないのですか
行動は言葉よりも雄弁です。コード自体がフィードバックを理解したことを示します。技術的な承認は社交的な礼節よりも価値があります。
レビューアが間違っていたらどうすればよいですか
技術的な理由で反論してください。あなたの立場を裏付ける、動作するコード、テスト、またはドキュメントを参照してください。
不明瞭なフィードバックにはどのように対処すればよいですか
実装を停止して明確化をリクエストしてください。部分的な理解は 잘못された実装につながります。
常に外部レビューアの提案を実施すべきですか
いいえ。まず彼らがあなたのコードベースの文脈を理解しているか確認してください。外部のフィードバックは評価すべき提案であり、従うべき指示ではありません。
フィードバックがチームの決定と矛盾する場合はどうすればよいですか
まずチームで停止して議論してください。確立されたアーキテクチャに反する変更は実装しないでください。
コードを削除すべきか修正すべきかはどのように判断すればよいですか
コードが実際に使用されているか確認してください。grepで使用が見つからない場合は、修正するのではなく削除を検討してください。

開發者詳情

檔案結構

📄 SKILL.md