A command for finding and fixing flaky tests, which are tests that sometimes pass and sometimes fail without a code change. It examines the project context, investigates likely causes, and updates the test code.

Use it to analyze a failing test, apply a targeted fix, and run it repeatedly to check whether it has become stable.

It helps remove unreliable test failures caused by timing, shared state, external services, randomness, execution order, or limited resources.

flaky-fix — Command by classmethod

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods

npx agentmods add commands/classmethod/tsumiki/flaky-fix

Clone the repo

git clone --depth 1 https://github.com/classmethod/tsumiki

Per session 50 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.

When invoked 1,397 The whole file, excluding the scripts and references it only reads on demand.

Security scan A 0 findings. Scan, not verified.

Origin original No closer match found in the catalogue.

Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

Model	Per session	Once invoked
Fable 5	$0.00050	$0.01397
Opus 5	$0.00025	$0.00698
Sonnet 5	$0.00010	$0.00279
Haiku 4.5	$0.00005	$0.00140

Measured 2d ago against content hash 237810405a9d, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

flaky-fix scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

commands/flaky-fix.md · 127 lines

How it starts

The opening of the file, as written. The whole thing — 127 lines — stays where its author put it; the contents beside it link to each section on GitHub.

flaky testを安定化して。

context

test_command: {{test_command}} (テスト実行コマンド。未指定の場合は npm test)
test_file: {{test_file}} (対象テストファイル)
error_output: {{error_output}} (失敗時のエラー出力)
max_retry: 2 (修正の最大リトライ回数)
stability_runs: 3 (安定性確認の実行回数)

step

step0: プロジェクトコンテキストの確認

以下のファイルが存在する場合は読み取り、テスト実行方法や開発ルールを把握する:

CLAUDE.md — テスト実行方法、プロジェクト固有の指示
README.md — テストフレームワーク、セットアップ手順
AGENTS.md — エージェント向けの開発ルール

test_command が未指定の場合は、これらの情報から適切なテストコマンドを決定する。

step1: flaky原因の分析

テストファイルと関連コードの読み取り
- 対象テストファイルを Read tool で読み取り
- テスト対象の実装ファイルを特定
原因分析（Task tool, subagent_type: Explore, thoroughness: medium）
- 以下のflaky原因パターンに沿って分析:
  - タイミング依存: 非同期処理のawait不足、setTimeout依存、競合状態
  - 共有状態: グローバル変数、DB状態、ファイルシステム状態のテスト間汚染
  - 外部サービス依存: API呼び出し、ネットワーク通信、外部DB
  - ランダム性: Math.random, Date.now, UUID生成等の非決定的処理
  - 順序依存: テスト実行順序に依存する暗黙の前提
  - リソース制限: メモリ不足、ファイルディスクリプタ枯渇、ポート競合
- 最も可能性の高い原因を特定し、修正方針を決定

step2: テストコードの修正

原因に応じた修正を実施（general-purpose subagent）:

タイミング依存の場合
- 不足しているawaitの追加
- setTimeout → 適切なイベント待機に変更
- waitFor / waitForExpect パターンの導入
- テスト用のタイムアウト値を十分に確保
共有状態の場合
- beforeEach/afterEachでの状態初期化・クリーンアップ追加
- テスト専用のデータ生成（ユニークなID/名前）
- テスト間の依存関係の排除
外部サービス依存の場合
- テスト用モック/スタブの導入
- MSW (Mock Service Worker) 等のHTTPモックの設定
- テスト用のインメモリDB切り替え
ランダム性の場合
- Math.random → seed付き乱数生成に変更
- Date.now → jest.useFakeTimers() / vi.useFakeTimers()
- テスト用の固定値モック
順序依存の場合
- 各テストの独立性を確保
- 暗黙の前提条件を明示的なsetupに変換
リソース制限の場合
- afterEachでのリソース解放追加
- 接続プールの適切な管理

step3: 安定性確認

修正後のテストを複数回実行

# stability_runs 回連続実行
{{test_command}} -- {{test_file}}
{{test_command}} -- {{test_file}}
{{test_command}} -- {{test_file}}

結果判定
- 全回成功: 安定化成功。step4へ
- 1回でも失敗:
  - retry_count < max_retry → 別のアプローチで step1 に戻る
  - retry_count >= max_retry → 安定化不能としてレポート

step4: 結果レポート

# flaky-fix 結果レポート

## 結果: [安定化成功 / 安定化失敗]

## 対象テスト
- ファイル: {{test_file}}

## flaky原因
- 原因分類: [タイミング依存 / 共有状態 / 外部依存 / ランダム性 / 順序依存 / リソース制限]
- 詳細: [具体的な原因]

## 修正内容
（修正した場合のみ）
- 修正ファイル: [ファイルパス]
- 修正内容: [具体的な変更内容]
- 安定性確認: X回連続成功

## 未解決
（安定化できなかった場合のみ）
- 試行した修正: [各試行の内容]
- 推奨対応: [手動での安定化が必要な理由と方針]

Read the full file on GitHub · 127 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

2d ago First seen · 127 lines · 50 tokens per session scan A 237810405a9d

Subscribe to this mod's changes

flaky-fix is a command published in the GitHub repository classmethod/tsumiki (974 stars, last pushed 25d ago), licensed MIT. It adds 50 tokens to every session and 1,397 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Research Testing

flaky-fix

Getting it into your agent

What it costs to keep this loaded

Grade A, and why

Nothing flagged

How it starts

context

step

step0: プロジェクトコンテキストの確認

step1: flaky原因の分析

step2: テストコードの修正

step3: 安定性確認

step4: 結果レポート

What this file has done since we first saw it

Other commands, from other repositories

checklist

clarify

specify

analyze

converge

implement