Tuist flaky test stabilizer

Skill Xopoko/build-swift-apps/skills/tuist-flaky-test-stabilizer

Investigate and fix flaky tests using Tuist test insights and local repeated test runs. Use when a user provides a flaky test URL, test case identifier, or asks to find and stabilize flaky tests.From its SKILL.md

Install

npx -y skills add Xopoko/build-swift-apps --skill tuist-flaky-test-stabilizer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

2.6 KB, 559 tokens by cl100k_base, as published. Nobody here has run it

Tuist Flaky Test Stabilizer

Use this skill to move from flaky-test evidence to a small code or test fix.

Inputs

Accept any of:

Tuist test case URL or UUID
Module/Suite/testName identifier
request to discover flaky tests in the current project

Discover Evidence

tuist test case list --flaky --json --page-size 50
tuist test case show <id-or-identifier> --json
tuist test case run list <module/suite/test> --flaky --json
tuist test case run show <run-id> --json

Collect:

reliability/flakiness rate and sample size
failure messages, source path, and line
branch/CI clustering
retry sequence if present
crash report details if the test runner crashed

Analyze The Test

Open the reported source line, then inspect setup, teardown, shared fixtures, global state, async waits, mocked services, file system use, and clock/timezone dependencies.

Common root causes:

async assertion before work completes
fixed sleeps instead of condition-based waits
shared singleton or static state leaking between tests
non-unique temp files, ports, identifiers, users, or database rows
real network/service dependency
order dependence exposed by parallel testing
force unwrap/precondition crash hidden by retry

Fix Rules

Make the test deterministic at the smallest relevant boundary.
Prefer dependency injection, explicit clocks, temp directories, mocks, and condition-based waits.
Reset shared state in setup/teardown or remove the shared state dependency.
Do not quarantine, skip, or weaken assertions unless the user explicitly asks.
Avoid broad refactors while stabilizing one flaky test.

Verify

Run the narrow test repeatedly:

xcodebuild test \
  -workspace <workspace> \
  -scheme <scheme> \
  -only-testing <module>/<suite>/<test> \
  -test-iterations 50 \
  -run-tests-until-failure

If the flake depends on parallelism, broaden the scope:

xcodebuild test \
  -workspace <workspace> \
  -scheme <scheme> \
  -only-testing <module> \
  -parallel-testing-enabled YES \
  -test-iterations 20 \
  -run-tests-until-failure

Use Thread Sanitizer when a data race is plausible and the project can run with TSan enabled.

Output

Report the root cause, fix, before/after evidence, exact verification command, and any residual risk if the original flake could not be reproduced locally.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most test skills give in 559 tokens

Counted across 1,201 of the 2,096 authors here whose files we hold, read 2026-09-06

Write a failing test before writing codein 43 of 1201, across 36 files
Run the full test suitein 36 of 1201, across 35 files
Test only one variable per experimentin 34 of 1201, across 17 files
Read product marketing context before asking questionsin 34 of 1201, across 14 files
Mock external dependenciesin 34 of 1201, across 30 files
Define primary, secondary, and guardrail metricsin 33 of 1201, across 16 files
Pre-determine sample size before startingin 31 of 1201, across 14 files
Test behavior rather than implementationin 31 of 1201, across 29 files
Formulate a hypothesis before designing a testin 30 of 1201, across 13 files
Document every test hypothesis, variant, and resultin 29 of 1201, across 11 files
Use descriptive test function namesin 25 of 1201, across 21 files
Commit to the methodology without stopping earlyin 24 of 1201, across 8 files

Said here and by no other author read

Confirm macOS execution context before running Apple binaries
Collect flakiness rate and failure details
Inspect setup teardown and shared state
Prefer dependency injection and condition-based waits
Run the narrow test repeatedly to verify
Use Thread Sanitizer for suspected data races

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.