القائمة
Use when implementing any feature or bugfix, before writing implementation code
التثبيت باستخدام 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 | test-driven-development |
| description | Use when implementing any feature or bugfix, before writing implementation code |
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
If you wrote code first, delete it and start over. Don't keep it as "reference" — you'll adapt it, which is testing-after, which is not TDD.
assert(result), expect(items).toBeTruthy(), expect(fn).not.toThrow()expect(result.status).toBe('completed'), expect(items).toEqual(['a','b','c'])Run the test. Confirm: it fails (not errors), the failure message matches what you expect, it fails because the feature is missing (not a typo).
If it passes, you're testing existing behaviour — fix the test. If it errors, fix the error and re-run until it fails for the right reason.
Simplest code that passes. No options bag, no extra branches, no "while I'm here" cleanup.
Test passes, other tests still pass, output pristine. If a test fails: fix the code, not the test.
Remove duplication, improve names, extract helpers. No new behaviour. Tests stay green.
Always: new features, bug fixes, refactors, behaviour changes. Exceptions (ask first): throwaway prototypes, generated code, config files. "Just this once" is rationalization.
Bug found → write a failing test that reproduces it → run → see it fail → fix → run → see it pass. Never fix a bug without a test.
If you can't tick all boxes, you skipped TDD — start over.
| Problem | Move |
|---|---|
| Don't know how to test | Write the wished-for API as the test, then build to it. |
| Test too complicated | Design too complicated — simplify the interface. |
| Need to mock everything | Code too coupled — use dependency injection. |
| Test setup huge | Extract helpers; if still huge, simplify the design. |
moe.start_step → implement → moe.complete_step cycle on test-touching steps.moe-planning Phase 3).moe.complete_task, pair with verification-before-completion — capture the actual test-run output (count + pass/fail) in your complete_step summary so QA has evidence rather than a claim.