Codex-only team orchestration: run a named team of cooperating Codex threads with durable, script-managed state. MUST USE when the user asks Codex to create, run, coordinate, inspect, archive, or delete a team of threads/sessions, or to work on something as a team in parallel. The main session is always the leader; members are defined by a concrete part, ownership area, or perspective - never a vague job role; a bundled cross-platform script writes the .omo/teams state plus an auto-generated member field manual. Use a team when the work is not perfectly isolated but parallelizing helps, or when a task still needs exploration under a clear goal; use plain subagents when scope is perfectly isolated or the goal is ambiguous. Triggers: team mode, teammode, make a team, run as a team, team of agents, coordinate threads, parallel Codex threads, archive the team, delete the team.

2026-06-2363.4k

codex-qa

code-yeongyu/oh-my-openagent

QA the omo Codex Light edition (lazycodex / packages/omo-codex) itself, in strict isolation so ONLY our plugin is exercised, never the user's real ~/.codex. The first-party method drives the real `codex app-server` against an isolated CODEX_HOME plus a LOCAL mock model (no real API call), and proves a plugin hook fired by asserting hook/started + hook/completed notifications. Also: isolated install verification, per-component hook probes, a tmux TUI smoke, and runtime log observation (RUST_LOG / logs SQLite / /debug-config). Ships tested helper scripts each with a --self-test. Use whenever someone changes anything under packages/omo-codex or wants to QA, smoke-test, verify, or debug the Codex plugin, its hooks/components, the installer/config.toml, the app-server flow, or the Codex TUI. Triggers: codex qa, qa codex, codex-qa, test codex plugin, verify codex hook, codex app-server, lazycodex qa, isolated CODEX_HOME, prove codex hook fired, codex tui test.

2026-06-2363.4k

opencode-qa

code-yeongyu/oh-my-openagent

QA opencode itself, per case: verify the CLI/terminal (opencode run, db, serve, export), prove a specific plugin hook/action/event fired via the SSE event stream, smoke-test the TUI under tmux, and investigate sessions in opencode's SQLite DB by id, title/name, or message text. Ships tested helper scripts (each with a --self-test) plus per-domain references. Use whenever someone wants to QA, smoke-test, verify, or debug opencode's CLI, HTTP server, plugin hooks/events, or TUI, or to find/inspect opencode sessions in the database. Triggers: opencode qa, qa opencode, test opencode, verify opencode hook, opencode session db, find opencode session by id/name/text, opencode tui test, opencode server health, opencode event stream.

2026-06-2363.4k

start-work

code-yeongyu/oh-my-openagent

Execute a Prometheus work plan in Codex with Boulder state, evidence ledger updates, worktree discipline, parallel subagents, and Stop-hook continuation. Use after planning when the user says start work, execute plan, continue plan, resume plan, or asks to run a .omo/plans plan.

2026-06-2363.4k

visual-qa

code-yeongyu/oh-my-openagent

Rigorous visual QA for any UI you built or changed, across BOTH web/page UIs and TUI/terminal UIs. MUST USE after building or changing any UI to verify it visually before declaring it done. Captures objective reference evidence with a bundled diff script (image-diff for screenshots, tui-check for terminal captures), then runs two parallel read-only oracle passes (design-system and functional integrity; visual fidelity and CJK precision) and synthesizes one good/bad verdict. Triggers: visual QA, visual regression, screenshot diff, pixel diff, image comparison, UI looks wrong, design system check, is this really a design system or just an image, alpha channel breakage, responsive check, CJK text, Korean/Japanese/Chinese text clipping or semantic line breaks, baseline drop, glyph drop, TUI alignment, terminal UI, tmux capture, box-drawing border misalignment, wide-character column drift. Use it even when the user does not say visual QA but asks whether a page, component, or terminal layout looks right.

2026-06-2363.4k

work-with-pr

code-yeongyu/oh-my-openagent

Full PR lifecycle in a fresh task-owned git worktree: implement via the ulw-loop skill with mandatory evidence-bound manual QA → reviewer-readable English PR → verification loop (CI + review-work reviewers + Cubic, where Cubic is skipped only when its quota is exhausted) → merge by default → worktree cleanup. Decomposes one task into the smallest atomic, independently-mergeable PRs and builds the independent ones concurrently via one worktree per PR driven by parallel subagents or a team. Unbounded loop: any failing gate sends you back to fix-and-re-QA inside that PR's worktree. Use whenever implementation work needs to land as a PR. Triggers: 'create a PR', 'implement and PR', 'work on this and make a PR', 'implement issue', 'land this as a PR', 'split into atomic PRs', 'parallel PRs', 'work-with-pr', 'PR workflow', 'implement end to end', even when user just says 'implement X' if the context implies PR delivery.

2026-06-2363.4k

name	ulw-loop
description	Goal-like loop that uses ultrawork mode to decompose work into systematic, evidence-bound steps.
metadata	{"short-description":"Goal-like ultrawork loop for systematic decomposition"}

ulw-loop

Use this skill when the user asks for ulw-loop, ulw, durable goal execution, evidence-led work, manual QA, or checkpointed long-running delivery.

This skill is intentionally compact. The full workflow lives in references/full-workflow.md. Read only the sections needed for the current phase, then execute them exactly.

Required First Steps

Open references/full-workflow.md.
Read through Bootstrap (including its tier triage), Execution Loop, and the Manual-QA channels table before running any ULW command or recording evidence.
If the task has code edits, tests, QA, or commit work, follow the full workflow's delegation and evidence rules. Tests alone never prove done.

Non-Negotiables

Use the ulw-loop CLI state under .omo/ulw-loop; do not hand-edit goal state.
After any compaction or context loss, re-read brief + goals + ledger FIRST (omo sparkshell cat .omo/ulw-loop/ledger.jsonl or read directly) plus omo ulw-loop status --json, then resume; never re-plan from scratch.
If omo ulw-loop create-goals says the existing aggregate is already complete, start unrelated new work with a fresh --session-id <new-id> instead of steering or forcing the completed default state. Use --force only to intentionally overwrite completed evidence.
Every success criterion needs observable evidence from a real surface: a channel (tmux, HTTP, browser, computer-use) or, for CLI- or data-shaped criteria, an auxiliary surface (CLI stdout, DB diff, parsed config dump).
Record evidence through the CLI only after cleanup receipts are available.
Delegate code edits, test writes, fixes, and QA execution to right-sized Codex subagents when the workflow requires it.
Every multi_agent_v1.spawn_agent message starts with TASK:, then names DELIVERABLE, SCOPE, and VERIFY; put role and specialty instructions inside message; use fork_context: false unless full history is truly required.
Plan and reviewer agents may run for a long time; spawn them in the background, keep doing independent root work, and poll with short multi_agent_v1.wait_agent cycles. Never use a single long blocking wait for them.
For work likely to exceed one wait cycle, require the child to send WORKING: <task> - <current phase> before long reading, testing, or review passes, and BLOCKED: <reason> only when it cannot progress.
Track spawned agent names locally. Use multi_agent_v1.wait_agent for mailbox signals, not proof of completion. A timeout only means no new mailbox update arrived. Treat a running child as alive.
While children run, surface the active subagent count, agent names, and latest WORKING: phase.
Fallback only when the child is completed without the deliverable, ack-only after followup, explicitly BLOCKED:, or no longer running. Then record inconclusive and respawn a smaller fork_context: false task with the missing deliverable.
Use git-master for git-tracked edits: inspect recent and touched-path commit history, then commit each verified work unit atomically in the repository's observed language, scope, and message style with only that unit's files staged.

Codex Tool Mapping

The full workflow may mention OpenCode-style orchestration examples. In Codex, translate them to native tools:

Workflow intent	Codex tool
Plan agent	`multi_agent_v1.spawn_agent({"message":"TASK: act as a planning agent. ...","fork_context":false})`
Search/read-only worker	`multi_agent_v1.spawn_agent({"message":"TASK: act as an explorer. ...","fork_context":false})`
Implementation or QA worker	`multi_agent_v1.spawn_agent({"message":"TASK: act as an implementation or QA worker. ...","fork_context":false})`
Final verification reviewer	`multi_agent_v1.spawn_agent({"message":"TASK: act as a rigorous reviewer. ...","fork_context":false})`
Wait for background result	`multi_agent_v1.wait_agent(...)`
Clean up finished worker	`multi_agent_v1.close_agent(...)`

When translating load_skills=[...], include the requested skill names in the spawned agent's message.