A procedure for diagnosing and fixing tests that exceed their time limit by finding causes such as slow processing, hanging network calls, deadlocks, heavy setup, or leaked resources.

Use it to investigate timed-out test files, choose a test command, reduce unnecessary test work, add mocks or time limits, and rerun the tests.

It helps separate genuinely slow tests from tests that are stuck or waiting for something that never finishes.

timeout-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/timeout-fix

Clone the repo

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

Per session 52 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,747 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.00052	$0.01747
Opus 5	$0.00026	$0.00873
Sonnet 5	$0.00010	$0.00349
Haiku 4.5	$0.00005	$0.00175

Measured yesterday against content hash 582becab9143, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

timeout-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 yesterday.

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/timeout-fix.md · 145 lines

How it starts

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

テストのタイムアウト問題を解消して。

context

test_command: {{test_command}} (テスト実行コマンド。未指定の場合は npm test)
test_file: {{test_file}} (タイムアウトしたテストファイル。未指定の場合は全テスト)
timeout_seconds: {{timeout_seconds}} (タイムアウトした秒数)
max_retry: 2 (修正の最大リトライ回数)
execution_timeout: 120 (テスト再実行時のタイムアウト秒数)

step

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

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

CLAUDE.md — テスト実行方法、タイムアウト設定、プロジェクト固有の指示
README.md — テスト実行環境、パフォーマンス要件
AGENTS.md — エージェント向けの開発ルール

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

step1: タイムアウト原因の分析

テストファイルと関連コードの読み取り
- 対象テストファイルを Read tool で読み取り
- テスト対象の実装ファイルを特定
原因分析（Task tool, subagent_type: Explore, thoroughness: medium）
- 以下のタイムアウト原因パターンに沿って分析:
  - 非効率な処理: N+1クエリ、不要なループ、大量データの逐次処理
  - 外部API呼び出しのハング: タイムアウト未設定のHTTPリクエスト、未応答のサービス
  - デッドロック/無限ループ: Promise未解決、イベントループブロック、再帰の終了条件欠如
  - 大量テストデータ: 不必要に大きなテストデータセット
  - テストのセットアップ過重: beforeAll/beforeEachでの重い初期化処理
  - リソースリーク: 未クローズの接続、ストリーム、ファイルハンドル
- 最も可能性の高い原因を特定し、修正方針を決定

step2: 修正の試行

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

非効率な処理の場合
- テスト対象コードの最適化（テスト範囲内で可能な場合）
- テスト側でのデータ量削減
- バッチ処理への変更
外部API呼び出しのハングの場合
- テストでのモック導入（実際のAPI呼び出しを回避）
- テスト対象コードにタイムアウト設定が不足している場合はレポートに記載
- テスト用のAbortController / タイムアウト設定追加
デッドロック/無限ループの場合
- テストコード内のPromise解決パターンを修正
- 無限ループの終了条件修正
- テスト用のタイムアウトガード追加
大量テストデータの場合
- テストデータセットの削減（本質を損なわない範囲で）
- テストファクトリの最適化
テストのセットアップ過重の場合
- 不要な初期化の削除
- 共有セットアップの最適化（beforeAllへの移動等）
リソースリークの場合
- afterAll/afterEachでの適切なクリーンアップ追加
- 接続のクローズ処理追加

step3: 再実行による確認

修正後のテストを実行（明示的タイムアウト設定）

timeout {{execution_timeout}} {{test_command}} -- {{test_file}} 2>&1

結果判定
- タイムアウトせず成功: 修正完了。step5（レポート）へ
- タイムアウトせず失敗: テストエラーは別問題。タイムアウト改善は成功としてレポート
- 再度タイムアウト: retry_count < max_retry → 別のアプローチで step1 に戻る
- retry_count >= max_retry: step4（テスト分離）へ

step4: テストの分離

修正でタイムアウトを解消できなかった場合、テストを通常実行から分離:

Read the full file on GitHub · 145 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.

yesterday First seen · 145 lines · 52 tokens per session scan A 582becab9143

Subscribe to this mod's changes

timeout-fix is a command published in the GitHub repository classmethod/tsumiki (974 stars, last pushed 25d ago), licensed MIT. It adds 52 tokens to every session and 1,747 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.

Debugging Research Testing

timeout-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: タイムアウト原因の分析

step2: 修正の試行

step3: 再実行による確認

step4: テストの分離

What this file has done since we first saw it

Other commands, from other repositories

checklist

clarify

specify

analyze

converge

implement