yq-stable-tests
Skill11 starsChanged 54 days agoMITView on GitHub
Use before calling any test or CI failure load flakiness, before rerunning a failed CI check, and before merging a PR that still carries a failing check. Diagnose, design, and review tests and fixtures that can fail nondeterministically under CI concurrency, slow runners, shared host resources, clocks, process-global state, subprocesses, network listeners, or asynchronous teardown. Also use when a test fails only in a parallel full-suite run or only on a slow runner but passes alone, fails with file-system errors such as EBUSY, ENOENT (including mkdtemp), or EEXIST, when investigating flaky CI, or when adding, changing, or reviewing tests with those risks; use pre-push-checks separately to select outgoing commands.
- Reads credentials
In this repository57 other files it gives its agents.
- AGENTS.mdAGENTS.md
- browser-session-handoffSkill
- deep-researchSkill
- find-skillsSkill
- github-desktop-releaseSkill
- gpt6-pro-consultSkill
- santa-methodSkill
- skill-creatorSkill
- skill-lifecycle-managerSkill
- yq-clear-contextSkill
- yq-pre-push-checksSkill
- yq-simplify-codeSkill
- yq-windows-trash-cleanerSkill
- electron-developmentSkill
- frontend-designSkill
- netlify-cliSkill
- yq-vps-vpn-deploySkill
- data-scraper-agentSkill
- docxSkill
- general-videoSkill
- github-readme-visualsSkill
- html-design-polishSkill
- hyperframes-animationSkill
- hyperframes-audioSkill
- hyperframes-cliSkill
- hyperframes-coreSkill
- hyperframes-creativeSkill
- hyperframes-keyframesSkill
- hyperframes-registrySkill
- hyperframesSkill
- imagegenSkill
- impeccableSkill
- jianying-editorSkill
- make-interfaces-feel-betterSkill
- media-useSkill
- pdfSkill
- ppt-nanoSkill
- pptxSkill
- remotion-video-creationSkill
- ui-ux-pro-maxSkill
- wechat-articleSkill
- xlsxSkill
- yq-editorial-presentation-htmlSkill
- yq-ui-checksSkill
- yq-article-style-imitationSkill
- yq-doc-maintenanceSkill
- yq-remove-reasoning-leaksSkill
- yq-technical-writingSkill
- yq-translate-docsSkill
- contract-reviewSkill
- creating-financial-modelsSkill
- dxy-task-clarifySkill
- healthcare-cdss-patternsSkill
- healthcare-emr-patternsSkill
- healthcare-eval-harnessSkill
- healthcare-phi-complianceSkill
- xhs-pharma-social-listeningSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
25 rules. About 0 are common, 21 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈21
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Use the target repository's testing policy to select unit, coverage, expected-output, snapshot, browser, or real-API evidence.
- Distinctive: line 13
Use the defensive patterns for lifecycle, subprocess, cancellation, and teardown behavior.
- Distinctive: line 14
Read the active Vitest config and GitHub workflow when their worker or job topology affects the test.
- Distinctive: line 15
Use pre-push-checks after the test design is sound to select outgoing validation.
- Distinctive: line 28
Before attributing a failure to load, check that the runner's reported Test Files count equals the intended subset.
- Distinctive: line 30
Do not serialize an entire suite merely because one fixture lacks isolation.
- Distinctive: line 34
Use the resource owner's allocator instead of checking availability and claiming it later.
- Very specific: line 37
Create private per-test temporary roots with mkdtemp.
- Distinctive: line 39
Use exclusive creation where a path must not already exist.
- Distinctive: line 40
Keep stable recorded identifiers separate from ephemeral transport addresses.
- Very specific: line 46
Treat process.env, cwd, fake timers, locale and timezone, module mocks, registries, console hooks, globalThis, and global fetch …
- Distinctive: line 48
Prefer an injected dependency or instance-local adapter.
- Very specific: line 53
use try/finally around the smallest mutation scope.
- Very specific: line 54
keep an afterEach fallback when failure before the local finally is plausible.
- Distinctive: line 66
Prefer an observation that holds on every platform.
- Distinctive: line 80
Wait for an explicit readiness event, handshake, state transition, owned promise, or externally observable condition.
- Distinctive: line 81
Use deferred promises or barriers to place a race at a deterministic point and prove the relevant operations overlap.
- Distinctive: line 82
Use a timeout only to bound a wait, never as the condition that makes the assertion correct.
- Distinctive: line 83
Do not assert scheduler-dependent ordering unless that ordering is the product behavior under test.
- Distinctive: line 84
When time itself is the subject, inject or fake the clock and always restore real timers.
- Distinctive: line 99
Verify external state, events, files, logs, exits, or disposal instead of trusting the component's self-report.
- Distinctive: line 105
Do not present these as root-cause fixes for deterministic local tests:
- Distinctive: line 126
When the same mechanism blocks a second PR, stop rerunning.
- Distinctive: line 130
Run the smallest focused regression for the affected behavior.
- Distinctive: line 137
Before a push, use pre-push-checks.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Reliable CI tests
Build tests that remain correct under the repository's real CI topology, not only when run alone on a quiet workstation. This skill owns isolation and reliability decisions; it does not replace the repository's test-tier policy or select every command for a push.
Read the owning rules
- Use the target repository's testing policy to select unit, coverage, expected-output, snapshot, browser, or real-API evidence.
- Use the defensive patterns for lifecycle, subprocess, cancellation, and teardown behavior.
- Read the active Vitest config and GitHub workflow when their worker or job topology affects the test.
- Use pre-push-checks after the test design is sound to select outgoing validation.
Model the execution topology
Assume these layers can overlap unless the active configuration proves otherwise:
- Tests in one Vitest file.
- Separate Vitest files or worker processes.
- Independent Vitest or repository-gate processes in one job.
- Different Actions jobs whose runners share one host.
Process isolation does not isolate host ports, predictable filesystem paths, external services, databases, sockets, or inherited child processes. For every acquired resource, identify its owner, atomic allocation mechanism, observable readiness signal, registered cleanup, and quiescent completion signal.
Before attributing a failure to load, check that the runner's reported Test Files count equals the intended subset. A mismatch means the invocation was wrong, not that the test is flaky.
Do not serialize an entire suite merely because one fixture lacks isolation. Narrow the exclusive scope or change the resource allocation first. A sequential Vitest block cannot protect a host resource from another file, process, job, or runner.
Allocate resources atomically
Use the resource owner's allocator instead of checking availability and claiming it later.
- Network fixtures bind loopback with
listen(0)and read the assigned address only after the server reports that it is listening. Never scan for a free port and bind it later. - Create private per-test temporary roots with
mkdtemp; do not acquire predictable shared paths. - Give shared databases, sockets, sessions, and output locations unique per-test namespaces.
- Use exclusive creation where a path must not already exist.
- Keep stable recorded identifiers separate from ephemeral transport addresses. Translate inside the fixture instead of forcing the live resource to use the recorded value.
Literal paths and URLs used only as parser inputs or expected values are not acquired resources. Do not rewrite them merely because they look fixed.
Contain process-global state
Treat process.env, cwd, fake timers, locale and timezone, module mocks, registries, console hooks, globalThis, and global fetch interception as exclusive mutable resources.
Prefer an injected dependency or instance-local adapter. When mutation is required:
- capture whether the original value was absent or present;
- restore that exact state;
- register restoration immediately;
- use
try/finallyaround the smallest mutation scope; - keep an
afterEachfallback when failure before the localfinallyis plausible; - intercept the narrowest exact request or call that the fixture owns.
Respect platform-owned semantics
CI runs the same suite on Windows and on POSIX hosts, and a value the operating system owns does not always come back the way a test wrote it.
- Writing a value back is safe only when the assertion tolerates the write-back failing. Restoring a file's
mtimeto prove that a fingerprint invalidates anyway holds everywhere; restoring it to prove that a record stays valid assumes a lossless round trip, which NTFS's 100-nanosecond ticks do not give a fractional millisecond. When the assertion depends on the restoration, take the expected value from a fresh read rather than from the remembered one. - Windows matches environment variable names case-insensitively, so a fixture seeding
http_proxyandHTTP_PROXYas separate keys holds one entry there. - Windows releases file handles asynchronously, so a rename or removal that completes at once on a POSIX host needs a bounded retry sized to the observed contention.
- Windows has no POSIX permission or signal semantics. A case that depends on them takes an explicit platform skip naming the reason, rather than an assertion weakened everywhere.
Prefer an observation that holds on every platform. When a case genuinely cannot, exclude it on that platform explicitly.
Budget timeouts against the lane
A describe or case timeout overrides the runner's --testTimeout instead of yielding to it, so a value below the lane's budget lowers what CI already granted — and the same literal reads as a widening on a host whose default is smaller. A suite bound by process creation takes the lane budget; a tighter value carries the reason it is tighter.
Raise the hook budget with the test budget. Setup and teardown pay the same contention, so lifting only the case budget moves a contended failure into afterEach.
Where a timeout is the subject, keep the outer wait far larger than the timeout under test. A case proving that a 20 ms deadline fires must not race the harness's own wait, or load decides which deadline reports first.
Synchronize on state
A fixed sleep is not evidence that setup completed or cleanup settled.
- Wait for an explicit readiness event, handshake, state transition, owned promise, or externally observable condition.
- Use deferred promises or barriers to place a race at a deterministic point and prove the relevant operations overlap.
- Use a timeout only to bound a wait, never as the condition that makes the assertion correct.
- Do not assert scheduler-dependent ordering unless that ordering is the product behavior under test.
- When time itself is the subject, inject or fake the clock and always restore real timers.
Dispose to quiescence
Register cleanup immediately after acquisition so assertion failures also release the resource. Cleanup stops new callbacks or requests, detaches listeners, restores global hooks, terminates owned work, and awaits child exit, server close, worker termination, or the equivalent completion signal.
Calling abort(), close(), or kill() without awaiting the owned completion signal is incomplete teardown. When late completion is possible, prove that disposal prevents it from mutating another test.
Prove the intended regression
- Observe an ordinary regression fail before the fix when practical.
- For a new static or corpus guard, temporarily introduce the rejected case and observe the intended failure.
- For a race, use barriers to prove overlap; repeated execution alone is not a race test.
- For ports, sockets, shared paths, subprocesses, or other host resources, run independent test processes concurrently when cross-process isolation is part of the fix.
- Where a fixture spawns with its own deadline, assert that no signal or timeout ended the child before asserting its exit status, so a killed child reports as a timeout instead of as a status mismatch.
- Verify external state, events, files, logs, exits, or disposal instead of trusting the component's self-report.
Stress runs supplement a deterministic regression; they do not replace one.
Reject flake-masking fixes
Do not present these as root-cause fixes for deterministic local tests:
- increasing a timeout without identifying the awaited state;
- adding retries;
- making all files serial;
- swallowing an error or unhandled rejection;
- weakening an assertion;
- normalizing away unstable behavior;
- adding a sleep before cleanup or assertion.
Retries remain valid for documented transient external-provider tests under the real-API policy. Keep that exception at the external boundary.
Restoring a budget is not masking. Raising a suite to the lane budget it already had, or sizing a bounded retry to the contention actually measured on the runner, names the awaited work and returns what the lane granted; neither invents headroom around an unexamined wait.
Diagnose existing flakes
For an existing probabilistic CI failure, read the CI flake diagnosis workflow. A diagnosis-only request remains read-only: report the cause and evidence unless the user also asks for a fix.
Before a rerun
- Before rerunning a failed CI check, intersect the failing test's transitive import closure with the PR diff. Name the base SHA you diffed against. Put both the base SHA and the intersection in the rerun reason. A non-empty intersection means the failure is not a flake; do not rerun it as one.
- When the same mechanism blocks a second PR, stop rerunning. Open a separate fix for the test or script that owns the mechanism right away.
Validate and report
Run the smallest focused regression for the affected behavior. Add topology-specific evidence only when the change owns that risk:
- global mutation needs restoration evidence;
- lifecycle or subprocess work needs quiescent teardown evidence;
- ports, sockets, or shared paths need concurrent independent-process evidence;
- a new guard needs a negative control.
Before a push, use pre-push-checks. Report exact commands and observed results; do not describe retries, skipped tests, or pending CI as passing.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

