Skip to content

tailtest for Cline

tailtest-cline is a Cline plugin. Cline runs across 8+ editors (VS Code, Cursor, JetBrains IDEs, Antigravity, Zed, Neovim, VSCodium, Windsurf, plus the Cline CLI), so one tailtest install reaches all of them.

Unlike the Claude Code, Cursor, and Codex CLI variants, Cline does not have a hook system. Instead, tailtest-cline uses three Cline-native primitives:

  • .clinerules/ carries the rule layer (R1-R14 + R15 adversarial mode)
  • An MCP server (this is what gets installed) provides structured tools
  • Memory Bank holds the per-project profile across sessions

Install

Three install paths.

Open Cline's Extensions panel inside your IDE. Search tailtest. Click install. Cline clones the source repo to ~/Documents/Cline/MCP/tailtest-cline/, runs pip install -e ., registers the server in cline_mcp_settings.json. One click, server is ready.

2. Direct GitHub install

In Cline's MCP server install dialog, paste:

https://github.com/avansaber/tailtest-cline

Cline runs the same clone + install + register flow as the marketplace path.

3. Manual cline_mcp_settings.json edit

Edit your cline_mcp_settings.json directly:

{
  "mcpServers": {
    "tailtest": {
      "command": "python",
      "args": ["-m", "src.server"],
      "cwd": "/path/to/tailtest-cline/mcp_server",
      "alwaysAllow": [
        "tailtest_ping",
        "tailtest_scenario_plan",
        "tailtest_classify_failures",
        "tailtest_pick_template"
      ]
    }
  }
}

Use this for local development or when running an unpublished fork.

First run

After install, open your project in Cline and type in chat:

set up tailtest in this project

Cline calls the tailtest_setup MCP tool. The tool:

  1. Detects language, framework, runner, test directory
  2. Writes .clinerules/01-tailtest-baseline.md (the rule layer)
  3. Writes 11 slash workflow files into .clinerules/workflows/
  4. Writes memory-bank/tailtestContext.md (a 7th file alongside Memory Bank's 6 core files; existing files are preserved)
  5. Initialises .tailtest/config.json (depth + mode) and .tailtest/session.json (runtime state)

Important: Cline does not auto-reload .clinerules mid-conversation. Start a new conversation (or reload the window) for tailtest to take effect.

The setup tool is idempotent. Existing .clinerules/ files, Memory Bank files, or .tailtest/ config are not overwritten. Re-running setup is safe.

Two operating modes

Manual mode (default)

You invoke the test cycle explicitly. After editing a source file, run one of:

  • /tailtest-test <file> -- full cycle (read source, scenario plan, write test, run, classify failures)
  • /tailtest hunt <file> -- one-shot adversarial pass on a specific file
  • Or natural language ("test the file I just edited")

Each step prompts for approval. Manual mode is the safer default for first-time users.

Auto mode (opt-in)

Enable Cline auto-approve for these categories:

  • Edit files (workspace)
  • Execute safe commands
  • Use MCP servers

Then run /tailtest-mode auto and reload the window. After every code edit, tailtest fires the test cycle automatically per a .clinerules/ instruction. No prompts.

To switch back: /tailtest-mode manual.

Plan / Act mode (Cline-native UX bonus)

Cline has a Plan / Act toggle that maps perfectly to tailtest's R4 SCENARIO PLAN convention.

  1. Toggle Plan mode in Cline
  2. Type /tailtest-test <file>
  3. Cline produces a SCENARIO PLAN (read-only; no file edits yet)
  4. Review the plan; amend if desired
  5. Toggle Act mode
  6. Cline writes the test file, runs it, and applies R12 classification

This is the one axis where Cline integration is UX-better than the hook-driven variants: the human review gate between scenario design and test code is enforced by the UX, not by rule compliance. Recommended for high-stakes files.

The 5 MCP tools

Tool Purpose
tailtest_setup Bootstrap. Detect stack; write rule pack, workflows, Memory Bank seed, .tailtest state.
tailtest_scenario_plan Return structured scaffolding for the agent to compose its SCENARIO PLAN: language, framework, depth, R15 adversarial count, language and framework baselines, test file path.
tailtest_classify_failures Parse runner output (pytest, jest, vitest, mocha) into structured R12 array.
tailtest_pick_template Return full framework R2 template (Flask test_client, NestJS Test.createTestingModule, Spring @WebMvcTest, Kotlin runTest, etc.).
tailtest_ping Health check.

The agent calls these as needed during a test cycle. With auto-approve enabled, tool calls do not prompt.

The 11 slash workflows

Slash command Purpose
/tailtest-test <file> Run the full cycle on a specific file
/tailtest hunt <file> One-shot adversarial pass; writes to a separate hunt test file
/tailtest-status Compact state snapshot (depth, mode, last run)
/tailtest-debt Review accepted-debt baseline
/tailtest-report Open the latest run report
/tailtest-depth <value> Change depth tier (simple / standard / thorough / adversarial)
/tailtest-gen <file> Starter test scaffold + compile check, no execution
/tailtest-scan Project scanner; reports stack + AI-surface markers + likely_vibe_coded flag
/tailtest-security Security posture + baselined findings
/tailtest-mode <auto/manual> Switch operating mode
/tailtest-summary Session summary block

Memory Bank integration

If your project already uses Cline's Memory Bank (the 6 core files: projectbrief.md, productContext.md, activeContext.md, systemPatterns.md, techContext.md, progress.md), tailtest adds a 7th file tailtestContext.md alongside them. Existing core files are not modified.

The 7th file holds:

  • Detected language, framework, runner, test directory
  • Current depth + mode
  • Baseline file path + entry count
  • Last R12 stats (real bugs, environment failures, test bugs)
  • A space for project-specific notes (preserved across re-runs of tailtest_setup)

Cline reads Memory Bank at every session start, so each session begins with the agent already aware of your project's tailtest configuration.

Configuration

.tailtest/config.json:

{
  "depth": "standard",
  "mode": "manual"
}

Depth options:

  • simple -- 2-3 happy-path scenarios; R15 disabled
  • standard -- 5-8 scenarios including 2+ adversarial probes (default)
  • thorough -- 10-15 scenarios including 4+ adversarial probes
  • adversarial -- 8-12 scenarios biased toward breakage; bug-hunting as default

See adversarial mode for the 8 scenario categories and the discovery story behind R15.

How tailtest-cline differs from the other variants

Same R1-R15 rule layer, same adversarial test mode, same R12 failure classification across all four variants. The differences:

Claude Code Cursor Codex Cline
Trigger PostToolUse hook afterFileEdit hook Stop hook .clinerules/ instruction + auto-approve OR manual slash
Tool I/O Rule text Rule text Rule text Structured (MCP)
Plan-before-write Rule-based Rule-based Rule-based UX-native (Plan mode)
IDE coverage Claude Code Cursor Codex CLI 8+ editors

See /comparison for the full feature matrix.

Troubleshooting

  • "tailtest does not respond after I edit a file" -- you may be in manual mode (the default). Run /tailtest-test <file> or switch to auto mode.
  • "/tailtest-test does not appear in the slash menu" -- the workflow files were written but Cline has not reloaded. Start a new conversation.
  • MCP tools listed in Cline but the agent does not call them -- in manual mode, the agent calls tools when the rule layer instructs (e.g., during /tailtest-test). In auto mode, the agent calls them after every edit. Confirm .clinerules/01-tailtest-baseline.md exists and Cline has reloaded.
  • "the setup tool wrote files I did not want" -- tailtest_setup is idempotent and never overwrites. To start clean, delete .clinerules/, memory-bank/tailtestContext.md, and .tailtest/, then re-run.

Where to ask for help

License

MIT.