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 저장소 열기 Creator 저장소 보기

다운로드

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.