القائمة
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use before calling moe.complete_step on the final step of a task, and again before moe.complete_task. Forces you to read your own diff as an attacker, not an author. Catches concurrency bugs, null-deref, embarrassing assumptions before QA does.
Use when writing, reviewing, or debugging modern C++ (C++11 and beyond) — .cpp/.cc/.cxx/.h/.hpp files, CMake builds, smart pointers, RAII, move semantics, templates, STL, or concurrency.
Use before referencing any function, model, method, relationship, constant, or import in a plan or implementation. Verifies things actually exist in the codebase before building on top of them. Eliminates an entire class of hallucinated-API bugs.
Use when an architect is turning an epic into a set of tasks (moe.create_task), before planning any single one. Covers where to cut the seams, how to size and order tasks, what each task's Definition of Done must carry, and the mandatory final integration-and-hardening task. Distinct from moe-planning, which plans the steps inside one task.
Use when an architect is turning a Moe task into an implementation plan via moe.submit_plan. Provides the canonical 8-phase template (plan, explore, tests, minimum impl, verify, document, adversarial review, QA loop), rules for when to skip phases on trivial tasks, and where the verification gate belongs — once at the end of a task, and at full scope only on the epic's final task.
Use when reviewing a task in REVIEW status as the QA agent. Provides the structured decision flow for moe.qa_approve vs moe.qa_reject, with rejectionDetails that drive a clean fix on the worker side.
| name | receiving-code-review |
| description | Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation |
Code review requires technical evaluation, not emotional performance. Verify before implementing. Ask before assuming. Technical correctness over social comfort.
NEVER write:
INSTEAD: restate the requirement, ask clarifying questions, push back with technical reasoning, or just start working. Actions > words. If you catch yourself typing "Thanks", delete it.
If any item is unclear, do NOT implement anything yet. Ask for clarification on the unclear items first. Items may be related; partial understanding produces wrong implementations.
Wrong: "I'll implement 1,2,3,6 now and ask about 4,5 later." Right: "I understand 1,2,3,6. Need clarification on 4 and 5 before proceeding."
Push back when:
How: technical reasoning, not defensiveness. Ask specific questions. Reference working tests/code.
If a reviewer says "implement properly", grep the codebase for actual usage. If unused, push: "This isn't called. Remove it (YAGNI)?" If used, then implement properly.
For multi-item feedback:
State the fix factually:
No gratitude. No performative agreement.
If you pushed back and were wrong: "You were right — I checked X and it does Y. Implementing now." No long apology, no defending, no over-explaining.
This skill loads when nextAction.recommendedSkill = receiving-code-review — typically after moe.qa_reject (task is back in WORKING with reopenCount > 0 and rejectionDetails populated).
When you receive a QA rejection:
rejectionDetails first. Don't start fixing until you understand every item.moe.add_comment on the task channel with technical reasoning. Don't silently ignore; don't silently implement.moe.start_step per item — don't batch unrelated fixes.moe.complete_task summary.Never include performative gratitude in moe.add_comment. State what you changed.