openspec-explore

Explore ideas and clarify requirements within OpenSpec workflows.

3|Updated Nov 25, 2025
One-click install
npx skills add https://github.com/g1331/AutoRouter --skill openspec-explore-g1331
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: openspec-explore
Source: https://github.com/g1331/AutoRouter/tree/main/.claude/skills/openspec-explore
Command: npx skills add https://github.com/g1331/AutoRouter --skill openspec-explore-g1331

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Provides a thinking partner to explore ideas, investigate problems, and clarify requirements before implementing changes.

Core Features & Use Cases

  • Non-prescriptive exploration: Encourages open-ended thinking, surface multiple directions, and avoids premature conclusions.
  • Codebase grounding: Reads and references the actual repository to keep discussions relevant.
  • Visual thinking: Uses ASCII diagrams and visuals to clarify complex ideas.
  • Risk surfacing: Identifies unknowns and potential risks to guide investigation.
  • Guardrails and stance: Emphasizes thinking, not coding, with guardrails against implementation.

Quick Start

Start explore mode to think deeply, visualize freely, and follow the conversation wherever it goes.

Frequently Asked Questions about openspec-explore

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I explore ideas and clarify requirements before coding?

A thinking partner helps you explore ideas and clarify requirements by reading your codebase, using ASCII diagrams for visual thinking, and surfacing unknowns. It enforces guardrails to prevent premature implementation during early design discussions.

What is the best way to investigate problems in a codebase during design?

Investigating codebase problems during design works best with non-prescriptive exploration that grounds conversations in the actual repository. This keeps discussions relevant by referencing real code while avoiding premature conclusions.

Can I use visual thinking and ASCII diagrams to map out software requirements?

Yes, visual thinking using ASCII diagrams clarifies complex ideas when mapping out software requirements. This thinking partner approach supports flexible inquiry and keeps exploration grounded while refining requirements within OpenSpec workflows.

How do I prevent premature implementation when discussing design changes?

Preventing premature implementation requires guardrails that emphasize thinking over coding. A thinking partner enforces this stance by focusing on requirement exploration, risk surfacing, and open-ended investigation rather than jumping straight to writing code.

Does OpenSpec explore mode work without writing any code?

Yes, OpenSpec explore mode works without writing code. It acts as a thinking partner with guardrails against implementation, enabling you to investigate problems, visualize ideas freely, and capture artifacts only when explicitly requested during the conversation.