SPEC workflow orchestration with EARS format requirements, acceptance criteria, and Plan-Run-Sync integration for MoAI-ADK development. Use when creating SPEC documents or defining acceptance criteria.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
SPEC workflow orchestration with EARS format requirements, acceptance criteria, and Plan-Run-Sync integration for MoAI-ADK development. Use when creating SPEC documents or defining acceptance criteria.
SPEC Workflow Orchestration - Comprehensive specification management using EARS format for systematic requirement definition and Plan-Run-Sync workflow integration.
Core Capabilities:
EARS Format Specifications: Five requirement patterns for clarity
Requirement Clarification: Four-step systematic process
SPEC Document Templates: Standardized structure for consistency
Constitution defines the project DNA that all SPECs must respect. Before creating any SPEC, verify alignment with project constitution defined in .moai/project/tech.md.
Constitution Components:
Technology Stack: Required versions and frameworks
Naming Conventions: Variable, function, and file naming standards
Forbidden Libraries: Libraries explicitly prohibited with alternatives
Architectural Patterns: Layering rules and dependency directions
Security Standards: Authentication patterns and encryption requirements
Logging Standards: Log format and structured logging requirements
Constitution Verification:
All SPEC technology choices must align with Constitution stack versions
No SPEC may introduce forbidden libraries or patterns
SPEC must follow naming conventions defined in Constitution
SPEC must respect architectural boundaries and layering
WHY: Constitution prevents architectural drift and ensures maintainability
IMPACT: SPECs aligned with Constitution reduce integration conflicts significantly
SPEC Workflow Stages
Stage 1 - User Input Analysis: Parse natural language feature description
Stage 2 - Requirement Clarification: Four-step systematic process
Stage 3 - EARS Pattern Application: Structure requirements using five patterns
Stage 4 - Success Criteria Definition: Establish completion metrics
Stage 5 - Test Scenario Generation: Create verification test cases
Stage 6 - SPEC Document Generation: Produce standardized markdown output
Version: 1.3.0 (SDD 2025 Standard Integration + SPEC Scope Classification)
Last Updated: 2026-01-21
Integration Status: Complete - Full Plan-Run-Sync workflow with SDD 2025 features and Migration Guide
Common Rationalizations
Rationalization
Reality
"The SPEC is obvious, I can skip EARS format"
EARS exists because obvious requirements are the first to be misinterpreted. The format forces disambiguation.
"Acceptance criteria are redundant with the requirements"
Requirements describe intent. Acceptance criteria describe observable evidence. Both are needed.
"I will refine the SPEC during implementation"
Late refinement means wasted implementation. SPEC is the cheap place to change your mind.
"Research is a nice-to-have, not a blocker"
Skipping research produces SPECs that conflict with existing code. research.md prevents rework.
"Annotation cycle is just user friction"
Annotation catches misunderstandings before code is written. It is the cheapest feedback loop in the pipeline.
"This SPEC is small, I do not need a separate file"
Every SPEC is a persistent contract. In-message SPECs cannot be referenced by /moai run SPEC-XXX.
Red Flags
Requirements written in imperative prose instead of EARS (WHEN X, SHALL Y)
Acceptance criteria phrased as subjective judgments ("feels fast", "looks clean")
SPEC document missing research.md sibling when modifying existing code
Annotation cycle skipped or reduced to a single-turn "looks good"
Requirements use "should" where they mean "shall" (optional vs mandatory ambiguity)
SPEC-ID not registered in .moai/specs/ directory
Verification
SPEC file exists at .moai/specs/SPEC-XXX/spec.md with unique ID
Every requirement uses EARS keywords (WHEN, WHILE, WHERE, IF, SHALL)
Every acceptance criterion is observable (test output, file existence, metric threshold)
research.md exists when the SPEC touches existing code
Annotation cycle completed with explicit user approval marker
SPEC references existing SPEC-IDs it depends on or supersedes