← DXD SkillsCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to DXD Skills
Snapshot Sep 30, 2026 · 23:18 UTC · version 0.3.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"name": "test-audit",
"description": "Evaluate proposed or existing tests for meaningful regression protection, duplication, implementation coupling, and test-only production seams. Use when writing substantive tests or when asked to review, simplify, or prune a test suite.",
"included_files": [
{
"relative_path": "LICENSE",
"size_in_bytes": 1076
}
],
"skill_md_contents": "---\nname: test-audit\ndescription: >-\n Evaluate proposed or existing tests for meaningful regression protection, duplication,\n implementation coupling, and test-only production seams. Use when writing substantive\n tests or when asked to review, simplify, or prune a test suite.\n---\n\n# Test Audit\n\nImprove confidence per test maintained. Apply the value check when adding or changing\ntests; use the audit workflow for an existing suite. Keep the scope tied to the\nuser's task rather than expanding an ordinary edit into a repository-wide sweep.\n\n## Value check for a proposed test\n\nBefore adding a test, identify:\n\n- The observable behavior, invariant, or independent contract it protects.\n- A credible regression that would make it fail for the intended reason.\n- Why existing tests do not already cover that regression at a stronger boundary.\n- Whether it requires an export, flag, injection hook, wrapper, or other production\n seam that no production caller needs.\n\nIf those answers are unclear, revise the test or omit it. Prefer extending a\nparameterized case or an existing owner suite over repeating the same scenario at\nanother layer. For a bug regression, demonstrate a pre-fix failure for the\nintended reason when practical, then verify it passes after the fix.\n\n## Audit candidates\n\nLook for tests that cannot detect a meaningful failure, including:\n\n- Assertion-free runs, self-comparisons, or expectations calculated by the same\n helper being tested.\n- Exact source, import, string, export-list, or fixture inventories that merely\n mirror implementation and break under behavior-preserving refactors.\n- Private call-shape or predicate checks already protected by a public boundary.\n- Repeated scenarios across unit, integration, and end-to-end layers without a\n distinct risk at each layer.\n- Mocks that supply the very behavior being asserted, or negative cases that\n pass because an unrelated guard rejects the request first.\n- Tests kept only to justify production code with no non-test caller.\n- Test names that promise a contract the assertions do not actually exercise.\n\nThese are leads, not automatic deletion rules. Keep a test when it independently\nguards a public API, protocol, configuration, migration, storage, security,\nplatform, release, or other meaningful contract. Source inspection can be the\nright guard when a specific byte, key, or path is itself the contract. Slow or\nstatic tests are not inherently low value.\n\n## Audit workflow\n\n1. Read applicable repository instructions. Identify the requested scope, the\n production owner, its callers, existing test layers, and CI routing. Check\n relevant history before calling a test obsolete.\n2. Discover candidates without editing. For each candidate, record its path and\n test name, the failure it can detect, overlap with stronger proof, and any\n production or test-support code it alone keeps alive.\n3. Classify each candidate as retain, repair, consolidate, or remove. Name the\n surviving owner for every contract moved or deleted. If proof is uncertain,\n retain the test and report the uncertainty.\n4. Make one coherent change at an ownership boundary. Remove a test-only seam\n only after confirming it has no production caller and its contract remains\n covered. Preserve unrelated tests and behavior.\n5. Run the smallest relevant test command and any required project checks.\n Confirm moved assertions can fail for the intended regression when feasible.\n Inspect the diff for lost coverage, accidental production changes, and\n whitespace errors.\n\nFor a whole-subsystem audit, baseline the current tests first, group them by\nbehavioral owner, and work through those groups in reviewable batches. Recheck\ncoverage after each batch instead of optimizing for deletion count. Treat a\nfailing retained test as a possible product defect, not a reason to discard it.\n\n## Handoff\n\nReport what was retained, repaired, consolidated, or removed; the contract that\nremains protected; any production seam simplified; the checks actually run; and\nunresolved coverage risks. Distinguish pre-existing failures from changes caused\nby the audit.\n\n## Source\n\nAdapted from [OpenClaw's Test Audit skill](https://github.com/openclaw/openclaw/blob/main/.agents/skills/test-audit/SKILL.md),\ncopyright © 2026 OpenClaw Foundation, under the MIT License. See [LICENSE](LICENSE).\n"
}SHA-256: b4556823bd5763e0f9d737aa34b5de3dbbce3c4a0243e1dffbfc8112d656c3fe