| name | core-explore-unknowns |
| description | Use only when the user explicitly invokes this skill to map unresolved product, domain, repository, or delivery unknowns before choosing a path. |
| metadata | {"version":"1.0","updated":"2026-07-26"} |
Explore Unknowns
Treat the prompt and any plan as a rough map, not the ground itself. The ground
is the current code, domain constraints, and what the user actually means. This
workflow closes the gap before implementation turns vague assumptions into code.
The deliverable is a four-part unknowns map. Move through the quadrants in order,
collecting evidence and user decisions, then hand the map over as the input to
the next workflow. Do not treat the walk itself as permission to build.
Two moves apply at every stage:
- Prefer reactable material over abstract questioning: a small sample, option
table, or concrete draft will surface taste and constraints faster than "what
do you want?"
- Shape each artifact so the user's next reply is easy: short options, check
boxes, or a draft message they can correct.
The Quadrant Walk
Five stages run in order. Open the reference file for the current stage before
working that stage. Name the quadrant you are in, close it visibly, then move
on.
- Known knowns — verify the fixed
ground before asking for choices.
- Known unknowns — line up visible
questions and close them by evidence or user decision.
- Unknown knowns — make implicit
preferences, vocabulary, and local habits observable.
- Unknown unknowns — look for
hidden failure modes before a plan hardens.
- Map handoff — package
decisions, open items, and blockers for the next workflow.
When the mapped work moves into build, review, or merge, read
after the walk: deviations found during
implementation are filed back into the map, reviewers get a buy-in package,
and long diffs get a merge-readiness check.
Rules
- Preserve stage order, but do not hide useful information because "its stage"
is later. Disclose decision-relevant facts immediately, then file them in the
right quadrant.
- A decision is not closed until the user has seen the question and the proposed
answer, even if local evidence supplied the answer.
- Ground repo or product claims in files, logs, docs, or data that were actually
read. Label illustrative examples as illustrative.
- Pause at stage boundaries when the next step depends on user reaction. Do not
implement from unconfirmed map entries.
