メニュー
Write clean, behavior-focused unit/integration tests that remain trustworthy when code is written or modified by agents (prevents “test weakening”, enforces invariants, and adds CI guardrails).
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use this skill when you need to diagnose and fix React 19 performance issues (render churn, slow updates, Suspense/Transitions, memoization, profiling, and React Compiler).
Use this skill when you are creating or updating Agent Skills in your project (structure, YAML frontmatter, naming, and progressive disclosure).
Use this skill when designing or refactoring boundaries, responsibilities, and change drivers using practical software architecture “hard parts” thinking + SRP.
Use this skill when you need a Bun runbook (dev, build, lint, typecheck, tests, migrations, and verification steps).
Use this skill when you need a thorough code hygiene pass (dead code, lint escapes, consistency, formatting drift, and subtle smells) on touched files.
Use this skill when you need a senior-level review of a PR/diff for security, correctness, performance, and maintainability (TypeScript + React 19 + Next.js 16).
| name | agent-proof-testing |
| description | Write clean, behavior-focused unit/integration tests that remain trustworthy when code is written or modified by agents (prevents “test weakening”, enforces invariants, and adds CI guardrails). |
| allowed-tools | runSubagent read_file grep_search file_search runTests run_in_terminal |
This skill helps you write tests that validate real behavior and integration (not just “green CI”) when an agent is implementing or modifying code.
The core problem: agents (and humans) sometimes “fix” failing tests by loosening assertions, re-recording snapshots, over-mocking, or editing fixtures until the test no longer protects the behavior.
Use this skill when you are:
Write a short “executable spec” at the top of the test file:
Then translate that into tests.
Avoid writing tests against private helpers that don’t represent your contract.
Add an Invariants section in the test file that asserts properties like:
workspace_id reads/writesInvariants reduce the chance an agent “loosens” one expectation and gets away with it.
For most dependencies, prefer small fakes (in-memory / deterministic implementations):
Clock (controls time)Mocking is acceptable at true external boundaries (payments, third-party APIs), but pair it with a contract test (see below).
Snapshots are code. Treat them like code.
Rules:
When an agent will implement the production code later, tests must remove ambiguity.
Define:
Create a scenario table:
Table tests make “creative interpretation” difficult.
Write 3–8 properties per unit:
Even if the core logic is unit-tested, add one end-to-end-ish test at the system boundary you care about (DB + auth + locale/time).
Use this whenever tests were changed in a PR.
toBe → toBeTruthy, exact → regex/contains) without a compensating stronger check.These guardrails prevent “make tests pass by weakening tests”.
tests/** and **/*.test.ts.it.only, describe.skip, mass snapshot updates, or test-only changes without justification.When you’re unsure how to test something, use multiple sub-agents with different roles and then reconcile results:
tests/ and similar modules.Only after that, write tests.
workspace_id.For deeper guidance, see:
.github/skills/security-strict/SKILL.md (auth/tenancy/security).github/skills/drizzle-tenant-queries/SKILL.md (workspace scoping).github/skills/bun-workflow/SKILL.md (how to run tests/lint/typecheck)