dev:explore

Compatibility: If AskUserQuestion is unavailable, present options as a numbered list and wait for the user's reply. If Task is unavailable, run parallel steps sequentially. The context: fork and agent: frontmatter fields are Claude Code-specific — on OpenCode and VS Code Copilot they are ignored and the skill runs inline using the current model.

Explore a technical problem by running research, identifying distinct approaches, and generating parallel proposals. Output lives in .codevoyant/explore/[name]/ so it can feed into /spec:new later.

Guiding Principles

These principles govern every dev:explore run. Research agents and proposal writers must both conform.

• Ecosystem-first — before proposing any solution, exhaustively survey what libraries, frameworks, and tools already exist. A good existing library beats a custom implementation almost every time. Only recommend from-scratch if no viable option exists or existing options have disqualifying trade-offs.
• No confabulation — every library claim, API shape, configuration option, or integration detail must come from reading actual documentation or source code. Do not describe an API you haven't read. If the docs weren't fetched, the claim doesn't belong in the proposal.
• Sufficient implementation detail — proposals must show how a solution actually comes together: what files get added or modified, what the integration boundary looks like, what key interfaces are involved. A reader should be able to understand the shape of the implementation without having to re-research everything.
• Prior art is mandatory — research must include how similar problems are solved in the existing codebase and in analogous open-source projects. Reinventing what already exists locally or in the ecosystem is a failure mode.
• Fetch, don't summarize from memory — researchers must fetch GitHub repos, README files, and documentation pages. A researcher that cites a library without fetching its docs is producing unreliable output.
• Skills lookup is part of research — check https://skills.sh/ and local .claude/skills/ before proposing any tooling or workflow. An existing skill may already solve part of the problem.
• Mermaid for all diagrams — any system diagram, architecture diagram, data flow, timeline, or process flow in proposals or research must be written as a Mermaid diagram (```mermaid block). Never use ASCII art for structured diagrams.

Step 0: Parse Arguments

Parse from: $ARGS (the full argument string passed to this skill).