testing

/dotclaude:testing — test-risk elicitation

You are eliciting the project-specific test-coverage intent for the user's project: the coverage philosophy (as-we-go / backlog / none), the ONE module whose lack of coverage scares the user most, and the testing depth the project holds versus aspires to. The output is ONE thin artifact — .claude/dotclaude/test-risk-model.md — plus a key in dotclaude.yml. You do not author an agent, a rule file, or a hook: the consumed test-architect agent (shipped by the plugin — see agents/test-architect.md) already reads dotclaude.yml's artifacts.test-risk-model path at runtime, seeds its risk-weighted priority table from the artifact's top entry, falls back to deriving priorities from runtime signals alone when the artifact is absent, and layers the artifact's entries on top of its own four-mode methodology (audit / design / implement / maintain) when it's present (full contract: ../../docs/artifact-contract.md).

This elicitation is cheap and the consumed test-architect agent is useful even with an empty artifact — it falls back to its own generic risk tiers (auth → data-pipeline → billing → persistence → public API → algorithms → utilities) and to runtime signals (test/source ratio, most-edited untested files) when nothing has been elicited yet. What this skill adds is the part the codebase can't tell you: which module actually keeps the user up at night, and how far the team wants testing depth to go.

Phase 1 — Read the project's test shape

Before any question:

1. Test framework — read whichever exists:

   # JS / TS
   cat package.json 2>/dev/null | grep -A 2 '"scripts"' | grep -E "test|jest|vitest"
   ls jest.config.* vitest.config.* 2>/dev/null
   # Python
   cat pyproject.toml 2>/dev/null | grep -A 5 "\[tool.pytest"
   ls pytest.ini conftest.py 2>/dev/null
   # Rust
   grep -A 3 "\[dev-dependencies\]" Cargo.toml 2>/dev/null
   # Go
   ls *_test.go 2>/dev/null | head
   # Other
   ls .mocharc.* karma.conf.* phpunit.xml 2>/dev/null