Yeachan-Heo / oh-my-codex

oh-my-codex (OMX) Start Codex stronger, then let OMX add better prompts, workflows, and runtime help when the work grows. **Website:** https://yeachan-heo.github.io/oh-my-codex-website/ **Docs:** Getting Started · Agents · Skills · Integrations · Demo · OpenClaw guide OMX is a workflow layer for OpenAI Codex CLI. It keeps Codex as the execution engine and makes it easier to: • start a stronger Codex session by default • reuse good prompts with • invoke workflows with skills like , , and • keep project guidance, plans, logs, and state in Recommended default flow If you want the default OMX experience, start here: Then work normally inside Codex: That is the main path. Start OMX strongly, do the work in Codex, and let the agent pull in or other workflows only when the task actually needs them. What OMX is for Use OMX if you already like Codex and want a better day-to-day runtime around it: • reusable role prompts such as and • reusable workflows such as , , , and • project guidance through scoped • durable state under for plans, logs, memory, and mode tracking If you want plain Codex with no extra workflow layer, you probably do not need OMX. Quick start Requirements • Node.js 20+ • Codex CLI installed: • Codex auth configured • on macOS/Linux if you later want the durable team runtime • on native Windows if you later want Windows team mode A good first session Launch OMX the recommended way: Then try one prompt and one skill: If the task grows, the agent can escalate to heavier workflows such as for persistent execution or for coordinated parallel work. A simple mental model OMX does **not** replace Codex. It adds a better working layer around it: • **Codex** does the actual agent work • **OMX prompts** make useful roles reusable • **OMX skills** make common workflows reusable • ** ** stores plans, logs, memory, and runtime state Most users should think of OMX as **better prompting + better workflow + better runtime**, not as a command surface to operate manually all day. Start here if you are new • Run • Launch with • Ask for analysis with • Ask for planning with • Let the agent decide when , , or another workflow is worth using Common in-session surfaces | Surface | Use it for | | --- | --- | | | analysis, boundaries, tradeoffs | | | focused implementation work | | | browsing installed skills | | | planning before implementation | | | persistent sequential execution | | | coordinated parallel execution when the task is big enough | Advanced / operator surfaces These are useful, but they are not the main onboarding path. Team runtime Use the team runtime when you specifically need durable tmux/worktree coordination, not as the default way to begin using OMX. Setup, doctor, and HUD These are operator/support surfaces: • installs prompts, skills, config, and AGENTS scaffolding • verifies the install when something seems wrong • is a monitoring/status surface, not the primary user workflow Explore and sparkshell • is for read-only repository lookup • is for shell-native inspection and bounded verification Examples: Platform notes for team mode needs a tmux-compatible backend: | Platform | Install | | --- | --- | | macOS | | | Ubuntu/Debian | | | Fedora | | | Arch | | | Windows | | | Windows (WSL2) | | Documentation • Getting Started • Demo guide • Agent catalog • Skills reference • Integrations • OpenClaw / notification gateway guide • Contributing • Changelog Languages • English • 한국어 • 日本語 • 简体中文 • 繁體中文 • Tiếng Việt • Español • Português • Русский • Türkçe • Deutsch • Français • Italiano License MIT