Checking and agents

What check looks for

Each profile brings its own rules, and one run checks them all. In components:

• unknown-intent

  An intent that is not in the registry; suggests the closest spellings.

• internal-intent

  A look intent used at a call site; suggests the meaning intents built on it.

• domain-mismatch

  An intent rendered by the wrong component, like <Text intent="action.save">.

• leaf-classname / leaf-style

  className or style on a component that only takes intents.

• layout-visual-class

  Colours, type or borders in a Layout className, which is for layout only.

• raw-element

  A <button>, <h2>, <input> or styled <p> instead of a component; suggests the closest intent.

• raw-surface

  A <div> that draws its own box (background, border, shadow); suggests a Layout intent.

• raw-look

  Any other plain element with look classes: a <div> with text colours, a <span> drawn as a dot, a styled <hr> or <iframe>.

• raw-style

  Inline styles that set colour, type or borders. Layout values and CSS variables are fine.

• intent-selector

  CSS or a class that selects elements by data-intent, which is for finding elements, not styling them.

• unknown-token

  A registry class that reads a CSS variable nothing declares, so it resolves to nothing.

• raw-value

  A registry class with a colour the theme cannot change, like bg-[#e5383b] or text-sky-700.

• unsafe-classname

  The escape hatch: an error without a prongs-unsafe reason, a warning with one.

• name-mismatch

  An action whose handler, label or text points to a different intent.

In error responses and logs, once those profiles are added:

• raw-error-response

  An error response written by hand; suggests the error intents with the same status.

• leaked-error

  An error’s own message, like error.message, sent to the caller, where it can expose internals.

• raw-console

  console.* in app code: nothing says who needs to know, and it may run in production.

• swallowed-error

  A catch whose only job is to print the error, so nothing notices the failure.

• secret-in-log

  Something named like a token, secret, password or cookie passed to a log without masking.

Every rule, with examples, is in the check rules reference. A deliberate exception takes a comment on the line above: // prongs-ignore: <reason>. The reason is required, and it stays in the code for the next person to read.

Adopting it in an existing app

prongs check --update-baseline records today’s findings in .prongs/baseline.json. After that only new findings fail, so the count can only go down. prongs check --suggest groups repeated overrides and styled elements into proposed intents, most repeated first, with the add-intent command to create each one.

Agent hooks

prongs install-hooks adds a Claude Code PostToolUse hook and a Cursor postToolUse hook. After every file an agent edits, the check runs on that file and the agent gets the result immediately, with the suggested intents, while it still has the code in front of it:

prongs check found 1 problem(s) in the file you just edited. Fix them before continuing:

app/settings.tsx:31:9  error  raw-element  <button> with its own styling; use <Action> with an intent.
    → <Action intent="action.save">: Keeps changes the user made to something that already exists

This is the difference between documentation and a harness. PRONGS.md tells an agent what the intents are; the hook tells it, at the moment it matters, that it did not use it.