MoAI Foundation Core

MoAI Foundation Core

Foundational principles and architectural patterns that power MoAI-ADK's AI-driven development workflow.

Core Philosophy: Quality-first, domain-driven, modular, and efficient AI development through proven patterns and automated workflows.

Quick Reference

What is MoAI Foundation Core?

Six essential principles that ensure quality, efficiency, and scalability in AI-powered development:

1. TRUST 5 Framework - Quality gate system (Tested, Readable, Unified, Secured, Trackable)
2. SPEC-First DDD - Specification-driven domain-driven development workflow
3. Delegation Patterns - Task orchestration via specialized agents (never direct execution)
4. Token Optimization - 200K budget management and context efficiency
5. Progressive Disclosure - Three-tier knowledge delivery (Quick, Implementation, Advanced)
6. Modular System - File splitting and reference architecture for scalability

Quick Access:

• Quality standards in modules/trust-5-framework.md
• Development workflow in modules/spec-first-ddd.md
• Agent coordination in modules/delegation-patterns.md
• Budget management in modules/token-optimization.md
• Content structure in modules/progressive-disclosure.md
• File organization in modules/modular-system.md
• Agent catalog in modules/agents-reference.md
• Command reference in modules/commands-reference.md
• Security and constraints in modules/execution-rules.md

Use Cases:

• New agent creation with quality standards
• New skill development with structural guidelines
• Complex workflow orchestration
• Token budget planning and optimization
• Documentation architecture design
• Quality gate configuration

---

Implementation Guide

1. TRUST 5 Framework - Quality Assurance System

Purpose: Automated quality gates ensuring code quality, security, and maintainability.

Five Pillars:

Tested Pillar: Maintain comprehensive test coverage with characterization tests ensuring behavior preservation. Execute the project's test runner with coverage (e.g. go test -cover, pytest --cov, cargo test, npm test -- --coverage). Block merge and generate missing tests on failure. Characterization tests capture current behavior for legacy code, while specification tests validate domain requirements for new code. High coverage ensures code reliability and reduces production defects, and preserves behavior during refactoring.

Readable Pillar: Use clear and descriptive naming conventions. Run the project's linter (e.g. golangci-lint, ruff, eslint, clippy). Issue warning and suggest refactoring improvements on failure. Clear naming improves code comprehension, team collaboration, and maintenance velocity.

Unified Pillar: Apply consistent formatting and import patterns. Run the project's formatter (e.g. gofmt, black, prettier, rustfmt). Auto-format code or issue warning on failure. Consistency eliminates style debates and merge conflicts and improves readability.

Secured Pillar: Comply with OWASP security standards. Surface security findings via the appropriate agent or reference skill (e.g. spawn a per-spawn general-purpose agent with security instructions, or load the moai-ref-owasp-checklist / moai-ref-llm-security reference). Block merge and require security review on failure. Security vulnerabilities create critical business and legal risks.

Trackable Pillar: Write clear and structured commit messages. Match Git commit message regex patterns (Conventional Commits). Suggest proper commit message format on failure. Clear history enables debugging, auditing, and collaboration.

Integration Points: Pre-commit hooks for automated validation, CI/CD pipelines for quality gate enforcement, Agent workflows for TRUST 5 validation (moai-foundation-quality orchestration), Documentation for quality metrics.

Detailed Reference: modules/trust-5-framework.md

---

2. SPEC-First DDD - Development Workflow

Purpose: Specification-driven development ensuring clear requirements before implementation.

Three-Phase Workflow:

Phase 1 SPEC (/moai plan): workflow-spec generates GEARS format (primary; EARS retained as 6-month backward-compat legacy reference for the 88 pre-v3 SPECs). Output is .moai/specs/SPEC-XXX/spec.md. Execute /clear to save 45-50K tokens.

Phase 2 DDD (/moai run): ANALYZE for requirements, PRESERVE for existing behavior, IMPROVE for enhancement. Validate with at least 85% coverage.

Phase 3 Docs (/moai sync): API documentation, architecture diagrams, project reports.

GEARS Format (current notation): Five patterns — Ubiquitous "The <subject> shall <behavior>" for system-wide always active requirements; Event-driven "When <event> the <subject> shall <behavior>" for trigger-response requirements; State-driven "While <state> the <subject> shall <behavior>" for conditional behavior; Where (capability gate) "Where <capability or feature flag>, the <subject> shall <behavior>" for capability-conditioned behavior; Event-detected (replaces the deprecated conditional modality) "When <undesired-condition-detected>, the <subject> shall <response>" for failure-mode handling. Unified compound clause: [Where ...][While ...][When ...] The <subject> shall <behavior> — any subset of the three modifiers may chain. The <subject> is generalized — any noun (system, component, service, agent, function, artifact). See the canonical authoring guide at ~/.claude/skills/moai-workflow-spec/SKILL.md § "GEARS Format".

EARS Format (legacy reference, 6-month backward-compat — expires 2026-11-22): Five patterns Ubiquitous / Event-driven (WHEN/THEN) / State-driven (WHILE) / Unwanted (SHALL NOT) / Optional (WHERE possible). The 88 pre-v3 SPECs continue to use EARS; the lint engine emits a LegacyEARSKeyword warning on residual deprecated conditional modality in NEW SPECs (warning non-strict, error under moai spec lint --strict). For NEW SPECs, use GEARS. See modules/spec-ears-format.md (legacy reference, deprecated — see GEARS Format guide).

Token Budget: SPEC takes 30K, DDD takes 180K, Docs takes 40K, Total is 250K.

Key Practice: Execute /clear after Phase 1 to initialize context.

Detailed Reference: modules/spec-first-ddd.md

---

3. Delegation Patterns - Agent Orchestration

Purpose: Task delegation to specialized agents, avoiding direct execution.

Core Principle: MoAI must delegate all work through Agent() to specialized agents. Direct execution bypasses specialization, quality gates, and token optimization. Proper delegation improves task success rate by 40 percent and enables parallel execution.

Delegation Syntax: MoAI delegates via natural language — "Use the {agent} subagent to {task}" — carrying full context, constraints, and rationale. The orchestrator never passes a subagent_type code literal; it spawns Agent() (or Agent(general-purpose) for domain work) with a prose prompt.

Three Patterns:

Sequential for dependencies: Use the manager-spec subagent to author the SPEC, then the manager-develop subagent to implement it with the SPEC as context.

Parallel for independent work: Spawn multiple Agent(general-purpose) teammates in one turn — e.g. one with backend instructions and one with frontend instructions — when the work is independent.

Conditional for analysis-based: Use the Explore subagent for read-only diagnosis, then route the result to the appropriate retained agent (manager-develop for fixes, sync-auditor for quality scoring) based on the findings.

Agent Selection: Simple tasks with 1 file use 1-2 agents sequential. Medium tasks with 3-5 files use 2-3 agents sequential. Complex tasks with 10+ files use 5+ agents mixed. Domain-specific work (backend / frontend / security / performance / refactoring) is handled in run-phase by manager-develop, or by a per-spawn Agent(general-purpose) with a domain whitelist per .claude/rules/moai/workflow/archived-agent-rejection.md.

Detailed Reference: modules/delegation-patterns.md

---

4. Token Optimization - Budget Management

Purpose: Efficient 200K token budget through strategic context management.

Budget Allocation:

SPEC Phase takes 30K tokens. Strategy is to load requirements only and execute /clear after completion. Specification phase requires minimal context for requirement analysis. Saves 45-50K tokens for implementation phase.

DDD Phase takes 180K tokens. Strategy is selective file loading, load only implementation-relevant files. Implementation requires deep context but not full codebase. Enables 70 percent larger implementations within budget.

Docs Phase takes 40K tokens. Strategy is result caching and template reuse. Documentation builds on completed work artifacts. Reduces redundant file reads by 60 percent.

Total Budget is 250K tokens across all phases. Phase separation with context reset between phases provides clean context boundaries and prevents token bloat. Enables 2-3x larger projects within same budget.

Token Saving Strategies:

Phase Separation: Execute /clear between phases, after /moai plan to save 45-50K, when context exceeds 150K, after 50+ messages.

Selective Loading: Load only necessary files.

Context Optimization: Target 20-30K tokens.

Model Selection: Sonnet for quality, Haiku for speed and cost with 70% cheaper rates for 60-70% total savings.

Detailed Reference: modules/token-optimization.md

---

5. Progressive Disclosure - Content Architecture

Purpose: Three-tier knowledge delivery balancing value with depth.

Three Levels:

Quick Reference Level: 30 seconds time investment, core principles and essential concepts, approximately 1,000 tokens. Rapid value delivery for time-constrained users. Users gain 80 percent understanding in 5 percent of time.

Implementation Level: 5 minutes time investment, workflows, practical examples, integration patterns, approximately 3,000 tokens. Bridges concept to execution with actionable guidance. Enables immediate productive work without deep expertise.

Advanced Level: 10+ minutes time investment, deep technical dives, edge cases, optimization techniques, approximately 5,000 tokens. Provides mastery-level knowledge for complex scenarios. Reduces escalations by 70 percent through comprehensive coverage.

SKILL.md Structure (maximum 500 lines): Quick Reference section, Implementation Guide section, Advanced Patterns section, Works Well With section.

Module Architecture: SKILL.md as entry point with cross-references, modules directory for deep dives with unlimited size, examples.md for working samples, reference.md for external links.

File Splitting when exceeding 500 lines: SKILL.md contains Quick at 80-120 lines, Implementation at 180-250 lines, Advanced at 80-140 lines, References at 10-20 lines. Overflow content goes to modules/topic.md.

Detailed Reference: modules/progressive-disclosure.md

---