moai-workflow-spec

Creates EARS-format SPEC documents with acceptance criteria for Plan-Run-Sync workflows.

Updated Jun 18, 2026
One-click install
npx skills add https://github.com/h102-log/pdfrag --skill moai-workflow-spec-h102-log
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: moai-workflow-spec
Source: https://github.com/h102-log/pdfrag/tree/main/.claude/skills/moai-workflow-spec
Command: npx skills add https://github.com/h102-log/pdfrag --skill moai-workflow-spec-h102-log

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Writing unambiguous, testable feature requirements is hard—vague specs cause scope creep, implementation drift, and untestable acceptance criteria. This Skill orchestrates the SPEC planning phase of the MoAI-ADK methodology, converting natural-language feature requests into structured EARS-format specifications. ## Core Features & Use Cases - EARS Requirement Patterns: Structures requirements using five patterns (Ubiquitous, Event-Driven, State-Driven, Unwanted, Optional) to eliminate ambiguity. - Standardized SPEC Documents: Generates the required 3-file structure (spec.md, plan.md, acceptance.md) with metadata schema, lifecycle levels, and quality validation checklists. - Plan-Run-Sync Integration: Connects SPECs to downstream DDD implementation and documentation sync phases, including Git Worktree-based parallel development. - Use Case: Ask to plan a "user authentication system" and receive a complete SPEC directory with EARS requirements, API contracts, constraints, quantified success criteria, and Given-When-Then test scenarios ready for implementation. ## Quick Start Ask the assistant to create a SPEC for a new feature, for example: create a SPEC for a JWT-based user authentication system with EARS requirements and acceptance criteria.

Frequently Asked Questions about moai-workflow-spec

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

FAQPage Schema
How do I write requirements in EARS format?▼

EARS defines five patterns: Ubiquitous (always active), Event-Driven (WHEN event THEN action), State-Driven (IF condition THEN action), Unwanted (prohibited behavior), and Optional (nice-to-have). Each requirement uses exactly one pattern to stay unambiguous and testable.

How do I create a SPEC document for a new feature?▼

Run the plan phase with a natural-language feature description, such as /moai:1-plan "user authentication system". The workflow analyzes input, clarifies requirements, applies EARS patterns, and generates spec.md, plan.md, and acceptance.md in .moai/specs/.

What files must a SPEC directory contain?▼

Every SPEC directory must contain three files: spec.md with EARS requirements, plan.md with the implementation plan and milestones, and acceptance.md with Given-When-Then acceptance criteria. Missing files break traceability and workflow execution.

Can I develop multiple SPECs in parallel?▼

Yes, use the --worktree flag when creating SPECs to set up isolated Git Worktree directories per feature. Each SPEC gets its own working directory, enabling parallel implementation sessions without branch switching or merge conflicts.

When should I not use this SPEC workflow skill?▼

Do not use it for implementation tasks (use the DDD workflow skill instead) or for documentation generation (use the project workflow skill). It also excludes reports and audits, which belong in .moai/reports/ rather than .moai/specs/.

What is the difference between spec-first, spec-anchored, and spec-as-source?▼

These are SPEC lifecycle levels. Spec-first is written once and discarded after implementation, spec-anchored is maintained alongside evolving code, and spec-as-source is the single source of truth where only the SPEC is edited by humans.