# Checking and agents

Types stop the obvious mistakes. prongs check catches the rest, in components, error responses and logs alike, and tells the person or agent what to use instead.

## 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](https://www.prongs.dev/docs/rules.md). 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.