유틸리티 명령어

유틸리티 명령어는 SPEC 3-Phase 라이프사이클 (/moai plan → /moai run → /moai sync) 바깥에서 빠른 자동화와 문제 해결을 맡는 명령어 모음입니다. 진단 도구가 찾은 오류를 반복해 고치는 루프 (loop, fix), 완료 조건을 선언해 세션을 계속 돌리는 조건 선언형 루프 (goal), 코드 위생 (clean, mx, gate), 아키텍처 문서화 (codemaps), 다관점 코드 리뷰 (review), E2E 테스트 (e2e), 그리고 피드백 제출 (feedback) 까지 맡습니다. 워크플로우 명령어가 “기능 하나를 통째로 만드는” 긴 흐름이라면, 유틸리티 명령어는 “지금 당장 이 문제를 풀고 싶을 때” 쓰는 짧고 뾰족한 도구들입니다. 따라서 두 계열은 서로 겹치지 않고 보완합니다.

정보

소속 가치: 에이전틱 루프 엔지니어링 · 에이전틱 하네스

v3의 세 가지 핵심 중 하나인 에이전틱 루프 엔지니어링이 실제로 도는 자리가 이 섹션입니다. /moai loop는 진단 도구가 찾은 이슈 큐를 비울 때까지 반복하는 진단형 루프이고, /moai goal은 완료 조건을 선언해 두면 그 조건이 충족될 때까지 세션이 스스로 일하는 조건 선언형 루프입니다. /moai fix는 같은 계열의 단발 (1회) 프리셋입니다. 루프가 돌면서 남긴 관찰은 하네스 학습의 원료가 됩니다. 루프가 관찰을 쌓고 하네스가 그것을 학습해 지침을 고쳐 가는 되먹임이 바로 여기서 시작됩니다. 그래서 이 섹션의 명령어들은 단순한 편의 도구가 아니라, 세 번째 핵심 가치가 런타임에서 현장적으로 검증되는 현장입니다.

flowchart TD
    A[유틸리티 명령어] --> B[자동화 명령어]
    A --> C[코드 관리 명령어]
    A --> D[피드백 명령어]

    B --> E["/moai
완전 자율 자동화"]
    B --> F["/moai loop
반복 수정 루프"]
    B --> G["/moai fix
일회성 자동 수정"]
    C --> H["/moai clean
데드 코드 제거"]
    C --> I["/moai codemaps
아키텍처 문서 생성"]
    C --> K["/moai gate
커밋 전 품질 게이트"]
    C --> L["/moai mx
@MX 코드 주석"]
    C --> M["/moai review
다관점 코드 리뷰"]
    C --> N["/moai e2e
E2E 테스트"]
    D --> J["/moai feedback
피드백 제출"]

    E -->|내부에서 사용| F
    F -->|1회만 실행하면| G
    H -->|정리 후 재생성| I

정보

SPEC 3-Phase 라이프사이클 명령어 (/moai plan, run, sync, project, design, harness)는 워크플로우 명령어 섹션을 참조하세요. /moai 오케스트레이터가 라우팅하는 전체 16개 서브커맨드 목록도 그 섹션에 있습니다.

정보

어떤 명령어를 써야 할지 모르겠다면?

• 기능 하나를 통째로 만들고 싶다면 → /moai
• “이 조건이 만족될 때까지 알아서 해줘"라면 → /moai goal
• 코드에 오류가 많아서 반복적으로 고치고 싶다면 → /moai loop
• 간단한 린트 오류만 빠르게 고치고 싶다면 → /moai fix
• 커밋 전에 통과/실패만 빠르게 확인하고 싶다면 → /moai gate
• AI 맥락용 코드 주석 (@MX) 을 심고 싶다면 → /moai mx
• 사용하지 않는 코드를 정리하고 싶다면 → /moai clean
• 프로젝트 아키텍처 문서를 만들고 싶다면 → /moai codemaps
• MoAI-ADK 자체에 문제가 있다면 → /moai feedback