| name | intent-lock |
| description | Fires before multi-step work when the user's request contains ambiguous referents ('the text', 'her Y'), characterizations of unverified entities ('the meeting is substantive'), or identity assumptions (which contact = the user). Emits a one-sentence interpretation lock for fast async correction; escalates to Asking only when interpretation gates an irreversible action AND multiple plausible reads exist. |
| context | load |
When to invoke
Check for these signal classes before starting any multi-step task:
Ambiguous referents — a noun phrase that could resolve to more than one entity in context:
- Bare demonstratives with no prior binding: "the text", "the doc", "that email", "the file"
- Possessives pointing to unintroduced people: "her draft", "their proposal", "his calendar"
- Ordinals with unclear basis: "the first one", "the latest version", "the other branch"
Unverified characterizations — a status or quality claim about a named entity the agent cannot confirm:
- "The meeting is substantive" (agent has not read the meeting)
- "The PR is approved" (agent has not checked)
- "The last run passed" (agent has not run or read CI output)
Identity assumptions — who is "the user", "me", "us", "the team", or a named person when the identity matters for action:
- Sending to "me" when multiple contact entries exist
- Filing under "my account" when credentials are ambiguous
- "The owner" when ownership is not established in context
Code-vs-runtime dual referent — a term that names an entity in the active codebase AND a model runtime concept. Fires when the user is working on a tool whose vocabulary mirrors the agent's own runtime (parity-mirror projects like agent CLIs, plugin frameworks, or harness tooling):
- "memory" — the project's memory store OR the agent's own session memory
- "session" — a project's session class OR the agent's conversation
- "hooks" — the project's hook registry OR the agent's tool-use hooks
- "agent" / "subagent" — the project's agent abstraction OR the agent dispatching them
- "tool" / "skill" / "plugin" — the project's loadable units OR the agent's available tools
- "MCP" / "terminal" / "REPL" — primitives the project implements that the agent also has
Skip when:
- Referent resolves unambiguously from immediately prior context (file was just read this turn, entity was named and confirmed, prior message established the binding).
- Request is reversible, exploratory, and any misread is immediately correctable without cost.
- User has already provided the interpretation explicitly ("I mean X by 'the text'", "agent-afk's memory", "my session", "this codebase's hooks").
- Single-step clarification would cost more than simply proceeding and correcting.
- Dual-referent term has no matching symbol in cwd — no parity risk, standard interpretation applies.
Procedure
Step 1 — Scan
Before acting, scan the request for signal classes above. List every ambiguous referent, unverified characterization, identity assumption, or code-vs-runtime dual referent found. If zero are found, skip this skill entirely.
Step 2 — Classify each finding
For each finding, determine:
- Plausible reads — how many distinct interpretations exist given available context?
- Gate type — does this interpretation gate a reversible or irreversible action?
Step 3 — Choose resolution mode
| Condition | Mode |
|---|
| Single plausible read, reversible action | Lock — emit interpretation, proceed |
| Single plausible read, irreversible action | Lock — emit interpretation, proceed (but flag) |
| Multiple plausible reads, reversible action | Lock — emit most-likely read with explicit note, proceed |
| Multiple plausible reads, irreversible action | Asking — stop, ask one question |
Multiple plausible reads means two or more interpretations that would produce materially different outcomes. "the text" pointing to one of two equally recent documents = multiple. "the text" when only one document was discussed this session = single.
Step 4 — Emit the lock
Lock format (most cases):
Interpreting: [ambiguous phrase] → [resolved referent]. Proceeding on that basis — correct me if wrong.
One sentence. No preamble. Append to the start of the work output, not as a standalone turn. The user can correct asynchronously; work continues.
If multiple locks needed: stack them, one per line, before the work output.
Asking format (irreversible + multiple reads only):
[One precise question that resolves the ambiguity.] (This determines [what action follows].)
One question. State what it unlocks. Do not proceed until answered.
Interaction with other skills
thesis-lock fires on first-person thesis before drafting. Intent-lock fires on the user's request before any multi-step work. They are complementary: thesis-lock protects the agent's own claims; intent-lock protects the agent's reading of what the user asked.
ground-state fires before implementation to survey repo state. Intent-lock fires before any multi-step work on requests with ambiguous inputs — including non-implementation work like drafting, research, or messaging. They can both fire on the same request (ground-state runs after intent-lock resolves).
premise-gate checks named-entity and status-claim pairs during research and analysis. Intent-lock fires before work begins on the request itself. They address the same underlying hazard at different points in the pipeline: intent-lock at request intake, premise-gate during execution.
Exit criteria
- Every ambiguous referent, unverified characterization, identity assumption, and code-vs-runtime dual referent is either locked (one-sentence interpretation emitted) or escalated to Asking.
- No multi-step work begins on a request whose interpretation gates an irreversible action when multiple plausible reads exist.
- Lock statements are visible in the turn output before the work they govern.
- Asking state contains exactly one question and states what it unlocks.
