about
Tuist builds infrastructure that shortens the build, test, and review loop for developers,…
Make test feedback faster and more trustworthy: see what fails and what is slow, contain flaky tests, split large suites across machines, and skip tests unaffected by a change where supported.
$ npx -y skills add tuist/tuist --agent claude-codeHow it fires
How this agent gets triggered: by you, by Claude, or both.
Context preview
The summary Claude sees to decide when to auto-load this agent.
Make test feedback faster and more trustworthy: see what fails and what is slow, contain flaky tests, split large suites across machines, and skip tests unaffected by a change where supported.
Make test feedback faster and more trustworthy: see what fails and what is slow, contain flaky tests, split large suites across machines, and skip tests unaffected by a change where supported.
Growing suites take longer on one CI machine. Parallel jobs end up uneven. Intermittent failures trigger retries and hide real regressions, and CI logs from individual runs do not show trends.
Sharding spreads work; selective testing removes work; insights explain what happened. They combine: a generated project can skip unchanged targets and shard the rest.
| Feature | Xcode project | Tuist-generated Xcode projects | Gradle | Bazel | Elixir | | --- | --- | --- | --- | --- | --- | | [Test Insights](/en/docs-markdown/guides/features/test-insights) | Yes | Yes | Yes | Yes (`tuist bazel test`) | Yes (`tuist_ex` Hex package) | | [Flaky-test detection](/en/docs-markdown/guides/features/test-insights/flaky-tests) | Yes | Yes | Yes | Yes | Yes, with test retries | | Quarantine (mute or skip) | Yes, via `tuist xcodebuild test` | Yes, via `tuist test` | Yes | Yes | Not applied yet | | [Test sharding](/en/docs-markdown/guides/features/test-sharding) | Yes | Yes | Yes | No | Yes | | [Selective testing](/en/docs-markdown/guides/features/selective-testing) | No | Yes, via `tuist test` | No | No | No |
Selective testing requires Tuist-generated Xcode projects because it reuses the project-graph hashing behind the module cache. Support for other build systems is planned but not available.
1. Connect the project to Tuist and enable test reporting for your toolchain, for example `tuist inspect test` as an Xcode scheme post-action, the Gradle plugin, `tuist bazel test`, or the Hex package. 2. Let real CI history accumulate, then review slow and flaky tests in the dashboard. 3. Configure flaky-test automations or quarantine where supported. 4. Follow the sharding guide for your toolchain; it needs insights history to balance shards (Xcode uses the last 30 days of timings). 5. For generated projects, run tests with `tuist test` to enable selective testing; it combines with the module cache.
Billing depends on the account's model: newer plans meter passing test cases reported to Test Insights and list selective testing as unlimited; older plans meter test usage differently. Check the live [pricing table](/pricing) and the [pricing guide](/marketing-markdown/pricing).
Tuist supercharges your build system, whether you build with Xcode, Gradle, or Bazel.
Tuist builds infrastructure that shortens the build, test, and review loop for developers,…
An entry point to Tuist's articles on build systems, caching, testing, CI, and the reasoning…
Official Tuist logos and wordmarks for referring to Tuist in documentation, integrations,…
Optimize the project first, then its execution environment: remove unnecessary work, then…
Where to ask questions, discuss build tooling, and contribute to Tuist.