plan-page
Write, check, repair and publish a plan page: a project's plans and subject files under its…
Audit existing tests for low-value, duplicated or implementation-coupled cases and the test-only code they keep alive, then remove or rewrite them on evidence. Use for test-audit, /test-audit <scope>, a test sweep, or pruning tests. Not for writing a new test; the project's
$ npx -y skills add udecode/dotai --skill test-audit --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/test-auditContext preview
The summary Claude sees to decide when to auto-load this skill.
Audit existing tests for low-value, duplicated or implementation-coupled cases and the test-only code they keep alive, then remove or rewrite them on evidence. Use for test-audit, /test-audit <scope>, a test sweep, or pruning tests. Not for writing a new test; the project's
name: test-audit description: "Audit existing tests for low-value, duplicated or implementation-coupled cases and the test-only code they keep alive, then remove or rewrite them on evidence. Use for test-audit, /test-audit <scope>, a test sweep, or pruning tests. Not for writing a new test; the project's Tests rule gates that."
Adapted from openclaw's `test-audit` skill (MIT, OpenClaw Foundation; see [LICENSE](LICENSE)).
Judge the result by how much the remaining tests can be trusted, never by how many were deleted. A test is worth keeping when it protects observable behavior, a credible regression, or an independent contract: a public API, protocol, config, migration, storage, security, platform, default, generated, package, release or architecture contract. Static or slow is never a reason to delete.
Take the user's scope, or the files they name. Read the root and scoped `AGENTS.md` first; their Tests rule is the bar for every test this audit keeps, rewrites or moves. Leave out skills and code installed from another repository.
1. For a broad scope, split it into read-only lanes by owner area and run them in parallel. 2. For each candidate, read the whole test, its production owner, the owner's callers, the overlapping tests, CI routing and history. When a test claims behavior a dependency provides, read that dependency. 3. Prove what a test catches by mutating a scratch copy of its owner and running the test against it, never by editing the checkout. 4. Prefer a few high-confidence candidates over a long speculative list. Report the evidence before editing.
Keep a test that independently enforces one of the contracts listed at the top, and keep:
A test that resembles the implementation may still be the independent contract. Prove otherwise before removing it.
Record every field before editing; a missing field means the candidate is not ready:
Change one coherent owner-boundary batch at a time. Delete obsolete test-only exports, globals, wrappers and dead production paths instead of keeping aliases. Move a retained regression to its canonical owner, and fold near-duplicates into the shared fixture. Prefer a change that removes more production lines than it adds. Add no replacement test that restates the implementation, and never turn an uncertain candidate into a deletion to raise the count. Before the first edit to a file that holds another session's work, copy it to scratch.
1. Run the owner's and its siblings' tests with the project's own runners. 2. Run each rewritten test against its named mutant and see it fail. 3. For a removed grep or plan assertion, run the executable that owns the real contract. 4. Regenerate anything the edited files feed, such as skill mirrors or a manifest, and run its check. 5. Report production and test line counts separately, measured against the scratch copies when the index holds other sessions' work.
Review and delivery follow the project's `AGENTS.md`.
Report the removed low-value categories, the production simplifications, the retained false positives and why they stay, the proof actually run, production and test line counts, the commit or PR state, and named follow-ups with owners. In a project with plan pages, write this in the plan's `## Close`.
Shared skills that the pstack plugin does not cover: test audits (test-audit, adapted from openclaw's), screenshot walkthroughs and video transcripts, and pstack setup, sync and skill-drift audits (sync-pstack).
Repo: udecode/dotai
Write, check, repair and publish a plan page: a project's plans and subject files under its…
Set up the pstack plugin in a project through an interview, and keep every pstack project on…
Transcribe a supplied local or linked video with Gemini Files API when its contents are…
Present final screenshots or rendered artifacts as an annotated walkthrough when visual…