specification-techniques

Name: specification-techniques
Availability: InStock
Author: enigmaicon-eng

Convert product vision into structured PRDs, user stories, and acceptance criteria.

1|Updated May 16, 2026

Search Tags:#edge cases #acceptance criteria #user stories #prd #product requirements #non-functional requirements #jobs to be done

Ready to run

npx skills add https://github.com/enigmaicon-eng/AI-Enterprise-OS --skill specification-techniques-enigmaicon-eng

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: specification-techniques
Source: https://github.com/enigmaicon-eng/AI-Enterprise-OS/tree/main/agents/plugins/ai-pm-copilot/skills/specification-techniques
Command: npx skills add https://github.com/enigmaicon-eng/AI-Enterprise-OS --skill specification-techniques-enigmaicon-eng

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) and assets (resource) components.

What problem does it solve?

This Skill prevents ambiguity and misalignment in product work by helping you translate product intent into clear, complete, and testable requirements that teams can execute with confidence.

Core Features & Use Cases

Write high-quality PRDs: Create structured product requirements including goals, non-goals, personas, requirements, UX, technical considerations, success criteria, and resourcing.
Craft strong user stories: Use trusted formats (e.g., INVEST, 3Cs, Given-When-Then) to ensure stories are valuable, negotiable, and testable.
Define acceptance criteria and edge cases: Produce behavior-driven “done” conditions using multiple formats (Given-When-Then, checklists, examples) and systematically cover unhappy paths and non-functional requirements.
Support product discovery and clarity: Use jobs-to-be-done and use case structures to capture context, motivation, and exception flows.

Quick Start

Tell the AI: "Help me write a PRD and user stories for the feature I described, including acceptance criteria in Given-When-Then format plus edge cases and non-functional requirements."

Frequently Asked Questions about specification-techniques

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

FAQPage Schema

How do I write user stories and acceptance criteria from a product idea?▼

To write user stories and acceptance criteria from a product idea, convert product vision into structured PRDs using INVEST and 3Cs formats, then define behavior-driven conditions using Given-When-Then checklists to ensure stories are testable.

What is the best way to document edge cases and non-functional requirements in a PRD?▼

The best way to document edge cases and non-functional requirements in a PRD is to systematically map happy and unhappy paths using jobs-to-be-done frameworks, capturing exception flows and technical constraints alongside standard feature definitions.

How do I structure a PRD so cross-functional teams can execute it without ambiguity?▼

To structure a PRD without ambiguity for cross-functional teams, include goals, non-goals, personas, UX considerations, technical constraints, success criteria, and resourcing, aligning API documentation with defined user stories.

When should I use Given-When-Then versus checklist formats for acceptance criteria?▼

Use Given-When-Then formats for acceptance criteria when defining complex behavior-driven paths, and use checklist or example-based formats when outlining simpler done conditions to ensure comprehensive edge-case coverage.

Does this approach to product specification work for API documentation alignment?▼

Yes, this product specification approach works for API documentation alignment by translating product intent into clear requirements and matching user stories with technical specs to prevent misalignment across cross-functional teams.

Why do my user stories fail INVEST principles when defining feature requirements?▼

User stories fail INVEST principles when they lack clear acceptance criteria, miss edge-case coverage, or fail to capture jobs-to-be-done context, making them non-negotiable or untestable for development teams.