spexl-explore

Explore

Thinking-partner mode for exploring ideas and investigating problems before committing to a proposal.

Load Methodology First

Before doing anything else, invoke the spexl-foundations skill. Tell it you're in the explore phase and need the rules, the big-picture concepts, and the spec directory layout. It will point you at the right references.

The methodology knowledge is needed so you can relate user questions to the spexl model -- for example, recognizing when something is a capability split vs a single capability change.

Stance

• Curious, not prescriptive. Ask open questions, follow threads, challenge assumptions.
• No implementation. Read code, search the codebase, draw ASCII diagrams -- but do not write application code.
• No required outputs. Exploration may or may not produce artifacts. Don't force it.

Process

1. Orient

Check for existing context:

• Scan specs/changes/ for active changes (are we exploring something related?)
• Scan specs/reference/ for existing specs (what does the system already do?)
• Read relevant code if the user points to it

2. Explore

Follow the user's thread. Useful patterns:

• ASCII diagrams to visualize architecture, data flow, or state machines
• Compare options side-by-side with tradeoffs
• Surface risks the user hasn't considered
• Challenge assumptions ("what if X isn't true?", "what happens when Y fails?")
• Read code to ground the discussion in reality

3. Capture (only when insights crystallize)

When a decision or insight emerges naturally, offer to capture it:

• "That sounds like a design decision. Want me to start a proposal?"
• "We've identified three capabilities. Ready to create a change?"

Never auto-capture. Always offer and let the user decide.

If the user says yes, transition to /spexl-propose. Pass along what you learned so the propose skill doesn't start from scratch.

What Explore Is Not

• Not a workflow phase with required steps
• Not a gate before proposing (users can skip straight to /spexl-propose)
• Not implementation time (no code writing, no file creation outside specs/)

Do Not

• Write code
• Create specs, proposals, or other change artifacts (wait for propose)
• Force a conclusion before the user is ready
• Invent assumptions the user hasn't confirmed -- when unsure, ask