chore(agents): add test-audit skill for contributor test-quality gating

.agents/skills/build-from-issue/SKILL.md

@@ -26,7 +26,7 @@ Use a single issue comment beginning with `> **🏗️ build-plan**` when a plan
 
 1. Check the current branch and working tree. Preserve unrelated work. Create an issue-specific branch or worktree as needed, following Branch Names in `CONTRIBUTING.md`.
 2. Implement the smallest coherent change that fulfills the acceptance criteria. Update relevant skills when behavior or commands change. Keep published documentation minimal: explain exactly what users need, avoid duplication across pages, and omit internal details with no user impact.
-3. Add meaningful tests for changed behavior and follow the verification guidance in `CONTRIBUTING.md`. Select format, lint, compile or type checks, and tests for affected components and their dependencies. Run the relevant E2E lane for infrastructure, sandbox, or policy changes. Guidance and template edits need applicable Markdown, YAML, link, and consistency checks. Do not require full Rust, SDK, or repository CI solely because a commit or PR is being created; broaden checks only for a concrete remaining risk or failed check.
+3. Add meaningful tests for changed behavior and follow the verification guidance in `CONTRIBUTING.md`. Before adding or changing a test, apply the `test-audit` skill's authoring gate so new coverage protects an independent contract instead of mirroring the implementation. Select format, lint, compile or type checks, and tests for affected components and their dependencies. Run the relevant E2E lane for infrastructure, sandbox, or policy changes. Guidance and template edits need applicable Markdown, YAML, link, and consistency checks. Do not require full Rust, SDK, or repository CI solely because a commit or PR is being created; broaden checks only for a concrete remaining risk or failed check.
 4. Review the diff, use a signed-off Conventional Commit, and prepare a PR following `create-github-pr`.
 
 Every PR from this issue-backed workflow must have its own existing issue and use `Closes #<id>` in its Related Issue section. For work needing multiple PRs, split the scope into a closable issue per PR. A high-level issue may track those issues but should not be closed by an incomplete PR. Report the implementation, verification, and any remaining limitation in the PR description, rather than copying earlier issue diagnostics.

.agents/skills/review-github-pr/SKILL.md

@@ -137,6 +137,12 @@ Read through the full diff (and the PR description if available). Produce a summ
   - Do not fabricate concerns or claim a behavioral regression without evidence
     for both the prior and proposed behavior.
 - **Agent infrastructure**: When the PR changes behavior, commands, or development workflows, use the `sync-agent-infra` maintenance map to check that related skills were updated. When it adds, removes, or renames skills or crates; changes workflow relationships or skill coverage; modifies issue or PR templates; or changes agent cross-references, apply the full consistency checklist. Report missing companion updates or drift under **Potential Concerns**.
+- **Test quality**: When the PR adds or changes tests, apply the `test-audit`
+  skill's junk-pattern checks to the diff. Report an assertion-free probe,
+  implementation-coupled test, mock-only coverage of a dependency a real
+  integration test could exercise cheaply, or near-duplicate coverage under
+  **Potential Concerns** when it creates a concrete risk, rather than
+  duplicating `test-audit`'s detailed criteria here.
 
 ## Step 5: Output
 

.agents/skills/sync-agent-infra/SKILL.md

@@ -31,6 +31,7 @@ Run after adding, removing, or renaming a skill or crate; changing issue or PR c
 | Gator supervision | `launch-openshell-gator` |
 | SBOM workflow | `sbom` |
 | RFC workflow | `create-rfc` |
+| Test authoring, test-quality gating, or junk-test patterns | `build-from-issue`, `review-github-pr` |
 
 Search both `skills/` and `.agents/skills/` for affected commands, fields, and components; the map is a starting point.
 
@@ -43,6 +44,7 @@ Search both `skills/` and `.agents/skills/` for affected commands, fields, and c
 5. Check the PR template, `create-github-pr`, `build-from-issue`, `fix-security-issue`, and `CONTRIBUTING.md`: every PR must close an existing issue covering its scope, except automated dependency updates as described in `CONTRIBUTING.md`. Multi-PR work needs an issue per PR; a separate issue may track the overall effort.
 6. Check contributor branch instructions and examples against Branch Names in `CONTRIBUTING.md`; AGENTS.md and skills should refer to that convention. Check `README.md`, `.github/ISSUE_TEMPLATE/`, `.github/workflows/`, `.agents/agents/`, and related skill cross references for stale workflow statements. Keep user-facing documentation changes minimal and avoid duplicated internal explanations.
 7. Check that PR, build, TUI, and docs contribution guidance follow the scoped verification guidance in `CONTRIBUTING.md`; they must not require full Rust, SDK, or repository CI for changes that cannot affect those areas.
-8. Use `npx -y skills add . --list` from a disposable clean copy when skill discovery changes. It should expose public skills only; clean generated files afterward.
+8. **Test-audit routing** — `build-from-issue` and `review-github-pr` must route test authoring and review to the `test-audit` skill's authoring gate and junk-pattern checks without copying its detailed criteria.
+9. Use `npx -y skills add . --list` from a disposable clean copy when skill discovery changes. It should expose public skills only; clean generated files afterward.
 
 Fix contradictions, then repeat the affected checks. Report files changed and any remaining drift. Do not treat an old document's label list as a source of truth over current GitHub metadata.