菜单
Use when writing tests, measuring coverage, or running characterization, performance, or PR-review QA. Comprehensive specialist combining DDD testing, characterization tests, performance profiling, and TRUST 5 quality-assurance validation.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/modu-ai/moai-adk --skill moai-workflow-testing命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | moai-workflow-testing |
| description | Use when writing tests, measuring coverage, or running characterization, performance, or PR-review QA. Comprehensive specialist combining DDD testing, characterization tests, performance profiling, and TRUST 5 quality-assurance validation. |
| when_to_use | Use for comprehensive testing and QA: DDD domain-driven testing, characterization tests, behavior preservation, performance profiling, code and PR review, CI/CD, and TRUST 5 quality-assurance validation. |
| license | Apache-2.0 |
| compatibility | Designed for Claude Code |
| allowed-tools | Read, Write, Edit, Bash(pytest:*), Bash(ruff:*), Bash(npm:*), Bash(npx:*), Bash(node:*), Bash(jest:*), Bash(vitest:*), Bash(go:*), Bash(cargo:*), Bash(mix:*), Bash(uv:*), Bash(bundle:*), Bash(php:*), Bash(phpunit:*), Grep, Glob |
| user-invocable | false |
| metadata | {"version":"2.4.0","category":"workflow","status":"active","updated":"2026-07-10","modularized":"true","tags":"workflow, ddd, testing, debugging, performance, quality, review, pr-review","author":"MoAI-ADK Team"} |
| progressive_disclosure | {"enabled":true,"level1_tokens":100,"level2_tokens":5000} |
Unified development workflow combining DDD (domain-driven development) testing, debugging guidance, performance optimization, automated code review, and CI/CD quality gates. Emphasizes behavior preservation during refactoring through characterization tests.
Core Capabilities:
Workflow Progression: Debug → Refactor → Optimize → Review → Test → Profile
When to Use:
Five integrated components form the workflow:
Quality assessment model with five dimensions:
Overall score: weighted average with critical-dimension override (security/testability cannot be masked).
See TRUST 5 detailed dimensions and scoring for full assessment rubric.
Legacy Code (PRESERVE phase):
Greenfield Development:
All three follow a 6-step pattern: capture/analyze → classify → identify candidates → apply → verify → document.
See debugging/refactoring/performance step-by-step walkthroughs for detailed process tables.
5-step multi-agent pipeline:
See PR review multi-agent architecture and output format for agent role detail and example output.
Per-language toolchain mappings (Python pytest+ruff+bandit, JS/TS Jest+ESLint+npm audit, Go go test+staticcheck+gosec, Rust cargo test+clippy+gosec equivalents).
See multi-language toolchain reference for per-language testing/lint/security/perf tool inventory.
Three strictness modes:
Gate config: per-dimension thresholds, max issues by severity, coverage targets, perf benchmarks.
Four-stage pipeline: Code Quality → Testing → Performance → Security. Each stage terminates pipeline on failure with stage-specific failure report.
See CI/CD integration patterns (GitHub Actions + Docker) for job configuration walkthroughs.
Playwright patterns (Page Object Model, cross-browser, visual regression) and documentation-lookup integration. See Playwright best practices.
Deep-dive modules for each workflow stage. These describe conceptual workflows (not an importable SDK) — apply each with your project's own toolchain. Start at the modules index, or jump to a stage:
Status: Production Ready Last Updated: 2026-07-10 Maintained by: MoAI-ADK Development Workflow Team Version: 2.5.0 (audit remediation: language-neutrality + module re-linking)
| Rationalization | Reality |
|---|---|
| "This code is already covered by integration tests" | Integration tests catch different bugs than unit tests. The testing pyramid exists for a reason. |
| "Mocking the database is too hard, I will skip that test" | If the test is hard to write because of coupling, the code needs a better abstraction boundary. |
| "80% coverage is good enough" | Coverage targets are floors, not ceilings. The missing 20% often contains the error handling paths. |
| "These are just utility functions, they do not need tests" | Utility functions are the most reused code. A bug in a utility propagates everywhere. |
| "I ran the tests locally, CI will pass" | Environment differences cause CI-only failures. Trust CI output, not local runs. |
| "Flaky tests are normal, just re-run" | Flaky tests hide real failures. Fix the flakiness or quarantine the test explicitly. |
Shift Left: Find and fix defects as early as possible. Every test that runs in CI instead of locally adds latency. Every test that could have been a unit test but is an E2E test adds fragility.
Beyonce Rule: If you liked it, you should have put a test on it. Untested behavior is unspecified behavior.
t.Skip() or skip without an accompanying issue tracker link