一键导入
execute
Use when the user wants to run an implementation plan. Triggers on "실행해줘", "구현해줘", "시작해줘", "execute", or after plan approval.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when the user wants to run an implementation plan. Triggers on "실행해줘", "구현해줘", "시작해줘", "execute", or after plan approval.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Loaded automatically at session start. Teaches the orchestrator how to route requests to skills and agents. Do not invoke manually.
Use when the user wants to explore an idea, design an approach, or think through a problem before implementing. Triggers on "고민", "논의", "아이디어", "brs".
Use when code review is needed. Triggers on "코드 리뷰", "리뷰해줘", "code review", or at completion of implementation.
Use to harvest `debt:` markers across the repo into a debt ledger and optionally persist it to the Obsidian vault. Triggers on "부채", "기술부채", "debt", "지름길 정리", "/debt". Read-only — does not modify code.
Implement an entire Figma page as Android Jetpack Compose screens by auto-splitting into frames with visual verification. Use whenever a user shares a figma.com/design URL and wants the page built as Compose code. Triggers on '안드로이드 피그마', 'Android Figma', 'Compose 구현'. Covers any multi-frame page. Does NOT apply to Figma asset downloads or single component edits.
Implement an entire Figma page by auto-splitting into frames with visual verification. Use whenever a user shares a figma.com/design URL and wants the page built in code. Triggers on '피그마 구현', '피그마 페이지', 'Figma implement'. Covers any multi-frame page: landing, dashboard, marketing, etc. Does NOT apply to Figma asset downloads or single component edits.
| name | execute |
| description | Use when the user wants to run an implementation plan. Triggers on "실행해줘", "구현해줘", "시작해줘", "execute", or after plan approval. |
Process all TODOs from a plan by dispatching executor agents with category routing. Automatically links ralph for persistent completion.
When this skill is invoked, ralph is automatically activated. The execution loop continues until all TODOs are complete and final verification passes.
Read the plan from the vault path provided via skill args (e.g., --plan-path {VAULT_PATH}).
Path resolution:
--plan-path is provided in args → Read the plan directly using Read tool from the vault path
agmo-everywhere/plans/[Plan]-제목.md{AGMO_VAULT_ROOT}/{vault_path} (e.g., {AGMO_VAULT_ROOT}/agmo-everywhere/plans/[Plan]-제목.md)agmo:vault-search to find the most recent plan for the current projectagmo:vault-search as fallbackParse all TODOs into a work queue.
Classify each TODO:
For each TODO (respecting dependency order):
1. Dispatch executor agent with appropriate category
- quick (haiku): simple file changes, config updates
- standard (sonnet): feature implementation, most work
- complex (opus): complex logic, architectural changes
2. Executor completes the TODO and reports results
3. Auto-trigger agmo:verification
- If FAIL → collect failure context (approach taken + verification judgment)
- Retry with accumulated feedback (up to 3 attempts):
Each retry prompt MUST include ALL prior failure context:
```
이전 시도 #{N}:
- 접근법: {what was changed}
- 실패 원인: {verification judgment summary}
- 금지: 위 접근법 재시도
```
(2nd retry includes attempt #1; 3rd retry includes attempts #1 + #2)
- If 3 failures → auto-trigger agmo:debugging (include all failure contexts)
- If PASS → proceed to step 4
4. Tag-based post-processing
- Check the TODO's Tags field
- If Tags contain `frontend` or `ui`:
→ Invoke agmo:accessibility with the TODO's changed files
→ If CRITICAL issues found → dispatch executor to fix → re-verify from step 3
→ If MINOR only → log summary, mark TODO complete
- If Tags do not contain `frontend` or `ui`:
→ Mark TODO complete, proceed to next
When a TODO is marked complete (after step 3 PASS and step 4 post-processing), report one of the following statuses:
| Status | When to use |
|---|---|
DONE | All acceptance criteria met, no known issues |
DONE_WITH_CONCERNS | Functionally complete but has known limitations or warnings |
BLOCKED | Cannot proceed due to missing dependency or external blocker |
NEEDS_CONTEXT | Requires clarification or additional context from the user |
Output format per TODO:
Status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
Evidence: [Brief summary of how completion was verified]
For DONE_WITH_CONCERNS, also include:
Concerns:
- [Concern description]
Follow-up: [Recommended next steps]
For BLOCKED, also include:
Reason: [Why it is blocked]
Blocker: [What needs to be resolved]
Next-Steps: [What must happen to unblock]
For NEEDS_CONTEXT, also include:
Question: [What clarification is needed]
Options: [Possible approaches, if applicable]
Behavior by status:
Connection to verification:
DONEDONE_WITH_CONCERNSBLOCKEDNEEDS_CONTEXTIf multiple TODOs are independent (no dependency, no shared files, and no import/export dependencies between their target files):
agmo:parallel to dispatch multiple executors concurrentlyAfter all TODOs are complete:
architect agent for final verificationWhen architect approves final verification:
agmo:save-impl to save implementation summary to Obsidianagmo:wisdom recordingIf the plan specifies TDD:
agmo:tdd to enforce RED → GREEN → REFACTOR| Situation | Action |
|---|---|
| TODO acceptance criteria unclear | Ask user for clarification |
| 3 consecutive verification failures | Invoke agmo:debugging (3-fix limit) |
| Dependency deadlock | Report to user, suggest plan revision |
| Build broken mid-execution | Stop, fix build, then resume |
| Tags missing from TODO | Log warning, attempt fallback by file extension (.tsx/.jsx/.css/.html → treat as frontend). If ambiguous, skip post-processing |