| name | challenge |
| description | Run a risk-scaled blind-spot discovery pass over a converged, exported frame BETWEEN /think and /spec-to-plan (the seventh origin skill, third leg in flow order): pressure-test the spec through structured lenses, route every finding back through the existing deterministic moves as proposed-only content the human adjudicates, and on a clean pass record the examined lenses/surfaces and residual uncertainty — never a claim that there are no unknown unknowns. Use when the user says "challenge this spec", "blind-spot pass", "pressure-test the frame", "what are we missing", "unknown unknowns", or after /think exports and before `devague plan new`. 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.
|
| type | command |
challenge — hunt the blind spots before the plan inherits them
The skill is named challenge; it is the blind-spot discovery leg of
the devague method — the seventh origin skill, sitting third in flow
order, between the spec leg and the plan leg:
scope -> think -> challenge -> spec-to-plan -> assign-to-workforce -> deviate -> summarize-delivery
Before this leg existed, a frame could converge on precisely stated claims
while the original framing was still incomplete: open questions only captured
uncertainty someone had already noticed — nothing actively hunted omitted
dimensions, hidden dependencies, or assumptions shared by everyone in the
frame, and no record existed of which surfaces were ever examined
(issue 73's problem statement). Strictly speaking, an unknown unknown cannot
be listed directly — once articulated, it becomes a known unknown. The useful
capability is therefore to raise the odds of discovering blind spots and
lower the cost of the surprises that remain, not to promise their
elimination.
That is the surprise-cost rationale: an articulated blind spot becomes a
known unknown the method can manage; an unexamined one surfaces later as a
mid-run /deviate or a production surprise. Discovery before planning is
cheaper than either — a proposed claim the human rejects costs minutes; the
same gap found mid-fan-out stops a wave, and found in production it costs
whatever the blast radius costs.
This doc is written for two readers. The operator — the main agent — runs
the pass: sweeps the lenses, drives the deterministic CLI move by move, and
proposes findings. The gate-owning human adjudicates: every finding lands
proposed, and confirming, rejecting, or resolving it is the human exercising
the existing spec gate (gate 1) — challenge adds no fourth gate, mirroring
how /deviate amends gate 2 rather than adding one.
When it runs
The timing is a recorded decision — quote it, don't re-derive it:
the challenge pass runs after /think exports: challenge the converged,
exported frame before devague plan new; findings reopen the frame,
reconverge, and re-export the same dated spec file — /think stays
self-contained (resolves q1)
— decision c17 in docs/specs/2026-07-15-challenge-skill.md.
Concretely: /think finishes its own arc (converge, export) untouched. Then
/challenge pressure-tests the exported spec before devague plan new
seeds a plan from it. Findings land as proposed claims, honesty conditions,
questions, or parks — which reopens the frame — the human adjudicates, the
frame reconverges, and devague export re-exports the same dated
file (docs/specs/<created-date>-<slug>.md; exports are prefixed with the
frame's creation date, so a re-export overwrites in place rather than
spawning a duplicate). That reconverge-and-re-export loop repeats until the
pass's findings are all adjudicated and the spec artifact carries them.
Proportionality — scale the pass to the risk
The pass is mandatory but proportional: lightweight for ordinary work,
rigorous for high-risk work (integration option 1 from issue 73, per the
issue author — a distinct operator skill, no new CLI engine until the
workflow proves it needs one). Which work is high-risk is likewise a recorded
decision:
the named escalation signals that deepen the pass from lightweight to
rigorous: migrations, security-sensitive work, distributed state, hardware,
destructive operations, other hard-to-reverse changes, concurrency hazards,
and any surface that can lose user data (resolves q3)
— decision c19 in docs/specs/2026-07-15-challenge-skill.md.
If any escalation signal applies, run the rigorous form: every lens,
deliberate counter-evidence hunting, and cheap probes where they would settle
a real question. If none applies, a lightweight sweep — one pass over the
lenses against the exported spec, minutes not hours — satisfies the method.
Lightweight never means skipped: even the lightest pass leaves durable
records (see the hard rules).
The lenses
Sweep the exported spec, the live frame, and the surfaces the idea touches
through these structured lenses (from issue 73):
- adjacent systems and hidden dependencies — what else reads, writes, or
assumes the thing being changed;
- unstated assumptions and missing counter-evidence — what everyone in
the frame believes without a claim saying so, and what was never checked
because nobody argued the other side;
- overlooked actors, lifecycle stages, data flows, and failure modes —
who and what the frame forgot: other users, upgrade/downgrade paths,
half-completed operations;
- security, migration, concurrency, operations, and reversibility — the
classic hard surfaces, each also an escalation signal when present;
- missing observability, containment, rollback, and recovery paths —
when the surprise happens anyway, how it is seen, bounded, and undone;
- cheap probes or experiments — small, scratch-space checks that could
expose a surprise now instead of mid-run (probes never mutate the repo or
.devague/ state).
The method
- Confirm the entry condition. A converged frame that
/think has
already exported, and no plan seeded from it yet (devague status shows
where the frame stands; the exported spec-md is the artifact under
challenge).
- Set the depth. Check the idea against the c19 escalation signals
above. Any hit → rigorous; none → lightweight. Say which you chose and
why — the depth decision is part of the pass's record.
- Sweep the lenses read-only. Read the exported spec claim by claim,
the frame's parked vagueness and resolved questions, and the actual
surfaces the idea touches. Nothing mutates during the sweep; the only
mutations are the deterministic moves that record findings.
- Route every finding through an existing move. Use the routing table
below. Everything the agent proposes carries
--origin llm and lands
proposed — the pass cannot silently convert speculation into confirmed
requirements.
- Let the human adjudicate.
devague review lists every proposal with
ids; devague confirm / devague reject / devague question --resolve
are user-only decisions. This is the existing spec gate doing its job.
- Reconverge and re-export.
devague converge, then devague export —
the same dated spec file now carries the adjudicated findings and the
pass's provenance (the exported spec renders scope entries in its
Scope exploration section).
- On a clean pass, record the pass itself. A sweep that finds nothing
still records which lenses and surfaces were examined (
devague scope
entries, one per lens/surface, e.g. challenge pass / concurrency lens: devague/store.py) and what residual uncertainty remains (park). A bare
"no issues found" is not an outcome this skill produces.
Where findings land
Challenge keeps no parallel prose-only artifact — the frame is the
record, and every output category from issue 73 has an existing deterministic
move to land in:
| Output category (issue 73) | What it is | Landing move |
|---|
| known facts | something the pass established, with provenance | capture --kind requirement / --kind decision / --kind boundary (--origin llm → lands proposed) |
| assumptions | beliefs the frame leaned on unstated | capture --kind assumption --origin llm, then pressure-test with interrogate --honesty / --hard-question / --contradicts |
| known unknowns / open questions | articulated uncertainty | question "<text>" when it needs a user decision; park --kind unknown_nonblocking|unknown_blocking when not decidable now |
| unexamined surfaces | what this pass did not (or could not) look at | devague scope "<surface>" --finding "<what was and wasn't examined, and why>" |
| residual surprise risk | uncertainty that survives the pass | park on the frame while speccing; devague plan risk --kind <kind> once the plan exists |
| resilience measures | containment, rollback, recovery the surprise cost demands | spec-side capture --kind requirement / --kind boundary; plan-side devague plan risk (see below) |
Every finding names the lens and surface it came from (the
challenge pass / <lens>: <surface> convention in scope entries; provenance
citations inside claim text). That provenance bar is how the method hunts
blind spots without encouraging speculative issue generation — a finding
you cannot trace to something you actually read is speculation, not a
finding.
Resilience placement — spec-side or plan-side
Where a resilience measure lands is a recorded decision:
resilience measures land in both spec and plan by nature: spec-side as
requirement/boundary claims when they change what to build, plan-side as
plan risks or tasks when they change how to build it — the skill coaches
which is which (resolves q2)
— decision c18 in docs/specs/2026-07-15-challenge-skill.md.
The coaching: ask "does this change what ships, or how it gets
built?" A rollback path the user needs, a fail-closed version check, a
containment boundary — those change the product: capture them spec-side as
requirement / boundary claims so the re-exported spec carries them.
A staging sequence, a merge-order constraint, an uncertainty the workforce
must build around — those change the build: land them plan-side via
devague plan risk --kind <kind> (blocking or nonblocking, honestly chosen)
once /spec-to-plan seeds the plan, where the plan's convergence gate keeps
blocking risks visible until resolved.
Hard rules (do not violate)
- Never conclude there are no unknown unknowns. Not after a rigorous
pass, not after a clean one. The only honest clean-pass output is a record
of which lenses and surfaces were examined —
devague scope entries — plus
the residual uncertainty that remains — park — so the pass leaves durable
provenance instead of a comforting absolute (issue 73 success criteria;
the anti-fabrication contract in docs/llm-guidance.md).
- LLM-origin findings stay proposed until the user confirms. Every
finding the agent proposes carries
--origin llm and lands proposed;
only the user's confirm makes it real. The pass must not be able to
silently convert speculation into confirmed requirements.
- Findings route through existing deterministic moves only.
capture,
interrogate, question, park, devague scope, devague plan risk —
nothing else. No parallel prose artifact, no new CLI verb, engine, or
state model (issue 20; issue 73's stated preference). If it didn't land in
a move, it didn't land.
- Provenance on every finding. Name the lens and the surface it came
from. If you didn't read it, don't claim it — same bar as
/scope.
- Proportional, never skipped. Lightweight is the floor, not an
exemption; any c19 escalation signal makes the rigorous form mandatory.
Skipping the pass entirely is not a depth setting.
- Not a fourth standing gate. The three human gates stay: exported spec,
implementation split plan, final PR. Challenge output is adjudicated
inside the existing spec gate — mirroring how
/deviate amends gate 2
rather than adding one.
- The sweep is read-only until it routes. Reading spec, frame, and
surfaces never edits files or state; probes run in scratch space. The only
mutations are the recording moves themselves.
Worked example
Challenging the exported spec for a store-schema migration (illustrative
slug store-schema-v3) — "migrations" and "any surface that can lose user
data" are both c19 escalation signals, so the pass runs rigorous:
devague capture --origin llm --kind assumption "older installed devague binaries refuse a v3 store via the fail-closed schema_version check in devague/store.py"
devague interrogate c9 --origin llm --honesty "a v2-reading binary pointed at a v3 store exits with the version hint, not a traceback"
devague scope "challenge pass / adjacent-systems lens: devague/store.py schema_version gate" --finding "older binaries fail closed on v3; seeded the compat assumption" --seeds c9
devague capture --origin llm --kind requirement "migration writes to a temp file and renames — a killed run never leaves a half-written store"
devague question "do mesh agents share one store, or does each checkout own its own?"
devague park "whether a v3->v2 downgrade path is ever needed" --kind unknown_nonblocking
devague scope "challenge pass / concurrency lens: devague/store.py + delivery_store.py" --finding "single-writer CLI, no locking today; clean pass — residual risk only if two agents ever share a checkout"
devague review
devague confirm c9 h4 c10
devague question --resolve q1 --decision "each checkout owns its own store"
devague converge
devague export
devague plan new --frame store-schema-v3
devague plan risk "two agents sharing a checkout could interleave store writes mid-migration" --kind unknown_nonblocking
Every finding above is traceable to a lens and a surface; the clean lens is
recorded as examined rather than silently dropped; and nothing the agent
proposed became confirmed without the human's confirm.
After the pass — hand off to /spec-to-plan
Once the frame reconverges and the same dated spec file is re-exported, the
pass is done — the examined surfaces, residual uncertainty, and adjudicated
findings all live in frame state and render into the spec artifact. Continue
with /spec-to-plan as usual: the plan seeds from the challenged frame, and
any residual surprise risk you routed plan-side lands via
devague plan risk as first-class plan state. If a surprise still gets
through mid-fan-out, that is /deviate's job — and every approved dN
deviation record is evidence for what the next challenge pass's lenses
should look harder at.
Provenance
This is a first-party skill — its origin is agentculture/devague, the
seventh in the outbound family after /scope, /think, /spec-to-plan,
/assign-to-workforce, /deviate, and /summarize-delivery, sitting third
in flow order as the blind-spot discovery leg between /think and
/spec-to-plan. 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.