Verified:GitHub

spec-workflow

Transform ambiguous change requests into requirements, design, and execution plans.

Updated May 14, 2026

Search Tags:#architecture #specification #requirements #project planning #acceptance criteria #task decomposition #cross-module

Ready to run

npx skills add https://github.com/williamwang25/ams-admin --skill spec-workflow-williamwang25

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: spec-workflow
Source: https://github.com/williamwang25/ams-admin/tree/main/.windsurf/skills/cloudbase/references/spec-workflow
Command: npx skills add https://github.com/williamwang25/ams-admin --skill spec-workflow-williamwang25

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It prevents wasted engineering effort by forcing medium-to-large changes to clarify requirements, confirm design decisions, and produce a reviewable task plan before implementation.

Core Features & Use Cases

Phase-based spec creation: Produces requirements, design, and tasks as separate artifacts (requirements → design → tasks → execution).
EARS acceptance criteria: Converts vague expectations into testable “EARS-style” criteria to reduce back-and-forth.
Traceable execution: Links tasks back to requirements and enforces confirmation between phases to maintain alignment.
Cross-module/architecture coordination: Helps when multiple files, user flows, database changes, or UI decisions require staged agreement.

Quick Start

Use the spec workflow to generate a new specs/<spec_name>/requirements.md, then ask for confirmation before writing design and tasks.

Frequently Asked Questions about spec-workflow

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

FAQPage Schema

How do I turn ambiguous product requests into actionable development plans?▼

To turn ambiguous product requests into actionable development plans, you can use a staged specification process that generates separate requirements, design, and task artifacts. This enforces user confirmation before implementation to prevent wasted engineering effort.

How do I write testable acceptance criteria for vague engineering changes?▼

Writing testable acceptance criteria for vague engineering changes involves converting expectations into EARS-style statements. This structured format reduces back-and-forth by making cross-module integration and database requirements explicitly verifiable before design begins.

What is the best way to plan cross-module architecture updates with uncertain scope?▼

The best way to plan cross-module architecture updates with uncertain scope is using a phase-based specification workflow. It produces traceable tasks linked back to requirements, ensuring staged agreement across multiple files, database changes, and UI decisions.

Does this specification workflow work for medium to large multi-step project planning?▼

Yes, this specification workflow works specifically for medium-to-large, multi-step project planning. It is designed for updates requiring cross-module integration, database and UI-heavy work, and architecture tasks where acceptance criteria are initially uncertain.

How do I decompose complex requirements into traceable execution tasks?▼

To decompose complex requirements into traceable execution tasks, generate a design artifact first, then produce a tasks file. This workflow links every task back to original requirements and enforces phase transitions to maintain alignment during execution.

Why should I use a staged specification process before starting implementation?▼

You should use a staged specification process before implementation to clarify requirements, confirm design decisions, and produce a reviewable task plan. This prevents wasted engineering effort on multi-step updates with uncertain acceptance criteria.