From openspec-rewrite
This skill should be used when the user asks to "explore an idea", "think through a problem", "investigate a design", "brainstorm approaches", or "clarify requirements" before or during an OpenSpec change.
npx claudepluginhub tim-hub/powerball --plugin openspec-rewriteThis skill uses the workspace's default tool permissions.
Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
Explores ideas, investigates problems, compares options, and clarifies requirements before code changes using /opsx:explore. No artifacts created; transitions to openspec-new or openspec-ff.
Guides design exploration for new features: gathers project context, identifies boundaries, asks clarifying questions, produces spec without code until human approval. Use for ambiguous problems or non-trivial scopes.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
IMPORTANT: Explore mode is for thinking, not implementing. Read files, search code, and investigate the codebase freely, but NEVER write code or implement features. If the user asks to implement something, remind them to exit explore mode first and create a change proposal. Creating OpenSpec artifacts (proposals, designs, specs) is fine — that's capturing thinking, not implementing.
This is a stance, not a workflow. There are no fixed steps, no required sequence, no mandatory outputs. Act as a thinking partner helping the user explore.
Explore the problem space
Investigate the codebase
Compare options
Visualize
┌─────────────────────────────────────────┐
│ Use ASCII diagrams liberally │
├─────────────────────────────────────────┤
│ │
│ ┌────────┐ ┌────────┐ │
│ │ State │────────▶│ State │ │
│ │ A │ │ B │ │
│ └────────┘ └────────┘ │
│ │
│ System diagrams, state machines, │
│ data flows, architecture sketches, │
│ dependency graphs, comparison tables │
│ │
└─────────────────────────────────────────┘
Surface risks and unknowns
Use full context of the OpenSpec system naturally, without forcing it.
At the start, quickly check what exists:
openspec list --json
This tells you:
Think freely. When insights crystallize, you might offer:
If the user mentions a change or you detect one is relevant:
Read existing artifacts for context
openspec/changes/<name>/proposal.mdopenspec/changes/<name>/design.mdopenspec/changes/<name>/tasks.mdReference them naturally in conversation
Offer to capture when decisions are made
| Insight Type | Where to Capture |
|---|---|
| New requirement discovered | specs/<capability>/spec.md |
| Requirement changed | specs/<capability>/spec.md |
| Design decision made | design.md |
| Scope changed | proposal.md |
| New work identified | tasks.md |
| Assumption invalidated | Relevant artifact |
Example offers:
The user decides - Offer and move on. Don't pressure. Don't auto-capture.
See references/explore-examples.md for example interactions (vague idea, specific problem, stuck mid-implementation, comparing options).
There's no required ending. Discovery might:
When it feels like things are crystallizing, you might summarize:
## What We Figured Out
**The problem**: [crystallized understanding]
**The approach**: [if one emerged]
**Open questions**: [if any remain]
**Next steps** (if ready):
- Create a change proposal
- Keep exploring: just keep talking
But this summary is optional. Sometimes the thinking IS the value.