Scope

scope — explore what an idea touches before you frame it

The skill is named scope; it is the opening leg of the devague method — run it before the sibling /think skill frames an idea into a spec. Where /think converges on what to build, /scope grounds where the idea lives: which surfaces it touches, which it must not, and what is genuinely unknown — so the frame starts from explored territory instead of guesses.

This comes from the sharper end-to-end method spec (devague#53): scope grounded up front means convergence measures real coverage instead of vibes. The exploration itself is agent-side work — the devague CLI stays deterministic and never explores anything (#20).

When to use — and when to skip

Use /scope when the idea touches an existing codebase or ecosystem: a feature in a real repo, a process change across skills, anything where boundaries are discoverable rather than invented.

Skip it freely for small ideas. Scope exploration is not a mandatory first stage — the move-driven adaptive arc stays intact, and an idea that fits in one announcement can go straight to /think. (This is a recorded non-goal of the method: no wizard.)

The method

1. Enumerate candidate surfaces. List what the idea might touch: source packages, CLI verbs, renderers, schemas, tests, docs, skills, CI workflows, sibling repos. git ls-files and the repo's CLAUDE.md are the usual map.
2. Explore each surface read-only. Read enough of each candidate to decide: touched, not touched, or unknown. Exploration never mutates anything — no edits, no state changes, no CLI moves yet.
3. Classify every finding. Each explored surface yields one of:
   • in scope — the idea changes it → becomes a requirement or assumption claim in the frame;
   • out of scope — the idea must not change it → becomes a boundary or non_goal claim;
   • genuinely unknown — can't tell without a decision → becomes a park (open vagueness) or a question (pending user decision).
4. Record findings on the frame, with provenance. Start the frame with devague new "<announcement>" --title "<short>" (this is also /think's first move) — scope entries live on the frame, so it must exist first. Record each explored surface as a first-class finding: `devague scope "<surface>" --finding "<text>" [--seeds <claim-id> ...]` — text that cites the surface explored ("the CLI stays deterministic per issue 20; scope exploration is agent-side" beats "we won't overreach"). Capture the claim it seeded first (capture --kind ...), then pass its id to --seeds — an unknown seed id is refused with a hint. Provenance, not generic disclaimers: a reviewer should be able to trace every boundary claim back to something you read.

How findings land (the shipped surface)

This skill invokes the CLI directly and stays self-contained (if devague isn't on your PATH: uv tool install devague).

The primary landing surface is the deterministic devague scope move, shipped in task t3 of the committed sharper-end-to-end-method plan (docs/plans/2026-07-01-devague-ships-a-sharper-end-to-end-method-a-guided.md, devague#53). It records an explored surface + finding as first-class frame state (Frame.scope_entries / ScopeEntry: id (sN), surface, finding, seeds) — deterministic recording only, no LLM calls, no subprocess, no filesystem exploration inside the CLI. Like capture, it needs a frame to already exist, so run devague new first:

Boundary / non-goal / in-scope claims still land the same way they always did, through the normal frame moves — devague scope documents what surface you explored and what you learned, capture records the claim that followed: