القائمة
Use before moe.complete_task. Runs the suite the plan named — narrow for a mid-epic task, full for the epic's final task — to confirm nothing unrelated broke. The goal is zero regressions. Better to find out now than in a QA reject comment.
التثبيت باستخدام 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 | regression-check |
| description | Use before moe.complete_task. Runs the suite the plan named — narrow for a mid-epic task, full for the epic's final task — to confirm nothing unrelated broke. The goal is zero regressions. Better to find out now than in a QA reject comment. |
| when_to_use | Worker, after the final implementation step is done, before moe.complete_task. |
| allowed-tools | Bash, Read |
Before moe.complete_task — once, not after every step — run the suite the plan named. The goal is zero regressions. Finding out now is cheap; finding out from a qa_reject is expensive.
The plan sizes this deliberately; don't silently upgrade it.
Unsure of your position? moe.list_tasks {epicId} and compare order. No siblings after you → treat it as epic-final.
The plan should name the suite. If it doesn't, work out from your changes:
| Touched | Run at minimum |
|---|---|
packages/moe-daemon/src/... | cd packages/moe-daemon && npm test |
packages/moe-proxy/src/... | cd packages/moe-proxy && npm test |
moe-jetbrains/src/... | cd moe-jetbrains && ./gradlew test |
| Multi-package or shared types | All of the above |
| Scripts / wrappers | Manually exercise the wrapper end-to-end |
| Docs only | Optional; lint the markdown |
If a project has a test:all or npm run check script, prefer that — it usually wires lint + type-check + tests in the right order.
complete_step summary as evidence. Don't claim green without numbers.complete_task. Usual suspects: shared util change, type-signature change, fixture / seed dependency, test ordering.Once you're in the full-scope case above, it's tempting to still run only the tests in the package you edited. Don't. Cross-package dependencies are exactly where regressions hide. Specifically:
schema.ts ripple through every tool and the plugin.load() for every existing .moe/.For everything else, run something — narrow or full per the sizing above. Skipping entirely is what turns 90 saved seconds into a 4-hour qa_reject round trip.
Be specific. Not "tests pass" — "342 / 342 tests pass; ran npm test in moe-daemon and moe-proxy; type-check clean." Numbers + commands let QA verify quickly without re-running everything.