メニュー
Handle code review feedback with technical rigor — verify before implementing, push back when reviewer is wrong, no performative agreement. Use when receiving feedback from Centinela, external reviewers, or PR comments.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Post-implementation business assessment by Prometeo (PM). Verifies success metrics achievement, scope compliance, acceptance criteria business interpretation, risk materialization, and product decision closure. Outputs structured report with verdict and confidence score.
Analyzes checklist effectiveness by tracking hit rates, identifying stale items, and finding coverage gaps. Generates evolution suggestions following Boorman's principles. Use periodically to keep checklists field-tested and relevant.
Scans the codebase for dead code, tech debt, outdated dependencies, and code quality issues. Use periodically or before releases to maintain code hygiene.
Creates a complete product feature specification. Use when defining new features, writing user stories, or planning product work. Generates structured specs in docs/specs/.
Generates test cases for a module or function following FIRST principles and Arrange-Act-Assert pattern. Detects test framework from project config. Use to bootstrap test coverage for existing code or as the Red phase of TDD.
Create and manage git worktrees for isolated feature work. Use when starting implementation that should not touch the main workspace, or for parallel development. Handles creation, baseline verification, and cleanup.
| name | receiving-code-review |
| description | Handle code review feedback with technical rigor — verify before implementing, push back when reviewer is wrong, no performative agreement. Use when receiving feedback from Centinela, external reviewers, or PR comments. |
Handle feedback on: $ARGUMENTS
WHEN receiving code review feedback:
1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask)
3. VERIFY: Check against codebase reality
4. EVALUATE: Technically sound for THIS codebase?
5. RESPOND: Technical acknowledgment or reasoned pushback
6. IMPLEMENT: One item at a time, test each
NEVER say:
INSTEAD:
IF any item is unclear:
STOP — do not implement anything yet
ASK for clarification on ALL unclear items
WHY: Items may be related. Partial understanding = wrong implementation.
Example:
Reviewer: "Fix items 1-6"
You understand 1,2,3,6. Unclear on 4,5.
WRONG: Implement 1,2,3,6 now, ask about 4,5 later
RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."
BEFORE implementing:
1. Technically correct for THIS codebase?
2. Breaks existing functionality?
3. Reason for current implementation?
4. Works on all platforms/versions?
5. Does reviewer understand full context?
IF suggestion seems wrong:
Push back with technical reasoning
IF conflicts with existing architectural decisions:
Check ADRs in docs/adr/ first, then discuss
IF reviewer suggests "implementing properly" or adding features:
Check: Is this actually used?
IF unused: "This isn't called anywhere. Remove it (YAGNI)?"
IF used: Then implement properly
FOR multi-item feedback:
1. Clarify anything unclear FIRST
2. Then implement in this order:
- Blocking issues (breaks, security)
- Simple fixes (typos, imports)
- Complex fixes (refactoring, logic)
3. Test each fix individually
4. Verify no regressions
Push back when:
How to push back:
When feedback IS correct:
"Fixed. [Brief description of what changed]"
"Good catch — [specific issue]. Fixed in [location]."
[Just fix it and show in the code]
Actions speak. The code itself shows you heard the feedback.
If you pushed back and were wrong:
"You were right — I checked [X] and it does [Y]. Implementing now."
"Verified and you're correct. My initial understanding was wrong because [reason]. Fixing."
State the correction factually and move on. No long apology.
| Thought | Reality |
|---|---|
| "The reviewer is probably right" | Verify first. Reviewers can be wrong too |
| "Just implement it to move forward" | Bad fixes create more work later |
| "I'll push back later" | Push back now with reasoning, or implement now |
| "This is just a style thing" | If it's just style, say so. Don't silently comply |
| "I don't want to seem difficult" | Technical correctness > social comfort |