---
name: openspec-bridge-explore
description: Bridges OpenSpec's own /opsx:explore into the GSD entry point — use before /gsd-discuss-phase when the user has an idea but no OpenSpec change yet. Does not replace OpenSpec's explore skill; it just makes sure exploration output lands where GSD's discuss:pre check will find it.
allowed-tools: Bash, Read
license: MIT
metadata:
  author: openspec-gsd-integration
  version: "0.1.0"
---

## Purpose

`/opsx:explore` (OpenSpec's own skill) is already the right no-stakes thinking partner for a fuzzy idea. This skill's only job is to make sure that when exploration crystallizes into something worth building, the user is pointed at `/opsx:propose` — and, once a change exists, that GSD's `discuss:pre` fragment can find it (see `openspec-propose`'s output contract). This skill contributes no new exploration logic; it is a thin dispatcher plus a phase-scope reminder.

## Invocation conditions

- User says something like "I want to build X but haven't scoped it" before running `/gsd-discuss-phase`.
- `discuss:pre` told the user no change is linked and they chose to explore rather than propose directly.

## Required inputs

- Freeform user description of the idea (same as native `/opsx:explore`).
- Optionally, a GSD phase number if the exploration is meant to seed a specific `ROADMAP.md` phase.

## Files read

- `ROADMAP.md` phase goal (if a phase number is given) — to keep exploration scoped to that phase's boundary, not the whole project.

## Files this skill may write

- None directly. All artifact writing happens in `/opsx:propose` (native OpenSpec skill) once exploration concludes.

## Algorithm

1. If a phase number was given, read that phase's goal from `.planning/ROADMAP.md` and state it back to the user as the exploration's boundary ("exploring within Phase 4: Observability — not a general architecture review").
2. Delegate to the native `/opsx:explore` conversation — this skill does not reimplement codebase-reading or option-weighing; that is OpenSpec's job and it already does it well.
3. When the user signals readiness ("let's do it", "yes", a concrete decision), remind them of the next real command: `/opsx:propose <change-id>` (or `/opsx:ff <change-id>` / `/opsx:continue` if the expanded workflow profile is enabled) — do not auto-invoke it; proposing is a deliberate, confirmed step.

## Outputs

None (conversation only). The eventual proposal is OpenSpec's own artifact, produced by its own skill.

## Failure states

- None specific to this skill — any failure belongs to native `/opsx:explore` and should surface as-is.

## Guardrails

- Never writes `proposal.md`, `specs/`, or any OpenSpec artifact itself — that would duplicate `/opsx:propose`'s job and risk producing two divergent drafts.
- Never tells the user a change exists when it doesn't.

## Idempotency

Pure conversation, no state — safe to invoke any number of times.

## Example

```
User: I want dark mode but I'm not sure how to do it cleanly, and this should land in Phase 4.
[openspec-bridge-explore] Phase 4 goal: "Observability & theming polish". Scoping exploration to that.
AI: Let me look at your styling setup... [reads code, weighs options]
User: Yes, CSS variables + system-preference detection.
[openspec-bridge-explore] Ready when you are — run /opsx:propose add-dark-mode to turn this into a change.
```