skills.rest
HermeticOrmus
HermeticOrmusCOMMUNITY
Explore all skills by this author →
Website𝕏@dbodartmGitHub

Spec Writing Patterns

Write testable technical specifications using Gherkin acceptance criteria and modal verbs.

Updated Feb 25, 2026
Search Tags:#testing#documentation#requirements#technical writing#specifications#gherkin
One-click install
npx skills add https://github.com/HermeticOrmus/LibreCopy-Claude-Code --skill spec-writing-patterns
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: Spec Writing Patterns
Source: https://github.com/HermeticOrmus/LibreCopy-Claude-Code/tree/main/plugins/specification-writing/skills/spec-writing-patterns
Command: npx skills add https://github.com/HermeticOrmus/LibreCopy-Claude-Code --skill spec-writing-patterns

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill helps technical writers and engineers create unambiguous, verifiable requirements and specifications, preventing costly misunderstandings and implementation errors.

Core Features & Use Cases

  • Testability: Ensures every requirement can be validated with a test case.
  • Clarity: Differentiates between mandatory ('shall'), recommended ('should'), and optional ('may') statements.
  • Structure: Provides templates for Gherkin acceptance criteria, interface contracts, and state machines.
  • Use Case: When defining a new user authentication feature, use this Skill's patterns to ensure requirements like "The system shall lock an account after 5 failed login attempts within 10 minutes" are precisely defined and testable.

Quick Start

Use the spec-writing-patterns skill to learn about the 'Shall vs. Should vs. May' pattern.

Frequently Asked Questions about Spec Writing Patterns

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

FAQPage Schema
How do I write testable technical specifications and requirements?▼

Testable technical specifications require verifiable criteria, using patterns like Gherkin acceptance tests and interface contracts to ensure each requirement can be validated and prevent implementation errors.

What is the difference between shall, should, and may in requirements writing?▼

In requirements writing, 'shall' indicates a mandatory specification, 'should' denotes a recommended statement, and 'may' defines an optional feature, establishing clear modal verb usage for technical documentation.

How do I use Gherkin acceptance criteria to structure software requirements?▼

Gherkin structures software requirements by defining acceptance criteria with a specific template, ensuring clear, testable scenarios that validate user authentication features and other technical use cases.

What are common anti-patterns in technical specification writing?▼

Common anti-patterns in technical specification writing involve ambiguous modal verbs, untestable requirements, and poorly defined state machine documentation, which lead to costly implementation errors and misunderstandings.

When do I need to document interface contracts and state machines in specifications?▼

You need interface contracts and state machines in specifications when defining complex system interactions, ensuring unambiguous technical requirements for feature behavior like account locking after failed login attempts.

Related Skills

Explore More Software Engineering Skills→
Cyber-SyntaxCyber-Syntax

prd

Generate production-ready PRDs conforming to the Strict PRD Schema.

Community
Basic
hmctshmcts
3

generate-bdd-specs

Converts acceptance criteria into Cucumber/Gherkin feature files with backgrounds and tags.

Official
Intermediate
saschadudkin-sketchsaschadudkin-sketch

domhub-product-spec-drift-audit

Audit DomHub product specifications against API contracts, backend services, and frontend code.

Community
Advanced
devalexanderdazadevalexanderdaza

bmad-create-epics-and-stories

Transform product requirement documents into structured epics and user stories.

Community
Advanced