Menu
Responding to feedback
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always. Upgraded with AC-first workflow, pre-flight fast-fail, and structured Judge verdicts (inspired by opslane/verify).
Guide for creating Claude Code skills following Anthropic's official best practices. Use when user wants to create a new skill, build a skill, write SKILL.md, or needs skill creation guidelines. Provides structure, naming conventions, description writing, and quality checklist.
Pattern for progressively refining context retrieval to solve the subagent context problem
Fast iteration with two-stage review (spec compliance, then code quality)
Multi-agent coordination SOP derived from Anthropic's internal coordinator architecture. Use when orchestrating parallel workers, dispatching subagents, planning multi-step implementations, or when tasks require research→synthesis→implementation→verification workflow. Triggers: 'coordinate', 'dispatch workers', 'parallel agents', 'multi-agent', 'fan out', 'orchestrate'.
Use to run multiple subagents concurrently on independent tasks
| name | receiving-code-review |
| description | Responding to feedback |
Code review requires technical evaluation, not emotional performance.
Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.
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:
INSTEAD:
IF any item is unclear:
STOP - do not implement anything yet
ASK for clarification on unclear items
WHY: Items may be related. Partial understanding = wrong implementation.
Example:
your human partner: "Fix 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."
Assume: They have business context you lack. Verify: The technical implication of their request. Action: If request breaks architecture -> Push back gently with reasoning + alternative.
Assume: They may lack context or be misinformed. Verify: Everything. Action: Defend the code if it's correct. Accept if they found a real bug.