receiving-code-review
Use when addressing code review or QA feedback, especially when the feedback is unclear, broad, or technically questionable.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Use when addressing code review or QA feedback, especially when the feedback is unclear, broad, or technically questionable.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
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.
Use when reviewing a diff, PR, or patch for bugs, regressions, missing tests, architecture risk, security risk, or reviewability concerns before merge.
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.
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.
Use when the user explicitly asks Guardian to launch or check an external coding assistant such as Codex, Claude Code, Gemini CLI, or Aider.
Use when the request is about a repo, codebase, implementation, bugfix, or backend-owned coding session that should stay anchored to the active workspace.
| name | receiving-code-review |
| description | Use when addressing code review or QA feedback, especially when the feedback is unclear, broad, or technically questionable. |
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.
| 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. |