openspec-explore

To explore codebase architecture and clarify requirements before implementation, use a thinking partner stance that reads files, surfaces questions, and maps dependencies without writing code. You investigate problems, validate requirements, and create ASCII diagrams to visualize flows.

Explore mode is strictly for brainstorming ideas and investigating problems without implementing features. You may read files, search code, and create OpenSpec artifacts like proposals and designs, but you must never write code or edit features while in this stance.

The best way to map dependencies and surface risks during an architecture review is to use a thinking partner that grounds discussions in the actual codebase. It visualizes architecture with ASCII diagrams, highlights unknowns, and suggests focused spikes to validate assumptions.

Explore mode does allow creating OpenSpec proposals and design specs because capturing thinking artifacts is permitted. You can generate proposals, designs, and specs to document your exploration, but you must exit explore mode to perform any actual code edits or feature implementations.

You should not use explore mode for problem-solving when you need to write code, edit files, or implement features. It is a stance for thinking and visualizing, not executing; if a task requires direct code changes, you must exit explore mode first and create a change proposal.

Explore mode enforces guardrails against code edits during requirements validation to keep thinking artifacts separate from implementation work. This ensures architecture reviews and brainstorming sessions remain focused on surfacing risks and clarifying problems without prematurely committing to code changes.