intent-lock

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.