Detect, prevent, and fix flaky Jest unit tests in MetaMask Mobile before they reach CI. Use this skill when: reviewing a PR diff or changed test files for flakiness risk, fixing an intermittently failing Jest test, reproducing a flaky test locally, or auditing GitHub Actions history to rank historically flaky unit tests by failure rate.
Installs into .claude/skills of the current project.
Are you the author of Metamask Official Flaky Test Detection?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/jiayaoqijia-metamask-official-flaky-test-detection)
---
name: flaky-test-detection
description: >
Detect, prevent, and fix flaky Jest unit tests in MetaMask Mobile before they
reach CI. Use this skill when: reviewing a PR diff or changed test files for
flakiness risk, fixing an intermittently failing Jest test, reproducing a flaky
test locally, or auditing GitHub Actions history to rank historically flaky unit
tests by failure rate.
---
# Flaky Test Detection
```
Task → Which mode?
├─ Reviewing changed test files / PR diff for risk patterns → Review mode
├─ Fixing a known flaky Jest unit test → Review mode + local reproduce loop
└─ Auditing CI history to rank flaky tests by failure rate → open references/gh-analysis.md
```
## Constraints
If the file is `*.view.test.ts(x)`, follow `mms-mobile-testing` component-view
rules instead of this skill's fake-timer patterns (J2 / J8). CV forbids fake
timers. Use the CV diagnosing table for sibling-skeleton waits, empty-state
load, list hydration, stale press, nested `findBy*`, and Engine `mockReset`.
All proposed **unit** fixes must comply with `mms-mobile-testing` (unit path) and `mms-coding-guidelines`. Key rules:
- Use `jest.mocked(fn)` — never `fn as jest.Mock`
- Use `toBeOnTheScreen()` — never `toBeTruthy()` / `toBeDefined()` for element presence
- Use `yarn` commands — never npm or npx
- No `toMatchSnapshot()` — use explicit assertions or `toMatchInlineSnapshot()`
## Review mode
1. Scan changed `.test.ts(x)` files against the pattern table (J1–J10).
2. Classify each hit (async / timing / isolation / mock / state).
3. Propose the fix for each hit using the ✅ pattern from the matching section — apply only on explicit confirmation.
4. Run the local reproduction loop to confirm the fix holds.
## Audit mode
Query GitHub Actions run history to produce a ranked list of historically flaky unit test files with failure rates and suggested fix categories.
Open [references/gh-analysis.md](references/gh-analysis.md) for the full procedure.