requirements-specification

Converts vague product ideas into implementable specifications with acceptance criteria and decision gates.

Updated Jun 8, 2026
One-click install
npx skills add https://github.com/vovanostm-public/multica --skill requirements-specification-vovanostm-public
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: requirements-specification
Source: https://github.com/vovanostm-public/multica/tree/main/workflow-bundles/multica-specops-v5/codex_skills/.agents/skills/requirements-specification
Command: npx skills add https://github.com/vovanostm-public/multica --skill requirements-specification-vovanostm-public

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Product requests often arrive as vague ideas or issues missing acceptance criteria, making them impossible to implement or estimate. This Skill transforms raw ideas, issues, and product requests into structured, implementable specifications with clear problem statements, goals, non-goals, and testable acceptance criteria. ## Core Features & Use Cases - Request Classification: Categorizes incoming work as idea, product task, bug, docs, or analysis before specification work begins. - Structured Spec Generation: Produces a problem statement, spec document, acceptance criteria, non-goals, and decision questions following a defined output contract. - Decision Gating: Escalates only critical product ambiguities as gated questions, preventing workflow stalls on optional clarifications. - Use Case: A product manager receives a one-line feature request in an issue tracker. The Skill classifies it, writes observable acceptance criteria, defines non-goals to prevent scope creep, and flags only the genuinely blocking product decisions. ## Quick Start Turn this vague feature request into an implementable product specification with acceptance criteria and non-goals.

Frequently Asked Questions about requirements-specification

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

FAQPage Schema
How do I turn a vague product idea into a specification?▼

Classify the request type first, then state the problem and user impact, define goals and non-goals, and write acceptance criteria as observable behavior. Critical ambiguities become decision-gated questions rather than blocking the workflow.

How to write testable acceptance criteria for product requirements?▼

Write acceptance criteria as observable behavior that can be verified, not as implementation details. If a criterion is not observable, rewrite it or escalate it as a product decision question.

What outputs does a requirements specification workflow produce?▼

It produces a problem statement, spec document, acceptance criteria, non-goals, and product decision questions. Every output includes used evidence, assumptions, blockers, confidence, and handoff information when applicable.

When should a product ambiguity block the specification workflow?▼

Only critical product ambiguities become decision-gated questions. Optional clarifications must not block the workflow, and scope conflicts are recorded as tradeoffs and gated only when critical.

What are the limitations of automated requirements specification?▼

It does not perform unrelated workflow stages, execute privileged actions directly, or overwrite evidence owned by other stages. Implementation details are converted to constraints or handed off to an architect role.