analyze-selective-testing
Skill35 starsChanged 8 months agoMITView on GitHub
Analyzes Xcode selective testing effectiveness for a test run, showing which test targets were skipped or ran, and diagnosing regressions in test selection. Can compare two test runs to identify what changed.
2 other projects use a version of this.
Adopted by
Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data
Most recently taken up by
- tuist/agent-pluginword for word, first seen Nov 8, 2026
- tuist/tuistword for word, first seen Oct 8, 2026
Other versions2 projects use a version of this.
Word for word · 2
- tuist/tuist★ 5.9k100% same
- tuist/agent-plugin★ 0100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository11 other files it gives its agents.
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. About 0 are common, 7 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 10
Run tuist test list --json to find test runs.
- Very specific: line 11
Run tuist test xcode target list <test-run-id> --json to see per-target selective testing status.
- Distinctive: line 12
If effectiveness dropped, compare targets between a known-good run and the regressed run.
- Very specific: line 31
Use this to confirm the run's branch, status, scheme, and environment (xcode_version, macos_version).
- Distinctive: line 35
If no test run is specified, use the most recent CI test run on the current branch.
- Distinctive: line 75
If effectiveness dropped, investigate:
- Very specific: line 79
If nearly all targets show as miss, the entire selective testing cache was invalidated.
- Very specific: line 92
If only some targets show as miss, a dependency change likely cascaded:
- Very specific: line 94
Run tuist test xcode target list <good-run-id> --json and tuist test xcode target list <bad-run-id> --json.
- Distinctive: line 97
Look for a common dependency among the invalidated targets.
- Distinctive: line 110
Environment change: Ensure CI uses consistent Xcode/macOS versions.
- Distinctive: line 111
Cascade from dependency change: Consider if the change to the root target was necessary.
- Distinctive: line 112
Cold cache on new branch: Run tests once to warm the cache.
≈ “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
Analyze Selective Testing
Quick Start
- Run
tuist test list --jsonto find test runs. - Run
tuist test xcode target list <test-run-id> --jsonto see per-target selective testing status. - If effectiveness dropped, compare targets between a known-good run and the regressed run.
Step 1: Resolve Test Runs
Find the test run to analyze
List recent test runs, optionally filtering by branch:
tuist test list --json --page-size 10
tuist test list --git-branch feature-x --json --page-size 5Get basic info for a specific test run:
tuist test show <test-run-id> --jsonUse this to confirm the run's branch, status, scheme, and environment (xcode_version, macos_version).
Defaults
- If no test run is specified, use the most recent CI test run on the current branch.
- For comparison, use the most recent CI test run on the project's default branch.
Step 2: Drill Into Selective Testing Targets
List per-target selective testing data for a test run:
tuist test xcode target list <test-run-id> --jsonEach target includes:
- name: The test target name
- hit_status:
miss(ran),local(skipped via local cache), orremote(skipped via remote cache) - hash: The selective testing hash for this target
Filter by status to focus your analysis:
tuist test xcode target list <test-run-id> --hit-status miss --json
tuist test xcode target list <test-run-id> --hit-status local --json
tuist test xcode target list <test-run-id> --hit-status remote --jsonAssess effectiveness
Count the targets by status:
effectiveness = (local_hits + remote_hits) / total_targets * 100| Effectiveness | Verdict |
| 60-100% | Healthy — most unchanged tests are being skipped |
| 30-60% | Moderate — some cache invalidation occurring, worth investigating |
| 0-30% | Low — likely a core dependency changed or the cache was invalidated |
| 0% | Cold cache — first run, environment change, or full invalidation |
Step 3: Diagnose Regressions
If effectiveness dropped, investigate:
Check for global invalidation
If nearly all targets show as miss, the entire selective testing cache was invalidated. Common causes:
| Cause | How to verify |
| Xcode version change | Compare xcode_version between good and bad runs via tuist test show |
| CI environment change | Compare macos_version, model_identifier between runs |
| Project graph or dependency change | Check git history for changes to project manifests, dependency versions, or target configurations |
| Core dependency change | A widely-depended-on target changed, invalidating all its dependents |
Note: Tuist CLI version upgrades rarely cause hash invalidation — the hash version is not updated on every release.
Check for cascade invalidation
If only some targets show as miss, a dependency change likely cascaded:
- Run
tuist test xcode target list <good-run-id> --jsonandtuist test xcode target list <bad-run-id> --json. - Match targets by name — identify those that changed from
local/remotetomiss. - Compare hashes for changed targets — if a target's hash differs, its sources or dependencies changed.
- Look for a common dependency among the invalidated targets.
Compare two test runs
For each target:
- Match by
name - Compare
hit_status(hit -> miss = invalidated, miss -> hit = improved) - Compare
hash(different hash = target or its dependencies changed)
Step 4: Recommendations
Based on the diagnosis:
- Environment change: Ensure CI uses consistent Xcode/macOS versions. This is the most common cause of full cache invalidation.
- Cascade from dependency change: Consider if the change to the root target was necessary. If the root target is a widely-shared module, consider splitting it.
- Cold cache on new branch: Run tests once to warm the cache. Subsequent runs will benefit from selective testing.
Summary Format
Produce a summary with:
- Overall: effectiveness percentage, verdict (healthy/moderate/low/cold)
- Target breakdown: targets grouped by hit status
- Comparison (if applicable): targets that changed status between runs, with hash diffs
- Root cause: what caused the regression
- Recommendations: actionable next steps
Example:
Selective Testing Analysis: test run abc123 on feature-x
Effectiveness: 15% (3/20 targets skipped) -- LOW
Local hits: 2 targets (CoreTests, UtilTests)
Remote hits: 1 target (NetworkTests)
Misses: 17 targets
Comparison with baseline (run def456, 75% effectiveness):
14 targets changed from hit to miss
All changed targets have different hashes
Root cause: Xcode version changed from 15.2 to 16.0 between runs.
This changed all target hashes, invalidating the entire cache.
Recommendations:
- Align CI Xcode version with the version used in the baseline run.
- If the upgrade is intentional, run tests once to re-warm the cache.Done Checklist
- Identified the test run(s) to analyze
- Drilled into per-target selective testing status via
tuist test xcode target list - Diagnosed root cause if effectiveness is low
- Compared targets with baseline if regression detected
- Provided actionable recommendations
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.

