backtick

name	backtick
description	Local task compiler for repository coding work. Before exploring the repo, compiles the request into a token-budgeted evidence packet — symbols, exact source spans, structural facts, tests, diagnostics — via the backtick MCP tools, then verifies the patch locally. Use on ANY coding task in a repository where the backtick tools (prepare_task, expand_context, inspect_symbol, verify_patch) are available: bug fixes, failing tests, type errors, small features, refactors. Also use when the user says "backtick", "task packet", or asks to cut context or token usage. Do NOT use for conceptual questions that need no repository code, or when the backtick MCP tools are not attached.
argument-hint	[lite|full|ultra]
license	MIT

backtick

You drive an evidence engine, not a search party. backtick compiles the request plus repository evidence into a minimal task packet so you read less and verify more. Cloud tokens per verified task is the number this workflow exists to cut — and a short packet that produces an unverified patch has cut nothing.

Persistence

ACTIVE EVERY RESPONSE while coding in a repository with the backtick tools attached. Still active if unsure. Off only: "stop backtick" / "normal mode". Default: full. Switch: /backtick lite|full|ultra.

The loop

Before broad repository exploration, in order:

1. Call prepare_task with the user's request verbatim and your level's token budget.
2. Work from the returned evidence packet. Its FACTs — symbols, exact source spans, structural facts, tests, diagnostics — are mechanically extracted; trust them. Its INTERPRETED GOAL is a hypothesis; confirm it against the code before building on it.
3. Missing evidence? Call expand_context with a pointed question and a small additional budget. Do not fall back to repo-wide scanning.
4. Need one symbol's neighborhood? inspect_symbol returns its definition, callers, callees, types, and related tests.
5. After editing, call verify_patch. Revise from the compact failure packet it returns — failing test names and implicated symbols, not raw logs.
6. Do not claim completion until verification succeeds.

Rules

• The packet's OMITTED CONTEXT section names what was cut. If the task needs it, ask for it by name via expand_context; never re-read the whole repo to check.
• Prefer the packet's exact source spans over re-opening files it already quoted.
• Keep edits inside the evidence neighborhood. Wandering past it usually means the packet is missing something — expand, then edit.
• If the same test fails twice, inspect_symbol the implicated symbol before a third attempt.
• If the evidence contradicts the interpreted goal, say so and expand; never force a patch to match a wrong goal.

Levels

Levels set the prepare_task token budget.

Level	What changes
lite	1000-token packets. Small fixes in code you already know.
full	2000-token packets. Default for most tasks.
ultra	4000-token packets. Cross-file work or unfamiliar repos.

Example: "Fix users being logged out after token expiry"

• lite: "prepare_task, budget 1000 — symbols and the one hot span."
• full: "prepare_task, budget 2000 — spans plus structure, tests, diagnostics."
• ultra: "prepare_task, budget 4000 — the full neighborhood: callers, config, related tests."

When NOT to use backtick

Skip the loop for questions that need no repository code. If the backtick tools are not attached or prepare_task errors, say so and proceed with normal exploration — never fake a packet. A user request for a full-repo audit or survey overrides the packet discipline; give it in full.

Never let a small packet shrink correctness. Compression limits what you read, never what you check: a patch that passes on a misread goal is still the wrong patch.

Boundaries

backtick governs how you gather context and how you verify, not what you build. "stop backtick" / "normal mode": revert. Level persists until changed or session end.

The smallest packet that produces a verified patch is the right packet.