skills.rest
taewook486
taewook486COMMUNITY
Explore all skills by this author →
WebsiteGitHub

moai-workflow-spec

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

Updated Mar 22, 2026
Search Tags:#workflow#planning#requirements#acceptance criteria#spec#ears#moai-adk
One-click install
npx skills add https://github.com/taewook486/Masters_degree --skill moai-workflow-spec-taewook486
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: moai-workflow-spec
Source: https://github.com/taewook486/Masters_degree/tree/main/.claude/skills/moai-workflow-spec
Command: npx skills add https://github.com/taewook486/Masters_degree --skill moai-workflow-spec-taewook486

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Writing unambiguous software requirements is hard: vague prose leads to misinterpretation, scope creep, and untestable acceptance criteria. This Skill structures requirement definition using the EARS/GEARS notation and a standardized 3-file SPEC format so every requirement is testable and traceable. ## Core Features & Use Cases - GEARS/EARS Requirement Patterns: Five canonical patterns (Ubiquitous, Event-driven, State-driven, Capability gate, Unwanted) with a unified compound clause and generalized subject for precise requirement authoring. - Standardized SPEC Structure: Enforces a 3-file layout (spec.md, plan.md, acceptance.md) with a 12-field metadata schema, lifecycle states, and lint validation rules. - Plan-Run-Sync Integration: Connects SPEC creation to implementation and documentation sync phases, including Git Worktree-based parallel development and clarification gates. - Use Case: When planning a new feature like user authentication, use this Skill to produce a SPEC with EARS requirements, quantified success criteria, and Given-When-Then acceptance scenarios before any code is written. ## Quick Start Ask the AI to create a SPEC document for your feature using EARS-format requirements and acceptance criteria, for example by running /moai plan followed by a feature description.

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 uses five patterns: Ubiquitous ("The system shall X"), Event-driven ("WHEN event, the system shall Y"), State-driven ("WHILE state, ..."), Unwanted ("shall not"), and Optional. Pick the pattern based on whether the requirement is always active, triggered, state-dependent, prohibited, or nice-to-have.

What is the difference between GEARS and EARS notation?▼

GEARS is the canonical notation as of v3.0.0 that generalizes the EARS subject to any noun and reframes Where as a capability gate. The legacy IF/THEN modality is deprecated and replaced by When <event-detected>; legacy EARS SPECs remain valid during a 6-month backward-compatibility window.

What files must a SPEC directory contain?▼

Every SPEC directory under .moai/specs/ must contain three files: spec.md for EARS requirements, plan.md for the implementation plan and milestones, and acceptance.md for acceptance criteria with Given-When-Then scenarios. Missing files create incomplete requirements.

How does SPEC integrate with Plan-Run-Sync workflow?▼

The PLAN phase creates the SPEC in .moai/specs/, the RUN phase implements it via DDD or TDD with quality-gate validation, and the SYNC phase updates documentation and changelogs. Git Worktrees allow multiple SPECs to be implemented in parallel.

When should I not put a document in .moai/specs/?▼

Reports analyzing existing code (security audits, performance reviews) belong in .moai/reports/, and usage documentation belongs in .moai/docs/. SPECs are exclusively forward-looking definitions of features to be built, written in EARS format.

Related Skills

Explore More Software Engineering Skills→
The-Vibe-CompanyThe-Vibe-Company
2.4k

to-spec

Synthesizes conversation context into a structured spec published to the project issue tracker.

Official
Intermediate
alexandrbasisalexandrbasis
12

si

Execute TDD implementation with Red-Green-Refactor cycles and code review preparation.

Community
Advanced
SayBGMSayBGM

moai-foundation-quality

Enforce TRUST 5 code quality standards with linting and CI/CD integration.

Community
Advanced
burgebjburgebj

octopus-quick

Execute small software changes with atomic commits and state tracking.

Community
Intermediate