agmo-everywhere-codex

Use as the canonical first-stage Agmo workflow when the user wants idea exploration, design tradeoffs, or requirement shaping before planning or implementation.

Run a Codex-native structured code review using agmo-critic and agmo-verifier where evidence is needed.

Harvest `debt:` markers across the repo into a read-only ledger without modifying code.

Audit and maintain the vault-backed llm-wiki knowledge base, including stale pages, low-confidence or contested captures, superseded captures, missing frontmatter, and broken wikilinks.

Use when prior notes, durable project knowledge, or vault-backed context should influence the current task.

Use when one execution lane is no longer enough and work should escalate to the durable `agmo team ...` runtime.

Use when the user wants a GitHub issue created from the current conversation or repo context. Triggers on requests like "이슈 만들어", "깃허브 이슈", "create issue", or "new issue". If the source artifact is an existing vault note, use `note-to-issue` instead.

Use when implementation should begin from an approved plan, with agmo-explore/agmo-architect preflight and the main session staying in orchestrator mode while handing coding to the Agmo execution lane.

Use when the user wants commit, push, PR, or branch management work in the current git repo. Triggers on requests like "커밋", "푸시", "PR", "pull request", "브랜치", or "git workflow".

Use when the user wants to convert an existing vault note or markdown note into a GitHub issue. Triggers on requests like "노트로 이슈", "이슈로 변환", "convert note to issue", or "note to issue". For issue creation from conversation context without a source note, use `create-issue` instead.

Use when a plan should be challenged, approved, or refined before implementation starts, with agmo-critic/agmo-architect/verifier routing as needed.

Use when the task needs scoped planning, decomposition, or execution sequencing before implementation begins, with agmo-explore/agmo-architect support when needed.

Use as an explicit compatibility alias for execute when the user wants completion-gated implementation that keeps going until proof is gathered.

Use as an explicit compatibility alias for consensus-oriented planning when the user wants a higher-trust plan before execution.

Use when the current run should persist a durable decision, checkpoint, or summary into the vault.

Use when the task needs relevant prior notes, vault context, or stored project decisions before planning or execution.

Use when the task needs validation, testing, completion checks, or evidence review.

Use as a compatibility alias for brainstorming when the user asks for design shaping, tradeoff discussion, or pre-plan solution framing.