Documentation v0.3.2
Earshot / Core concepts

Scope and editable plans

Declare the work, inspect the plan, and approve the text you actually reviewed.

Reviewed for 0.3.2 · Latest documentation

2. Scope contract#

Before the first mutating tool call, the agent states its scope in one paragraph: which files, which behaviours. Editing a file outside that scope triggers a confirmation prompt.

Unrequested refactors, renames, new dependencies and formatting sweeps are blocked by default — by policy text and by a guard, because policy text alone is not enforcement.

The guard is deliberately not a line count. A threshold either fires on every large change the user actually asked for or never fires on the small wrong ones, so what it checks is categorical: a file outside the declared list, a dependency manifest or install command, a rename or delete, a rewrite that changes no line's content, a removed test. Size is only a backstop, floored so that a small change is never over budget whatever the estimate said. A turn that declared no scope is not guarded at all — a prompt on every one-line fix is the prompt fatigue this document lists as an anti-goal.

3. A plan you can edit#

/plan produces a plan file you edit in $EDITOR or inline before approving. The approved plan is pinned into context for the run. A plan you can only accept or reject is a prompt, not a plan.

Working with a plan#

/plan fix the stale session selector
/plan edit
/plan show
/plan approve
/plan clear

/plan drafts in plan mode. /plan edit opens the plan in $VISUAL or $EDITOR, or prints its path. Approval pins the file as it now reads. Subagents inherit the approved plan and share the same scope contract object.

A scope is not a permission#

Declaring a file in scope does not approve a mutation. Every action still passes through the permission gate. A turn without a declared scope is not guarded by the scope contract; permission rules still apply.

Something unclear?Suggest a correction on GitHub ↗