skills.rest
Yoodaddy0311
Yoodaddy0311COMMUNITY
Explore all skills by this author →
GitHub

spec-format

Writes structured requirements and acceptance criteria using EARS templates and Given-When-Then format.

3|2|Updated Feb 13, 2026
Search Tags:#specification#requirements#acceptance criteria#prioritization#ears#user story#given-when-then
One-click install
npx skills add https://github.com/Yoodaddy0311/artibot --skill spec-format-yoodaddy0311
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: spec-format
Source: https://github.com/Yoodaddy0311/artibot/tree/main/plugins/artibot/skills/spec-format
Command: npx skills add https://github.com/Yoodaddy0311/artibot --skill spec-format-yoodaddy0311

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Ambiguous natural-language requirements cause rework, scope creep, and disputes over whether a feature is done. This Skill converts business needs into unambiguous, testable specifications using the EARS syntax and Given-When-Then acceptance criteria. ## Core Features & Use Cases - EARS Requirement Templates: Five patterns (Ubiquitous, Event-Driven, State-Driven, Optional, Unwanted) plus combined forms for writing precise, testable requirement statements. - Acceptance Criteria & Spec Template: Given-When-Then criteria format and a full technical specification template covering functional/non-functional requirements, design, constraints, and out-of-scope items. - Quality Gates & Prioritization: A six-attribute quality checklist (atomic, testable, unambiguous, complete, consistent, traceable) and P0-P3 priority classification with stakeholder checkpoints. - Use Case: When a product manager hands you a vague ticket like "users should log in securely", use this Skill to produce EARS requirements, Given-When-Then acceptance criteria for happy and error paths, and a prioritized spec ready for stakeholder sign-off. ## Quick Start Ask the agent to write a SPEC for your feature using EARS requirements and Given-When-Then acceptance criteria with P0-P3 priorities.

Frequently Asked Questions about spec-format

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

FAQPage Schema
How do I write testable software requirements with EARS?▼

EARS provides five sentence patterns: Ubiquitous (The system shall...), Event-Driven (When...), State-Driven (While...), Optional (Where...), and Negative (If...). Each pattern produces a single unambiguous statement that can be verified with a pass/fail test.

How to write acceptance criteria in Given-When-Then format?▼

State the precondition after GIVEN, the triggering action after WHEN, and the expected outcome after THEN, adding AND clauses for extra outcomes. Write at least one block for the happy path and one for each known error path before implementation starts.

When should I not use EARS requirements format?▼

Skip EARS for quick exploratory spikes, one-line fixes, or when stakeholders explicitly want to prototype first and specify later. The overhead exceeds its value for tasks under roughly 30 minutes of implementation.

What makes a software requirement high quality?▼

A quality requirement is atomic, testable, unambiguous, complete, consistent, and traceable to its source. Avoid vague words like fast or easy, compound statements mixing and/or, and requirements written after implementation is merged.

How do I prioritize requirements with P0-P3 classification?▼

P0 means the system cannot function without it, P1 covers core user journeys, P2 significantly improves experience, and P3 is a deferrable enhancement. Priority decisions require stakeholder agreement and documented rationale.

Related Skills

Explore More Product & Management Skills→
magnus919magnus919
40

product-discovery

Map stakeholders, conduct interviews, and distill requirements into formal specifications.

Community
Advanced
insentekinsentek
1

vapa-exec

Orchestrate approved software proposals with multi-agent task decomposition and audit gates.

Official
Advanced
udecodeudecode
16.5k

feasibility-reviewer

Evaluates technical plans for architecture conflicts, dependency gaps, and implementability risks.

Official
Intermediate
yanochka11yanochka11

spike

Validate uncertain technical approaches through focused disposable experiments.

Community
Advanced