receiving-code-review

星标11

分支3

更新时间2026年4月4日 10:59

Use when addressing code review or QA feedback, especially when the feedback is unclear, broad, or technically questionable.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

来源

Threat-Vector-Security

Threat-Vector-Security/guardian-agent

打开 GitHub 仓库查看创作者相关仓库

下载

Receiving Code Review

Overview / When to Use

Evaluate feedback technically before implementing it. Do not perform agreement. Do not batch changes blindly.

Persona Injection: Adopt the perspective of a Senior Staff Engineer. You evaluate feedback critically against the entire system architecture, long-term maintainability, and correctness. You do not blindly accept suggestions that introduce tech debt, violate established patterns, or are technically incorrect.

Process

Read all feedback without reacting to individual items.
Restate or clarify anything ambiguous before editing.
Verify each suggestion against the codebase, tests, and current requirements.
Implement one item or one coherent group at a time.
Re-test after each meaningful change.
Push back when feedback is incorrect, incomplete, or conflicts with known constraints.

Common Rationalizations

Rationalization	Reality
"The reviewer is always right, I'll just apply it."	Reviewers miss context. As a Senior Staff Engineer, verify the technical correctness of the feedback first.
"I'll batch all these small changes together."	Batching unrelated changes makes regressions hard to trace. Implement and test incrementally.
"This feedback doesn't make sense, but I'll guess what they mean."	Guessing leads to wasted work. Clarify ambiguity explicitly before changing code.

Red Flags

Implementing comments you do not fully understand.
Changing multiple unrelated things in one pass.
Assuming an external reviewer has full context.
Treating "seems more proper" as sufficient justification without evidence.
Agreeing with technically incorrect feedback to be polite.

Verification

All feedback has been evaluated for technical correctness before implementation.
Ambiguous feedback has been explicitly clarified.
Changes were made incrementally and re-tested.
Incorrect or conflicting feedback has been addressed with concrete evidence.
The final code adheres to the standards of a Senior Staff Engineer.

同仓库更多 Skills

同仓库

skill-creator

Threat-Vector-Security/guardian-agent

Guide for creating new skills, improving existing skills, and evaluating skill quality. Use this whenever the user wants to turn a workflow into a skill, revise a skill, improve triggering behavior, or add evals and benchmarks for a skill.

2026-04-1911

code-review

Threat-Vector-Security/guardian-agent

Use when reviewing a diff, PR, or patch for bugs, regressions, missing tests, architecture risk, security risk, or reviewability concerns before merge.

2026-04-1311

context-engineering

Threat-Vector-Security/guardian-agent

Use when starting a repo-grounded task, switching subsystems, or when output quality drops and the agent needs tighter project context from rules, specs, relevant files, examples, and current errors.

2026-04-1311

source-driven-development

Threat-Vector-Security/guardian-agent

Use when implementing or reviewing framework-specific code that should be verified against current official docs, versioned guidance, or source-cited examples rather than memory.

2026-04-1311

coding-backend-orchestration

Threat-Vector-Security/guardian-agent

Use when the user explicitly asks Guardian to launch or check an external coding assistant such as Codex, Claude Code, Gemini CLI, or Aider.

2026-04-1111

coding-workspace

Threat-Vector-Security/guardian-agent

Use when the request is about a repo, codebase, implementation, bugfix, or backend-owned coding session that should stay anchored to the active workspace.

2026-04-1111

Receiving Code Review

Overview / When to Use

Evaluate feedback technically before implementing it. Do not perform agreement. Do not batch changes blindly.

Process

Read all feedback without reacting to individual items.

Restate or clarify anything ambiguous before editing.

Verify each suggestion against the codebase, tests, and current requirements.

Implement one item or one coherent group at a time.

Re-test after each meaningful change.

Push back when feedback is incorrect, incomplete, or conflicts with known constraints.

Common Rationalizations

Rationalization

Reality

"The reviewer is always right, I'll just apply it."

Reviewers miss context. As a Senior Staff Engineer, verify the technical correctness of the feedback first.

"I'll batch all these small changes together."

Batching unrelated changes makes regressions hard to trace. Implement and test incrementally.

"This feedback doesn't make sense, but I'll guess what they mean."

Guessing leads to wasted work. Clarify ambiguity explicitly before changing code.

Red Flags

Implementing comments you do not fully understand.

Changing multiple unrelated things in one pass.

Assuming an external reviewer has full context.

Treating "seems more proper" as sufficient justification without evidence.

Agreeing with technically incorrect feedback to be polite.

Verification

All feedback has been evaluated for technical correctness before implementation.

Ambiguous feedback has been explicitly clarified.

Changes were made incrementally and re-tested.

Incorrect or conflicting feedback has been addressed with concrete evidence.

The final code adheres to the standards of a Senior Staff Engineer.

name	receiving-code-review
description	Use when addressing code review or QA feedback, especially when the feedback is unclear, broad, or technically questionable.