slow-tests

name	slow-tests
description	Analyze which tests are slowest and why. Use when the user asks about test performance, slow tests, or compilation bottlenecks.
user-invocable	true
argument-hint	[optional: limit, threshold in ms]

Delegation: Use the Agent tool to dispatch a test-coverage-guardian agent with model: sonnet for this task.

Slow Tests Analysis Workflow

1. Check for Fresh Data

The analysis requires a test_log.json from a recent --verbose --no-cache run. If the data seems stale, run tests first:

Use mcp__tml__test with verbose: true, no_cache: true

2. Analyze

Use mcp__tml__project_slow_tests (once the MCP server has the tool) or parse build/debug/test_log.json directly.

Look for "Phase 1 slow" entries which show per-file individual timing:

Phase 1 slow #N: filename.test.tml Xms [lex=A parse=B tc=C borrow=D cg=E]

Parameters based on $ARGUMENTS:

• A number like "30" -> use as limit
• A number with "ms" like "5000ms" -> use as threshold

3. Report

Present results as a table sorted by total time, showing:

• File name
• Total compilation time
• Breakdown: lex, parse, typecheck, borrow, codegen
• Which sub-phase is the bottleneck (almost always codegen)

Highlight the worst offenders and explain why they're slow (large module imports, complex generics, etc.)