com um clique
ds-test-mode
Activate pragmatic testing mode for this session.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Menu
Activate pragmatic testing mode for this session.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Design a target architecture for a new system — module boundaries, dependency rules, seams, and build order — from its requirements. Reports a blueprint; changes nothing.
Analyze an existing codebase's architecture and produce a sequenced refactoring plan — assess module boundaries, dependency structure, and layering, then lay out ordered, risk-tagged steps. Language-agnostic. Reports a plan; changes nothing.
Turn a goal or another command's output into an ordered task roadmap.
Find the root cause of a failure with the scientific method — reproduce, isolate, fix, then prove it.
Interview the user relentlessly about a plan or design until reaching shared understanding.
Run an extremely strict maintainability + single-source-of-truth review of code changes — abstraction quality, file sprawl, spaghetti-condition growth, and duplicate/competing implementations. Reports findings by default; `--fix` applies the mechanical, unambiguous ones — structural/code-judo restructurings rest on judgment and stay reported.
| name | ds-test-mode |
| description | Activate pragmatic testing mode for this session. |
| disable-model-invocation | true |
When active, make sure the things that matter get well tested as you build — without test-first ceremony. This is the pragmatic sibling of /ds-tdd-mode: /ds-tdd-mode drives the design by writing the test first; this rides alongside normal work and ensures the risk is covered before you call something done. To audit tests that already exist, use /ds-test-quality-review.
Test by risk, not by rule. Spend tests where a failure would actually hurt:
Skip the trivia — getters, glue code, framework behavior, the obvious. A test there is maintenance with no payoff.
A test coupled to implementation is a liability, not an asset — it taxes every change and trains the team to ignore red. As you write tests, avoid:
Prefer fewer, sharper tests that would each catch a real failure over many that chase coverage. Coverage is a side effect of testing the right things, never the goal.
Confirm activation with "Pragmatic testing mode active." Activating a mode only turns on this posture; it is not approval to begin work — continue with whatever the user already asked for, or wait for their next instruction.