> ## Documentation Index
> Fetch the complete documentation index at: https://reikon.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Goals

> Set what you're steering toward in plain language; Reikon tracks each goal deterministically, forever after.

# Tour: Goals

**Goals is the wheel's first stage — set intent.** Tell Reikon what you're steering your
codebase toward, and it tracks your progress on every analysis, with zero AI in the loop
after setup. Press `2` to jump here.

## A goal is a plain-language target

"Fewer `useEffect`s over time." "No file over 500 lines." "Keep test coverage above 80%."
"More TypeScript than JavaScript." Describe what you want in a sentence; Reikon translates
it once — using an AI tool you've connected, if you have one — into a precise, countable
rule, and shows you that rule before you save. No AI connected? Pick the rule type from a
menu and fill the fields in yourself. Either way, what gets saved is a deterministic check,
not a prompt.

You also set a **fix approach** for each goal — a short note on *how* to achieve it, prefilled
with a sensible default for the goal type and fully editable. It rides along to your agent when
you dispatch the goal, so the agent gets tactics ("split large files into modules, completely")
rather than just a target number.

Reikon only accepts a goal it can actually count. Ask for something vague — "make it
cleaner" — and it says so, rather than pretending to track it.

## Tracked forever, deterministically

Every goal records a **baseline** the moment you create it, then re-checks itself on every
analysis: current vs. baseline, a sparkline of the trend, and a status — improving, holding,
regressing, or met. When a goal regresses, Reikon shows the files driving the number, so you
know exactly where to look.

(Creating a goal with uncommitted changes in your tree? Reikon warns you — the baseline would
count those changes. Commit first, or re-baseline later, for a clean trend.)

Goals you're no longer steering by can be **archived** — they drop out of the way without losing
their history. The tab splits three ways (each with its own count): **Active** is your in-progress
worklist, **Met** holds the goals you've currently hit, and **Archived** is the manual shelf for
goals you've set aside. Met is live — a goal that's met moves there on its own, and slides back to
Active if the code regresses; unarchive any goal to bring it back.

## Goals close the loop

A goal isn't just a chart — it's something you can hand to your agent. Each goal card has two
verbs. **Request fix** is the *selector*: it adds the goal to your request set (and starts
tracking the attempt against an effort budget); the button flips to **Requested** — click again
to drop it. **Copy prompt** is the *primary* action: it composes a kickoff prompt for that one
goal — its description, the exact files driving the number, and your fix approach — and previews
it to copy. The Goals header has a **Copy all** that does the same for every requested goal at
once.

Paste the prompt into your own agent; or, if your agent has Reikon's MCP connected, tell it to
"work Reikon's dispatch queue" and it pulls the goals itself (the
[`reikon-queue` skill](../../guides/mcp-claude-code) teaches it the steps). Either way your agent
works in its own environment and Reikon never runs it for you — it prepares the hand-off, you give
the verdict.

Reikon re-checks the number deterministically on every analysis — that re-check *is* the
verification, not the agent's say-so: the rule is the stop-condition, the engine is the judge.
If a goal didn't budge it stays in **Active** (so you never accept a no-op); when it hits target
it moves to **Met** on its own. It's the same loop as [Review](./changes), pointed at a goal
instead of a diff.

A request carries an **effort budget** so it can't loop forever. The card counts attempts
(`Requested · 2/5`) when the metric moves or a commit touches the goal's driving files —
unrelated commits don't burn the budget; if the budget runs out with the goal still
short of baseline, it **gives up** — the agent is told to stop and leave a note on
how close it got, and you get a "Gave up after 5 · closest 41" card with **Retry +5**
(extend the leash) or **Clear**. An unreachable target fails into a finding, never an
infinite loop.

Because the agent worked the goal in its own environment — possibly across several
iterations you didn't watch — a requested goal's card carries a **Review changes since the request**
button. It shows the cumulative diff since the request began (every file touched, additions
and deletions, the commit count) so you can judge the whole change at once. The longer the
leash, the more there is to review — and Reikon makes that scope legible instead of hiding it.

Your agent can read your goals over MCP (`get_rule_progress`) and bias its work toward them —
if you want fewer `useEffect`s, it won't add more.
