菜单
Build a focused, evidence-backed test plan from `mastermind impact` or `mmcg_test_impact`. Use when deciding which tests to run for a change, explaining direct/transitive/heuristic candidates, or sequencing fast feedback before the repository's required full test gate.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Turn a design handoff into a task contract that can actually be checked — named source, resolved components, token names instead of raw values, and an explicit list of what stays unverifiable. Use when a Figma frame, mockup, or design spec is handed over for implementation.
Convert a PRD, ticket, or feature request into a task contract that can fail — behaviour split from outcome, product nouns resolved to symbols that exist, unspecified cases surfaced as questions, and success metrics parked where a merge gate cannot wave them through. Use when product writing is handed over for implementation.
Enumerate what a change can reach and what enforces it — privileged operations and their callers, guards and the sites that apply them, and every module that reads a secret — before designing an auth, permission, or secrets change. Feeds the security review; produces a population and a gap list, never a verdict.
Read-only review of whether the tests in a finished change actually prove its behaviour — changed code no test reaches, a test exercising a different path than the one that changed, an assertion edited to match the new output, and a suite that ran nothing. Use after implementation, and whenever a change claims to be covered.
Gather who already depends on a service, handler, or state owner before changing it, and name the runtime gaps the codegraph cannot span. Use before designing a change to an API, queue consumer, background job, migration, or shared state; it feeds the architecture review rather than replacing it.
Read-only review of a finished UI change against the codegraph — a component nothing renders, a props contract changed without its callers, a reinvented component, or a raw value where the design system has a token. Use after implementing React or Vue work; triggers "review this UI change", "check the component", or a finished frontend diff.
| name | mastermind-test-impact |
| description | Build a focused, evidence-backed test plan from `mastermind impact` or `mmcg_test_impact`. Use when deciding which tests to run for a change, explaining direct/transitive/heuristic candidates, or sequencing fast feedback before the repository's required full test gate. |
| metadata | {"version":"0.1.0","authors":["mastermind"],"tags":["workflow","testing","mmcg"]} |
Use deterministic candidates to prioritize feedback. Never treat them as proof that omitted tests are unnecessary.
Choose the same trusted baseline and fresh index used for change analysis.
Run mastermind status first. Stop on index_stale unless re-indexing is
authorized; never infer candidates from a stale graph.
Run mastermind impact --since REF --format json, or call
mmcg_test_impact for the exact test projection.
Reject a response that omits the
focused_tests_do_not_replace_full_gate caveat.
Group candidates in this order:
direct: a changed test symbol at depth 0 or a graph-linked test at depth 1;transitive: a graph-linked test at greater depth;heuristic: a filename/component candidate without a proven call path.For each test, retain file, symbol, line, depth, confidence, changed-symbol seeds, and structured evidence. Explain collisions or weak language edges.
Run focused tests from high to low confidence for fast feedback, then run every project-required phase/final gate.
Do not invent framework commands. Discover them from repository configuration
and the task spec. Do not call a heuristic candidate “covered”. If graph and
heuristic work were skipped with work_limit, report that no classified
candidates are available. A separately labeled fallback may widen by changed
modules and repository-owned test commands, but it is not direct,
transitive, or heuristic response evidence. Always retain the full gate.