Lovable already reads a SKILL.md. Give it the rubric that keeps escalation honest.

Lovable's own team has publicly argued against exposing a model picker: its control plane assigns different parts of a build to different models on its own, dynamically, and that routing isn't a lever any prompt or skill file can pull. This rubric can't force Lovable onto a cheaper model the way it can for Claude Code or Cursor — see how this maps onto Lovable before you install it expecting the same lever.

How this maps onto Lovable

Two confirmed paths in. One thing it genuinely can't do.

Lovable's documented Skills feature is a close, deliberate cousin of the open SKILL.md standard this repo already targets. Per Lovable's own Skills docs, a workspace owner or admin can import a skill straight from a public GitHub URL — either the whole repo, or a subdirectory path in the form github.com/owner/repo/tree/<branch>/path/to/skill, provided that path "contains SKILL.md directly." Undercut's skill folder already sits at exactly that shape (skills/firstpass/SKILL.md, front matter with a name and description), so the subdirectory URL below points straight at it with nothing to rewrite. Once imported, "every custom workspace skill has Automatic use enabled by default" — Lovable applies it when a request matches the description, or you invoke it manually as /firstpass.

Separately, Lovable's own Knowledge docs confirm that "instruction files such as AGENTS.md or CLAUDE.md" in a project's connected GitHub repo also guide the agent, and that a "root-level AGENTS.md" is "always read by the Lovable agent regardless of session length." That path needs the project's repo connected via Lovable's two-way GitHub sync, which is a paid-plan feature in practice — the Skills import above has no such gate documented, which is why it's Option 1 below.

Here's the part worth being blunt about. Undercut's tier names — cheap, standard, frontier, apex — work everywhere else on this site because the agent reading them can itself choose which model handles a delegated unit of work. Lovable's own engineering blog is explicit that it deliberately does not expose that choice to you or to prompt text: a proprietary control plane "can assign different parts of the build to different models" on its own, dynamically, "watching the work" rather than taking a fixed instruction up front. We have not found, and don't expect to find, a documented way for a Skill or an AGENTS.md line to steer that control plane's model choice. So on Lovable, install this for what it can confirm doing — give the agent a versioned rubric for classifying ambiguity and blast-radius, checking its own output before claiming it's done, and escalating only on a failed check or a flagged uncertainty — not for the cost-routing lever this same file pulls on Claude Code or Cursor. Whether that verification discipline also happens to influence Lovable's own internal routing is unverified either way; we're not claiming it does.

Nothing here sits between Lovable and its backend. It's a markdown file Lovable's own infrastructure hosts and reads — no proxy, no network hop Undercut controls, nothing to route around if you delete the skill.

Install for Lovable

Free. MIT. Nothing installs, nothing proxies your traffic.

Option 1 — import as a workspace Skill from GitHub (recommended, confirmed path)

In Lovable, go to Workspace settings > Skills > Import from GitHub and paste the subdirectory URL below. Lovable downloads it, validates the SKILL.md, and adds firstpass to every project in the workspace with Automatic use already on.

Option 2 — append to a project's AGENTS.md (GitHub-synced projects)

If the project's repo is connected via Lovable's two-way GitHub sync, a root-level AGENTS.md is always read regardless of session length — useful for one project specifically, or if you're not a workspace owner/admin and can't add a workspace Skill yourself.

Validate it yourself

1. 1Read the published results — testing/README.md and the raw JSON in testing/results/
2. 2Reproduce for free, no API key, no spend: node src/main.js --mock
3. 3Open a Lovable project after importing the skill and check the slash menu for /firstpass before starting mechanical work

Zero lock-in. It's markdown text Lovable reads — remove the skill or the AGENTS.md block and you're back to status quo.

Six flags assign a tier. Three triggers are the only way up.

This is a named, versioned spec — not internal logic we could quietly change. When the rubric changes (a new flag, a different cap), the version number moves and the changelog says why.

Every unit of work gets scored against six flags, then assigned the cheapest tier that can plausibly handle it. It only moves up a tier when something objective proves it needs to — a failed check, a measured disagreement, an explicit uncertainty flag. It never moves up on a guess, and it never moves back down mid-task.

 unit of work
      |
  6-flag rubric
      |
  +---+----+
  | 0 flags|--> cheap
  | 1-2    |--> standard
  | 3+/own |--> frontier
  +---+----+
      | fail x2 / disagree / uncertain
      v
  escalate +1 tier
  (residue only)
      |
  still unresolved?
      v
  single batched
  apex tie-break

Why it holds up

Flags steer. Verification and escalation decide.

Even when the rubric flags are scored imperfectly, the escalator still routes work to the right tier almost every time — because a wrong flag only ever costs one extra cheap attempt, never a wrong answer or a big bill.

Honest limits

What this doesn't do.

Not a proxy, not a gateway, doesn't auto-flag in production, and doesn't promise a dollar figure for your workload. It also doesn't prove your number until you run it — every figure here is an observation from our tasks and our graders, not a guarantee about yours. And on Lovable specifically: it does not, and cannot, override which model Lovable's own control plane picks for a given part of your build — Lovable has said publicly it keeps that decision internal and dynamic, and we've found no documented way for a Skill or AGENTS.md file to change it. The measured cost-routing numbers in the benchmarks above come from clients where the agent itself chooses the model per unit of work; treat that part of the pitch as not applicable to Lovable until its docs say otherwise. Full list of general limits, with the finance/procurement note and the paid-tier disclosure, is on the main page.