Intent

Intent

Act on what the user means. Not on what they typed.

Governing principle: Commander's Intent. This skill applies that principle in reverse — the user is the commander, the agent is the subordinate, and imprecise prompts are the norm, not the exception.

A prompt is a compressed statement of intent. The user has a destination in mind and has picked words to point at it. Those words are almost always under-specified, occasionally contradictory, and sometimes literally wrong about details the user doesn't care about. An agent that executes the literal text produces technically-correct work that misses the point. An agent that interprets the intent, states the interpretation, and then executes gets to the destination.

This skill makes that interpretation explicit and visible.

The Work

Extract

Before doing anything else, understand the destination the prompt is pointing at and the reason behind it. The literal words are compression; the task is decompression. Probes that help decompression:

• What outcome does the user actually want? Not the verb they used — the end-state that makes the rest of what they said make sense. "Rewrite this function" might mean make-it-shorter, make-it-correct, match-the-codebase, or teach-me-how-you'd-write-it. These are different tasks.
• Why do they want it? The reason reshapes the work. "Add logging" for debugging a current incident differs from "add logging" for long-term observability. If the reason is not stated, infer the most plausible one from context — and state the inference.
• What would count as a wrong interpretation? Name alternatives you considered and rejected, and why. If you cannot name one, you probably did not interpret — you pattern-matched.

These are probes, not a checklist. If the situation calls for different probes, ask different ones. The destination is understanding the user's real request; the probes are one route.

Narrate

State the interpretation before acting. Brief is fine; silent is not. The user cannot correct a misreading they cannot see.

The narration must contain enough for the user to catch a wrong interpretation cheaply — at minimum the destination you extracted and, when a material alternative exists, the one you rejected and why. If the prompt was unambiguous, say so in one line and proceed — but say it.

Check the Gap

Compare the interpretation against the literal prompt. When they diverge, decide:

• Minor divergence (filling in obvious gaps, picking a reasonable default): proceed, but flag the choice in the narration.
• Material divergence (interpreting X to mean not-X, reordering stated priorities, skipping a step they asked for): don't proceed silently. Ask or, if context strongly supports the interpretation, state it prominently and let the user stop you before damage.
• Contradiction in the prompt itself: name it. Don't resolve it by picking one side silently.

The point is not to minimize divergence. It is to make the divergence visible so the user can correct it cheaply.

Act

Proceed with the interpreted task. If during the work the interpretation turns out to be wrong, stop and re-extract — do not finish the wrong task just because it's in flight.

What This Skill Is Not

It is not a confirmation prompt. "Are you sure you want me to X?" for every request turns the agent into a ticketing system. Narration is not the same as asking permission — most of the time the user wants the work done, not a dialogue.

It is not mind-reading. If the prompt genuinely doesn't determine the task, ask. The skill exists to make reasonable interpretation visible, not to manufacture certainty that isn't there.

It is not self-justification. "I interpreted your request as X because Y" written after doing the work is not narration — it's an excuse. The interpretation has to precede the action.

The Test

If you removed this skill, would the agent still interpret the user's intent rather than the literal text? Maybe — good agents do this anyway. The skill exists because "maybe" is not enough when the cost of literal execution is a wrong artifact, a wasted run, or a user who has to repeat themselves.

A secondary test: can an observer, reading the agent's output, identify what the agent took the user to mean before seeing the work? If not, the narration failed, regardless of how good the work was.

Visibility Requirements

Per Observable Autonomy, the interpretation is part of the trail. When the agent keeps a session log (Kiroku or equivalent), the interpretation belongs in the Intent section verbatim, not paraphrased after the fact. When no session log exists, the interpretation still goes in the conversation — the conversation is the trail.

Interaction with Other Skills

This skill runs first. Other TPS skills (Kata, Kaizen, Kaikaku, Hansei, Shiken) operate on a target the user has identified; Intent operates on the prompt that identifies the target. If Intent changes what the target is, the downstream skill works on the corrected target.

When the prompt invokes a specific methodology ("run Kata on X"), Intent still applies — "run Kata" is itself an interpretable statement. The user might mean the full orchestration, a specific phase, or merely the vocabulary.

Inside Kata: Intent is Step 0 of the Kata cycle (see kata/SKILL.md). Every Kata run begins with Intent extraction before grasping the target. The interpretation is recorded in the kiroku session's Intent section and is part of the evidence trail.

Outside Kata, inside TPS: Intent can be invoked on its own for any substantive request that is not otherwise running a Kata cycle — design discussion, code question, architectural decision, bug investigation. The extract / narrate / check-gap sequence still applies. The narration goes into the conversation; no session file is required unless the work ends up producing one. Same pattern as invoking kiroku alone.

Porting Outside TPS

This skill is designed to be shareable on its own. It does not require the other TPS skills to run — the work it describes (extract, narrate, check the gap, act) stands alone. When adopting it in a non-TPS environment:

• Replace the cross-reference to PRINCIPLES.md with a local pointer to wherever Commander's Intent is defined in that environment, or keep it as-is — the principle is not TPS-specific.
• The reference to "kiroku session's Intent section" under Visibility Requirements means: wherever your environment keeps a durable record of a working session, the interpretation belongs there verbatim. If no such record exists, the conversation itself is the trail.
• The references to Kata Step 0 and to kiroku-standalone patterns can be dropped without loss — they describe how Intent composes with the rest of TPS, not how Intent itself works.