openspec-intake

Normalizes vague customer requests into structured Intake Briefs for OpenSpec workflows.

Updated Jun 26, 2026
One-click install
npx skills add https://github.com/pavelvdo/universal-xml-exchange2 --skill openspec-intake-pavelvdo
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: openspec-intake
Source: https://github.com/pavelvdo/universal-xml-exchange2/tree/main/.cursor/skills/openspec-intake
Command: npx skills add https://github.com/pavelvdo/universal-xml-exchange2 --skill openspec-intake-pavelvdo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Raw customer requests arrive as noisy mixes of chat logs, screenshots, workarounds, and wishes. This Skill turns that noise into a verifiable Intake Brief with facts, hypotheses, scope boundaries, and open questions before any code investigation begins. ## Core Features & Use Cases - Input Classification: Routes incoming material as intake, debug (traces/stacks), explore (code investigation), or change requests, with automatic handoff to the right OpenSpec command. - Clarification Loop: Runs a Readiness Check and asks up to 3 targeted questions per iteration (max 3 iterations) until the brief meets quality criteria or the user fixes it as-is. - Structured Intake Brief: Separates verified facts, hypotheses, and noise; defines current/target scenarios, scope boundaries, technical context, and open questions split by resolvable-next and stakeholder-only. - Use Case: A customer sends a long email with screenshots asking to "improve the invoice form". The Skill classifies the input, clarifies the goal and scope through questions, then produces a brief and hands off to /opsx:explore or /opsx:new. ## Quick Start Paste the raw customer request or notes into the chat and ask the assistant to run the openspec-intake skill to produce an Intake Brief.

Frequently Asked Questions about openspec-intake

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

FAQPage Schema
How do I turn a vague customer request into a structured requirements brief?

Feed the raw customer text, screenshots, or notes to the intake skill. It classifies the input, runs a readiness check, asks up to 3 clarifying questions per iteration, and outputs an Intake Brief with facts, hypotheses, scenarios, scope, and open questions.

What is the difference between /opsx:intake, /opsx:explore, and /opsx:new?

Intake normalizes noisy customer wording into a brief without reading code. Explore investigates code and architecture to answer technical questions. New creates a formal change request (ZNИ) with full artifacts once scope and goals are clear.

Does the intake skill read source code or trace files?

No. Intake never reads BSL code, XML metadata, traces, or change artifacts. When a trace or stack is present, it immediately hands off to /opsx:debug or /opsx:explore with a trace-brief instead of analyzing the file itself.

When should I skip intake and go straight to creating a change request?

Even when the user asks to create a change directly, intake first produces an Intake Brief, then recommends /opsx:ff or /opsx:new. Skipping the brief entirely is not part of the protocol.

What happens if the customer cannot answer all clarifying questions?

After 3 clarification iterations, or when the user says "fix as is", the skill builds the brief from current state. Remaining gaps are recorded as open questions for the next step or for the stakeholder, not left as unresolved loops.