hellblazer/receiving-review
nx/skills/receiving-review/SKILL.md
Use when receiving any code review feedback, before implementing any suggestion - requires technical rigor and verification, not performative agreement or blind implementation
$ install --global
skillsauthnpx skillsauth add hellblazer/nexus receiving-reviewInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 25, 2026, 9:34 PM1.9s1 file scanned
SKILL.md
- name:
- receiving-review
- description:
- Use when receiving any code review feedback, before implementing any suggestion - requires technical rigor and verification, not performative agreement or blind implementation
- effort:
- medium
Receiving Code Review Feedback
Code review requires technical evaluation, not emotional performance.
Response Pattern
1. READ — complete feedback without reacting
2. UNDERSTAND — restate requirement in own words (or ask)
3. VERIFY — check claims 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
Rules
Never say: "You're absolutely right!", "Great point!", "Thanks for catching that!" Instead: State the fix, or push back with technical reasoning. Actions > words.
If any item is unclear: STOP. Ask for clarification on ALL unclear items before implementing any.
If suggestion seems wrong: Push back with technical reasoning — reference working tests, existing code, or architectural decisions.
Handling External Review Feedback
Before implementing, verify:
- Technically correct for THIS codebase?
- Breaks existing functionality?
- Reason for current implementation?
- Does reviewer understand full context?
- Conflicts with prior architectural decisions?
If can't verify: say so. "I can't verify this without [X]. Should I investigate?"
YAGNI Check
When reviewer suggests "implement properly": use /nx:serena-code-nav to find all callers before accepting. If unused: "This isn't called anywhere. Remove it (YAGNI)?"
Implementation Order
For multi-item feedback:
- Clarify anything unclear FIRST
- Blocking issues (breaks, security)
- Simple fixes (typos, imports)
- Complex fixes (refactoring, logic)
- Test each fix individually
- Verify no regressions
When to Push Back
- Suggestion breaks existing functionality
- Reviewer lacks full context
- Violates YAGNI (unused feature)
- Technically incorrect for this stack
- Conflicts with architectural decisions
Acknowledging Correct Feedback
✅ "Fixed. [Brief description of what changed]"
✅ "Good catch — [specific issue]. Fixed in [location]."
✅ [Just fix it and move on]
Correcting a Wrong Pushback
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 read was wrong because [reason]. Fixing."
State the correction factually. No apology, no over-explaining.
GitHub Thread Replies
Reply in the comment thread (gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies), not as a top-level PR comment.
Related Skills
hellblazer/review
development
VerifiedTrustedCommunity
Use when critiquing / auditing / reviewing a change set against decision history — tries the review plan library first (catalog lookup → decision-evolution traversal → extract → compare), falls through to /nx:query if nothing matches
1SKILL.mdUpdated Apr 17, 2026
hellblazer/research
documentation
VerifiedTrustedCommunity
Use when doing design / architecture / planning work that walks from prose (RDRs, docs, knowledge) into the modules implementing a concept
1SKILL.mdUpdated Apr 17, 2026
hellblazer/plan-promote
development
VerifiedTrustedCommunity
Use when surveying the plan library's runtime metrics to propose plans for promotion to a higher scope — advisory-only; dispatches the plan-promote-propose meta-seed (no lifecycle ops — those ship in RDR-079)
1SKILL.mdUpdated Apr 17, 2026
hellblazer/plan-inspect
business
VerifiedTrustedCommunity
Use when inspecting plan runtime metrics or enumerating dimension-registry usage — dispatches plan_match with dimensions={verb:plan-inspect}; strategy:default reports per-plan metrics, strategy:dimensions reports registry usage counts
1SKILL.mdUpdated Apr 17, 2026