core-explore-unknowns

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.

1. Known knowns — verify the fixed ground before asking for choices.
2. Known unknowns — line up visible questions and close them by evidence or user decision.
3. Unknown knowns — make implicit preferences, vocabulary, and local habits observable.
4. Unknown unknowns — look for hidden failure modes before a plan hardens.
5. 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.