spec-writer

Convert feature ideas into structured .spec.md specifications with REQ IDs and Given/When/Then criteria.

Updated May 9, 2026
One-click install
npx skills add https://github.com/GustavoGutierrez/engineering-skills --skill spec-writer-gustavogutierrez
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: spec-writer
Source: https://github.com/GustavoGutierrez/engineering-skills/tree/main/skills/spec-writer
Command: npx skills add https://github.com/GustavoGutierrez/engineering-skills --skill spec-writer-gustavogutierrez

SYSTEM DOCUMENTATION & REQUIREMENTS

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

What problem does it solve?

It eliminates ambiguity in feature requests by converting informal ideas into a clear, testable specification that an AI agent or engineering team can implement with confidence.

Core Features & Use Cases

  • Behavior-based spec writing: Produces a bounded, verifiable specification that separates intent from implementation detail.
  • Traceable, testable requirements: Generates stable REQ IDs with Given/When/Then acceptance criteria for main flows and edge cases.
  • Safety guardrails and scope control: Adds Always allowed / Ask before / Never do plus explicit in-scope and out-of-scope boundaries to prevent unsafe or off-target changes.

Quick Start

Ask the AI to spec out your feature by providing the goal and key constraints, and request an implementation-ready spec in a .spec.md format.

Frequently Asked Questions about spec-writer

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

FAQPage Schema
How do I write a specification with acceptance criteria for agent-driven development?

To write a specification for agent-driven development, you convert informal feature ideas into a structured .spec.md file containing stable REQ IDs and Given/When/Then acceptance criteria for main flows and edge cases.

What is the best way to define scope boundaries and guardrails before coding a feature?

Defining scope boundaries and guardrails involves creating a bounded specification that explicitly separates in-scope and out-of-scope elements, while adding Always allowed, Ask before, and Never do sections to prevent unsafe changes.

How do I create a testable specification from a vague bug report?

Creating a testable specification from a bug report requires translating the observed behavior into an explicit verification plan with traceable requirements, ensuring the output defines a clear Definition of Done.

Can I use this specification format if some feature requirements are missing or unclear?

Yes, you can use this specification format with missing details because it accommodates ambiguity by automatically generating an open questions or assumptions section to clarify intent before implementation begins.

Does rewriting an imprecise specification require redefining all acceptance criteria?

Rewriting an imprecise specification does not require discarding existing acceptance criteria if they remain valid, but it does enforce standard Given/When/Then formats and stable REQ IDs to ensure traceability.

What limitations exist when converting informal ideas into a structured specification?

A limitation of converting informal ideas is that the resulting specification only captures explicitly stated intent and defined scope boundaries, meaning completely unstated assumptions might require manual clarification through open questions.