| name | scope |
| description | Explore the scope of a vague idea BEFORE framing it into a spec (the idea→scope leg; the optional opening move ahead of the `think` skill). Survey the surfaces the idea touches — code, docs, skills, CI, sibling repos — and seed the coming Announcement Frame with boundary, non-goal, and assumption claims that cite what was actually explored (provenance, not generic disclaimers). Use when the user says "explore scope", "scope this idea", "what does this touch", "map the scope", "scope exploration", or when an idea touches an existing codebase and speccing it cold would mean guessing its boundaries. Hand off to the sibling `think` skill to build the frame. Authored and maintained in agentculture/devague (origin = devague); guildmaster pulls this skill from here and broadcasts it to the AgentCulture mesh — it is NOT vendored from guildmaster like the inbound skills here. |
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.)
How to run in qwen
The moves run through the devague CLI — the same agent-agnostic commands for
any agent or operator (if devague isn't on PATH: uv tool install devague). Qwen Code has no curated tool allow-list: every move — the frame
moves (new, capture, interrogate, park, converge, status, show)
and the scope / question moves — runs directly through the shell tool
(run_shell_command), and the operator runs the same commands directly in a
terminal.
The method
- 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.
- 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.
- 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).
- 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)
The primary landing surface is the deterministic devague scope move,
shipped in task t3 of the committed sharper-end-to-end-method plan (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:
| Move | What it does |
|---|
devague scope "<surface>" --finding "<text>" | Record a finding on the current frame. |
devague scope "<surface>" --finding "<text>" --seeds <claim-id> [<claim-id> ...] | Record a finding, linking it to the claim id(s) it went on to seed. An unknown seed id is refused with a hint (run 'devague show' to see valid claim ids). |
devague scope --list [--json] | Read every recorded entry back. |
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:
| Finding | Move |
|---|
| in scope (the idea changes this) | capture --kind requirement / --kind assumption (with --origin llm if you proposed it) |
| out of scope (must not change) | capture --kind boundary / --kind non_goal |
| genuinely unknown, needs a user decision | question "<text>" (later question --resolve <qid> --decision "<text>") |
| genuinely unknown, not decidable now | park "<text>" --kind unknown_blocking|unknown_nonblocking |
Hard rules (do not violate)
- Exploration is read-only. Surveying scope never edits files, never
mutates frame state, never runs a mutating CLI move.
- Provenance in every seeded claim. A scope-derived claim cites what was
explored. If you didn't read it, don't claim it.
- LLM proposals stay proposed. Findings you capture with
--origin llm
land proposed; the user confirms. Same anti-fabrication contract as
think.
- Don't become a wizard. Scope exploration is optional-by-size and
adaptive. Never block a small idea on a survey it doesn't need.
Worked example
Scoping "devague exports should carry per-item instructions" against the
devague repo itself:
git ls-files devague/ | head -30
devague new "devague exports carry per-item instructions" --title "per-item instructions"
devague capture --origin llm --kind requirement "claims gain an optional instruction field — devague/frame.py claim model + docs/spec-contract.md schema both need a bump"
devague scope "devague/frame.py" --finding "claim model needs an optional instruction field per docs/spec-contract.md's schema contract" --seeds c2
devague capture --origin llm --kind boundary "render/spec_md.py renders instructions verbatim; absent instructions render nothing — the renderer never fabricates filler"
devague scope "render/spec_md.py" --finding "renderer must render instructions verbatim; absent instructions render nothing — never fabricate filler" --seeds c3
devague capture --origin llm --kind non_goal "no LLM calls land inside the CLI (issue 20) — instruction text is authored by the operator/user, never generated in-CLI"
devague scope "issue 20 (no LLM calls in-CLI)" --finding "instruction text is authored by the operator/user, never generated in-CLI" --seeds c4
devague question "do instructions attach to frame claims, plan tasks, or both?"
devague scope --list
Every claim above names the file or issue that was actually read — that is the
provenance bar. Note the order: --seeds needs the claim id to already exist,
so capture runs first and the matching scope call cites it back.
After scoping — hand off to think
The recorded scope entries and the claims captured alongside them both live on
the same frame — there is nothing separate to export. devague scope --list
is the durable, citable record of what was explored; a converged frame's
exported spec-md also renders a ## Scope exploration section from the same
entries (surface, finding, and seeded claim ids), so the provenance survives
into the buildable artifact (#53 t6). When the survey is done, continue with
think's remaining moves (interrogate, confirm/reject, converge,
export) to take the frame the rest of the way. The user confirms
LLM-proposed claims there, as always.
Provenance
This is a first-party skill — its origin is agentculture/devague, the
fourth authored in the outbound family (after think, spec-to-plan, and
assign-to-workforce) but the opening leg of the flow, covering the
pre-frame exploration that runs before think. guildmaster pulls it from here
and broadcasts it to the AgentCulture mesh; because devague is upstream, it is
never re-vendored back from guildmaster's re-broadcast copy. The
cite, don't import policy still holds: downstream repos copy it, they don't
symlink or depend on it. See docs/skill-sources.md.
