test

name	test
description	Generate tests and coverage plans. Triggers: "test", "generate tests and coverage plans.", "test skill".
practices	["tdd","property-based-testing","bdd-gherkin"]
hexagonal_role	supporting
consumes	["standards","repo-context"]
produces	["test-evidence"]
context_rel	[]
skill_api_version	1
context	{"window":"fork","intent":{"mode":"task"},"sections":{"exclude":["HISTORY"]},"intel_scope":"topic"}
metadata	{"capabilities":["test"],"effects":["write_test_files","write_test_evidence","modify_source_files"],"canonical_status":"canonical","disposition":"keep_specialist","tier":"execution","dependencies":[]}
output_contract	test files, coverage report

Test Skill

Generate real tests, run them, and leave reproducible coverage or TDD evidence. Do not stop at a plan unless the requested mode is strategy.

Critical Constraints

• Why: behavior is the contract. Derive tests from acceptance scenarios and public behavior, not implementation details or coverage percentages alone.
• Why: prove new behavior. In TDD mode record a real failing test before the minimal implementation; a test that starts green is not RED evidence.
• Why: avoid false confidence. Assert exact values, error types/messages, and branch outcomes; ban zero-assertion, tautological, and padding tests.
• Why: keep suites trustworthy. Tests must be deterministic, isolated, and independent of timing, ordering, production services, or mutable shared state.
• Why: protect user intent. Report a product bug discovered by a test; do not silently change product behavior or delete existing tests without approval.
• Why: close with proof. Run the narrow test after each edit, then the relevant suite and coverage command before handing work downstream.

Modes

Mode	Use when	Required result
generate	writing tests for existing code	passing focused and suite tests
coverage	finding and filling important gaps	before/after coverage plus tests
tdd	implementing new behavior test-first	logged RED → green → refactor cycles
strategy	designing test architecture only	inventory, risks, and recommendations

Default to generate. Flags: --mode, --scope, --min-coverage, and --dry-run narrow the workflow but never weaken its evidence requirements.

Oracle-strength hierarchy

Every test asserts through an oracle, and oracles are not equal. Rank them:

exact value > property/invariant > differential (two implementations agree) > smoke (it ran)

Choose the strongest oracle the behavior admits and name the oracle-strength tier when a test uses anything below exact. A smoke assertion where an exact one was available is the failure mode: the test runs the code but proves almost nothing about it. Stop condition: no acceptance scenario may be covered only by smoke-tier tests when a stronger oracle is practical; if only smoke is practical (e.g. nondeterministic external output), record why in so the gap is a visible decision, not an accident.