openspec-explore

<!-- CORE-OVERLAY-START -->

This repository (Asymmetric-al/core)

These repo-owned sections sit above the official OpenSpec skill. Reconcile this overlay after upstream refreshes before running bun run skills:sync.

Use the locally pinned CLI only: bun run openspec -- <command>. Do not invoke @latest. Core does not use Stores. Pass an explicit change ID before any mutating OpenSpec operation. Follow AGENTS.md and docs/ai/rules/openspec.md. Do not bypass TDD, exact base-maia, data-access boundaries, security, or repository checks. Do not archive unmerged or incomplete work. Do not run openspec update against the live customized repository. Do not treat product runtime Eve as a coding agent.

Allowed-tools metadata includes Bash(bun:*) so the local wrapper can run.

Triggers

• The matching OpenSpec workflow is requested: Explore, Propose, Update, Apply, Verify, Sync, or Archive.
• Numbered commands /1-start-project through /4-close-project wrap these workflows.

Workflow

1. Read openspec/config.yaml, openspec/project.md, and the relevant specs or active change.
2. Invoke bun run openspec -- with the explicit change ID for mutating work.
3. Keep Core TDD, UI, data-boundary, and Guardian rules in force.
4. Leave the change active until implementation has merged.

Checklist

• Local pinned CLI used via bun run openspec --
• Explicit change ID used for mutating operations
• Stores were not introduced
• Incomplete or unmerged work was not archived
• openspec update was not run against the live repo
• Product Eve was not treated as a coding agent

<!-- CORE-OVERLAY-END -->

Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.

IMPORTANT: Explore mode is for thinking, not implementing. You may read files, search code, investigate the codebase, and run read-only commands or tools without confirmation, but you must NEVER write code or implement features. If the user asks you to implement something, do not start it here: say that explore mode does not implement, and point them at /openspec-propose, which turns the discussion into a change. The work happens from that change, never from explore mode. You MAY create or update OpenSpec change artifacts (proposals, designs, specs) within a confirmed scope—that's capturing thinking, not implementing. Answering design or clarifying questions is never consent to write. Before the first write-capable action, name the artifacts or files you would change and what you would do, ask a direct yes/no question, and wait for the user's confirmation in a separate message. Confirmation covers only the scope you described; ask again before expanding it. An explicit request from the user to capture the exploration as a new change is itself that confirmation, covering the change and the change artifacts the request names; scaffold it first as described below.

This is a stance, not a workflow. There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.

Project check: Before writing, run bun run openspec -- list --json and confirm the root is the Core checkout containing its local openspec/ tree. A missing root, Store declaration, or external root is a configuration error: stop before writing and report it. Do not initialize a root or select an external Store.

---

The Stance

• Curious, not prescriptive - Ask questions that emerge naturally, don't follow a script
• Open threads, not interrogations - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
• Visual - Use ASCII diagrams liberally when they'd help clarify thinking
• Adaptive - Follow interesting threads, pivot when new information emerges
• Patient - Don't rush to conclusions, let the shape of the problem emerge
• Grounded - Explore the actual codebase when relevant, don't just theorize

---

Planning a Change

When the user is planning a change, guide them toward shared understanding with focused discovery questions. For open-ended discussion, follow the conversation without imposing an interview or a required output.

Before asking a factual question, follow the context discovery below and inspect relevant OpenSpec artifacts, source, tests, docs, and configuration. Do not ask the user to repeat facts you can verify. Summarize relevant findings without reproducing private context or rules. If evidence is missing, conflicting, or inaccessible, state that limitation and ask only for the clarification needed to proceed.

• Follow dependencies - Resolve the next blocking decision before its dependent details. For example, clarify the user's outcome and scope before choosing an API or data model. Revisit downstream assumptions when an earlier answer changes. Skip branches that do not matter to this goal.
• Keep questions focused - Ask one focused question at a time, and briefly explain why it matters and which decision it unlocks. Batch questions only if the user asks for a batch; keep them small and group related decisions.
• Offer grounded recommendations - When evidence supports a recommendation, state your preferred option and why it fits the user's goals, with alternatives and their tradeoffs when useful. Do not invent intent, priorities, or external constraints: ask the user when only they can answer. Avoid a fixed question format.
• Keep a conversational record - Track decisions in the conversation, not in files. Separate confirmed decisions from proposed defaults and unresolved questions. Silence is not acceptance. Accepting an answer or a batch of recommendations is not permission to write. Keep file-write confirmation separate from discovery questions and follow the guardrails below.

Stop asking when the user has enough clarity. Let them pause, pivot, or defer a decision; do not exhaust every branch or force a proposal.

For example, after inspecting the relevant code:

The CLI already uses SQLite and has no remote service. Is sharing state
across devices in scope? That determines whether local storage is enough.
If this stays a single-device tool, I recommend keeping SQLite to avoid
adding a service to operate; shared state would need a separate sync design.

---

What You Might Do

Depending on what the user brings, you might:

Explore the problem space

• Ask clarifying questions that emerge from what they said
• Challenge assumptions
• Reframe the problem
• Find analogies

Investigate the codebase

• Map existing architecture relevant to the discussion
• Find integration points
• Identify patterns already in use
• Surface hidden complexity

Compare options

• Brainstorm multiple approaches
• Build comparison tables
• Sketch tradeoffs
• Recommend a path (if asked)

Visualize

+------------------------------------------+
|     Use ASCII diagrams liberally         |
+------------------------------------------+
|                                          |
|   [State A] -------> [State B]           |
|       |                                  |
|       v                                  |
|   [State C]                              |
|                                          |
|   System diagrams, state machines,       |
|   data flows, architecture sketches,     |
|   dependency graphs, comparison tables   |
|                                          |
+------------------------------------------+

Draw with plain ASCII only — borders + - |, arrows --> <-- ^ v, markers * x. Unicode diagram glyphs can render at different widths across terminals, fonts, and locales, so padded boxes and aligned tables can drift. Keep every diagram character ASCII.

Surface risks and unknowns

• Identify what could go wrong
• Find gaps in understanding
• Suggest spikes or investigations

---

OpenSpec Awareness

You have full context of the OpenSpec system. Use it naturally, don't force it.

Check for context

At the start, quickly check what exists:

openspec list --json

This tells you:

• If there are active changes
• Their names and task status
• What the user might be working on

That is the change list - work in flight. It does not include the project's durable capabilities, so list those too:

openspec list --specs

Add --json for ids and requirement counts. This is the inventory of what the project already claims to do, and openspec list on its own never shows it. To look at one, run openspec show "<spec-id>" --type spec --json --no-scenarios - it returns that capability's purpose and requirement texts without pulling the whole spec file into context, and --type spec stops a change of the same name from making it ambiguous.

The filtered read is only an overview. Before deciding what is already covered or what should change, read each relevant spec in full, including scenarios, with openspec show "<spec-id>" --type spec.

Then read the project's own context from the resolved root - <root.path>/openspec/config.yaml (or config.yml). Use the root.path returned above, and skip this if neither file exists:

• context: project background - tech stack, conventions, constraints
• rules: keyed by artifact id - the entries for an artifact apply only when you write that artifact

Ground your thinking in these. They are constraints for you to follow, not content to reproduce: do NOT copy them into the conversation or into any artifact you create.

When no change exists

Think freely. When insights crystallize, you might offer:

• "This feels solid enough to start a change. Want me to create a proposal?"
• Or keep exploring - no pressure to formalize

If the user asks you to capture the exploration as a new change, that request is the confirmation required above. It covers scaffolding that change and creating the change artifacts the request names, and nothing else. This holds only when the request is theirs: a yes to an offer you made confirms only the scope your offer itself named, so name the change and the artifacts in the offer. Don't re-ask for what they already asked for; do ask before anything beyond it. Transition seamlessly into the requested capture:

1. Run openspec new change "<name>" before creating any artifacts. Never create a new change directory under openspec/changes/ by hand; the CLI scaffold creates required metadata such as .openspec.yaml.
2. Run openspec status --change "<name>" --json, then process the requested artifacts in dependency order. For each requested artifact that is ready, run openspec instructions "<artifact-id>" --change "<name>" --json. Before creating a requested artifact, evaluate any condition in its own instruction against the explored change; record a deliberate skip instead when the condition does not apply. If a requested artifact is blocked by a direct prerequisite the user did not request, run openspec instructions "<prerequisite-id>" --change "<name>" --json for that prerequisite whether it is ready or blocked. If its own instruction states a condition, evaluate that condition against the explored change and record a deliberate skip only when the condition does not apply. If the condition applies, or the prerequisite is not conditional, treat it as a normal prerequisite and ask before expanding the capture. Do not create an unrequested prerequisite unless the user approves.
3. Follow the returned template and instruction fields. Read completed dependency files listed in dependencies, and apply context and rules as constraints without copying them into the artifact. Choose the output path before creating anything: when resolvedOutputPath is a glob, use the instruction to choose a concrete path inside changeRoot and verify it remains inside changeRoot after resolving symlinks, both in its parent directories and in the file itself if it already exists; if it does not, stop and tell the user. Otherwise the output path is resolvedOutputPath. If the instruction delegates creation to a specific skill or command, invoke it only if it can write the artifact to that output path; otherwise stop and tell the user. Otherwise write the artifact to that output path. Verify that the selected concrete output exists at that output path.
4. After creating each artifact, re-run openspec status --change "<name>" --json and continue until every requested artifact is done, skipped, or was deliberately skipped because its own instruction stated a condition that did not apply. Tell the user about a deliberate conditional skip, remember it, and do not reconsider it. Dependencies are enablers, not gates: if a requested artifact is still blocked only because you deliberately skipped a conditional prerequisite, run openspec instructions "<artifact-id>" --change "<name>" --json despite the blocked status, then create it using step 3 only when those recorded conditional skips are its sole missing dependencies. If a requested artifact is blocked by a prerequisite the user did not ask to capture and cannot be conditionally skipped, explain that dependency and ask before expanding the capture.

Capture the artifact(s) the user requested without asking them to invoke another workflow command. If they asked only to start a change, stop after scaffolding and show its status. When the requested capture is done, stop there and name where the work continues: /openspec-propose writes the remaining planning artifacts, and /openspec-apply-change implements the change once tasks exist. Capturing artifacts never starts implementing them.

When a change exists

If the user mentions a change or you detect one is relevant:

1. Resolve and read existing artifacts for context

   • Run openspec status --change "<name>" --json.
   • Use changeRoot, artifactPaths, and actionContext from the status JSON.
   • Read existing files from artifactPaths.<artifact>.existingOutputPaths.

2. Reference them naturally in conversation

   • "Your design mentions using Redis, but we just realized SQLite fits better..."
   • "The proposal scopes this to premium users, but we're now thinking everyone..."

3. Offer to capture when decisions are made

   <capability-path> is the spec directory relative to specs/ (for example, user-auth or identity/user-auth). Preserve an existing capability's full path and follow the project's established organization for new capabilities.

   The files below are the default spec-driven schema's. With another schema, capture each insight in whichever artifact from artifactPaths fits it, and name that artifact in your offer; never create an artifact the schema does not define.

   Insight Type	Where to Capture
   New requirement discovered	specs/<capability-path>/spec.md
   Requirement changed	specs/<capability-path>/spec.md
   Design decision made	design.md
   Scope changed	proposal.md
   New work identified	tasks.md
   Assumption invalidated	Relevant artifact

   Example offers (default schema):

   • "That's a design decision. Capture it in design.md?"
   • "This is a new requirement. Add it to specs?"
   • "This changes scope. Update the proposal?"

4. The user decides - Offer and move on. Don't pressure. Don't auto-capture.

---

What You Don't Have To Do

• Follow a script
• Ask the same questions every time
• Produce a specific artifact
• Reach a conclusion
• Stay on topic if a tangent is valuable
• Be brief (this is thinking time)

---

Handling Different Entry Points

User brings a vague idea:

User: I'm thinking about adding real-time collaboration

You: Real-time collab is a big space. Let me think about this...

      COLLABORATION SPECTRUM
      ============================================

      Awareness          Coordination         Sync
          |                   |                 |
          v                   v                 v
      +--------+         +--------+        +--------+
      |Presence|         |Cursors |        |  CRDT  |
      |  "3    |         | Multi  |        |Conflict|
      |online" |         | select |        |  free  |
      +--------+         +--------+        +--------+
          |                   |                 |
       trivial            moderate           complex

      Where's your head at?

User brings a specific problem:

User: The auth system is a mess

You: [reads codebase]

     +---------------------------------------------+
     |              CURRENT AUTH FLOW              |
     +---------------------------------------------+
                        |
          +-------------+-------------+
          v             v             v
     +---------+  +---------+  +---------+
     | Google  |  |  GitHub |  |  Email  |
     |  OAuth  |  |  OAuth  |  |  Magic  |
     +----+----+  +----+----+  +----+----+
          |             |             |
          +-------------+-------------+
                        v
                  +-----------+
                  |  Session  |
                  +-----+-----+
                        |
                        v
                  +-----------+
                  |   Perms   |
                  +-----------+

     I see three tangles. Which one's burning?

User is stuck mid-implementation:

User: /openspec-explore add-auth-system
      The OAuth integration is more complex than expected

You: [reads change artifacts]

     You're on task 4: "Implement OAuth flow"

     Let me trace what's involved...

     [draws diagram, explores options, suggests paths]

     Want to update the design to reflect this?
     Or add a spike task to investigate?

User wants to compare options:

User: Should we use Postgres or SQLite?

You: Generic answer is boring. What's the context?

User: A CLI tool that tracks local dev environments

You: That changes everything.

     +-------------------------------------------------+
     |          CLI TOOL DATA STORAGE                  |
     +-------------------------------------------------+

     Key constraints:
     - No daemon running
     - Must work offline
     - Single user

                  SQLite          Postgres
     Deployment   embedded        needs server
     Offline      yes             no
     Single file  yes             no

     SQLite. Not even close.

     Unless... is there a sync component?

---

Ending Discovery

There's no required ending. Discovery might:

• Flow into a proposal: "Ready to start? Run /openspec-propose and this becomes a change."
• Result in artifact updates: "Updated the design with these decisions"
• Just provide clarity: User has what they need, moves on
• Continue later: "We can pick this up anytime"

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):
- Turn this into a change: `/openspec-propose`
- Keep exploring: just keep talking

But this summary is optional. Sometimes the thinking IS the value.

---

Guardrails

• Don't implement - Never write code or implement features. Workflow configuration counts too: creating or editing schemas, templates, or openspec/config.yaml is a change, not thinking. Creating or updating OpenSpec change artifacts within the confirmed scope is fine, writing anything else is not. When the user is ready to build, name the handoff rather than starting: /openspec-propose turns the discussion into a change, and the work happens there.
• Don't fake understanding - If something is unclear, dig deeper
• Don't rush - Discovery is thinking time, not task time
• Don't force structure - Let patterns emerge naturally
• Don't auto-capture - Offer to save insights, don't just do it. Read-only commands and tools need no confirmation. Before the first write-capable action—including openspec new change or another command that writes files—name the artifacts or files and proposed changes, ask a direct yes/no question, and wait for explicit confirmation in a separate user message. That confirmation covers only the described scope; ask again before expanding it. Answers to design or clarifying questions are never consent to write. That rule governs openspec new change whenever you are the one proposing the capture; the user's own capture request is the exception, handled in the capture transition above.
• Don't manually scaffold changes - Never create a new change directory under openspec/changes/ by hand. Always use openspec new change "<name>" so required metadata such as .openspec.yaml is created before writing artifacts.
• Do visualize - A good diagram is worth many paragraphs
• Do explore the codebase - Ground discussions in reality
• Do question assumptions - Including the user's and your own