openspec-explore

Explore ideas and clarify requirements using ASCII diagrams and OpenSpec artifacts.

147|28|Updated Apr 24, 2026
One-click install
npx skills add https://github.com/linaproai/linapro --skill openspec-explore-linaproai
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: openspec-explore
Source: https://github.com/linaproai/linapro/tree/main/.agents/skills/openspec-explore
Command: npx skills add https://github.com/linaproai/linapro --skill openspec-explore-linaproai

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Teams often rush into implementation before fully understanding the problem, exploring all options, or clarifying requirements, leading to costly rework and misalignment. This Skill provides a dedicated thinking space to avoid that pitfall.

Core Features & Use Cases

  • Non-prescriptive thinking partner: Adapts to your line of questioning, explores multiple directions instead of following a rigid script, and grounds discussions in your actual codebase when relevant.
  • Visual problem exploration: Uses ASCII diagrams to map architecture, state flows, option tradeoffs, and system relationships to make abstract ideas concrete.
  • OpenSpec integration: References existing change proposals, designs, and specs when relevant, and offers to capture new insights into the appropriate OpenSpec artifact when decisions are finalized.
  • Use Case: For example, if your team is considering adding real-time collaboration, this Skill helps you map the collaboration spectrum (from presence awareness to CRDT-based sync), evaluate tradeoffs for your specific use case, and ground the discussion in your existing codebase before creating a formal change proposal.

Quick Start

Use the openspec-explore skill to think through our plan to add user notification features, investigate the current notification system in the codebase, and compare push vs in-app notification options before we start building.

Frequently Asked Questions about openspec-explore

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

FAQPage Schema
How do I clarify software requirements before starting implementation?

To clarify software requirements before implementation, use a non-prescriptive thinking partner to explore ideas, investigate problems, and map technical options. This reduces rework and misalignment by grounding discussions in your actual codebase before building begins.

What is spec-driven development and when do I need to explore technical options?

Spec-driven development requires exploring technical options and capturing decisions in formal specification documents before coding. You need this process when feature ideation or codebase investigation involves complex tradeoffs that require alignment to prevent costly rework.

How do I investigate a codebase to compare technical design options for a new feature?

You can investigate a codebase and compare technical design options by mapping architecture and state flows with ASCII diagrams. This visual problem exploration makes abstract ideas concrete and evaluates tradeoffs against existing project context before finalizing decisions.

Can I use ASCII diagrams to map architecture and state flows during requirement exploration?

Yes, you can use ASCII diagrams to map architecture, state flows, option tradeoffs, and system relationships during requirement exploration. This visual problem exploration approach makes abstract technical design concepts concrete and easier to evaluate.

How do I capture finalized decisions from requirement clarification into formal specification documents?

You capture finalized decisions from requirement clarification into formal specification documents through OpenSpec integration. After exploring ideas and comparing options, insights are recorded into the appropriate OpenSpec change artifact when decisions are finalized.

What are the limitations of using a non-prescriptive thinking partner for software technical design?

A non-prescriptive thinking partner for software technical design adapts to your questioning rather than following a rigid script, meaning it explores multiple directions without enforcing a specific workflow. It focuses on requirement clarification rather than generating actual implementation code.