メニュー
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.