From c233b60c2e846081f4c48cdf1c7160019e5891e8 Mon Sep 17 00:00:00 2001 From: AlpoxDev Date: Sat, 4 Jul 2026 23:55:48 +0900 Subject: [PATCH] Update LazyCodex web copy --- README.md | 2 +- packages/web/content/docs/configuration.md | 2 +- .../web/content/docs/discipline-agents.md | 10 ++--- packages/web/content/docs/faq.md | 4 +- packages/web/content/docs/overview.md | 12 +++--- packages/web/lib/commands.ts | 2 +- packages/web/lib/docs-content.generated.ts | 12 +++--- packages/web/lib/github-stars-format.ts | 2 +- packages/web/lib/site-config.ts | 40 +++++++++---------- 9 files changed, 43 insertions(+), 43 deletions(-) diff --git a/README.md b/README.md index 2747f7a..68f8ca0 100644 --- a/README.md +++ b/README.md @@ -252,7 +252,7 @@ LazyCodex is a thin distribution layer. The core engine is [oh-my-openagent (OmO lazycodex/ ├── src/ → oh-my-openagent (submodule) ├── packages/ -│ └── web/ → Next.js 15 + Tailwind v4 + opennextjs-cloudflare +│ └── web/ → Next.js 16 + Tailwind v4 + opennextjs-cloudflare │ (deployed to lazycodex.ai via Cloudflare Workers) ├── .github/workflows/ → web-ci.yml + web-deploy.yml ├── README.md diff --git a/packages/web/content/docs/configuration.md b/packages/web/content/docs/configuration.md index 6c7c5e1..7445612 100644 --- a/packages/web/content/docs/configuration.md +++ b/packages/web/content/docs/configuration.md @@ -46,7 +46,7 @@ npx lazycodex-ai install --no-tui --codex-autonomous - **Model routing** — which model handles planning, implementation, verification, and specialist skills. The installer sets sensible defaults from your detected subscriptions; override per role when a project needs a different profile. - **Hooks and lifecycle** — whether the Stop-hook auto-continues a plan, iteration caps (500 in ultrawork mode, 100 in normal mode), and how completion is gated. - **Skills** — which skills are active and where they load from. -- **Agent** — Hephaestus, the autonomous deep worker, and its model/prompt overrides. The Codex package is the Hephaestus-only light port; the full OmO's Sisyphus orchestrator is not included. +- **Agent roles** — Hephaestus plus explorer, librarian, planner, reviewer, QA, and gate roles. The installer writes the role definitions and model/prompt overrides that Codex can route to. ### Hooks & lifecycle diff --git a/packages/web/content/docs/discipline-agents.md b/packages/web/content/docs/discipline-agents.md index a351502..1059686 100644 --- a/packages/web/content/docs/discipline-agents.md +++ b/packages/web/content/docs/discipline-agents.md @@ -1,4 +1,4 @@ -LazyCodex ports a single discipline agent from OmO into Codex: **Hephaestus**, the autonomous deep worker. There is no Sisyphus orchestrator in the Codex package — Hephaestus is the one role, and it carries the whole run itself with read-only subagents for parallel exploration. +LazyCodex installs OmO's discipline-agent surface into Codex. **Hephaestus** remains the autonomous deep-worker voice for end-to-end implementation, while specialist roles support exploration, external research, planning, review, QA, and completion gates. ### What Hephaestus is @@ -6,7 +6,7 @@ Named after the Greek god of the forge. Goal-oriented: you give it objectives, n ### Installed roles -As of `4.12.1`, the following roles are installed. When Codex exposes `agent_type`, the role is set directly; otherwise the role description is included in the message as a fallback. +The current install provides these roles. When Codex exposes `agent_type`, the role is set directly; otherwise the role description is included in the message as a fallback. | Role | Primary use | | --- | --- | @@ -41,9 +41,9 @@ Hephaestus runs a short, tight loop on every unit of work: - **Never speculates about code it has not read.** Exploration is cheap; assumption is expensive. - **Never leaves work unresolved at end of turn.** Every plan step is reconciled: `completed`, blocked (one-line reason), or removed (one-line reason). -### Delegation, not orchestration +### Delegation and orchestration -Hephaestus stays the parent. For parallel exploration it spawns read-only Codex subagent roles (`multi_agent_v1.spawn_agent`) and keeps the parent session live with brief status updates while children run. It does not hand the run off to a separate orchestrator — it owns the goal, delegates the grunt work, and verifies the results itself. +The parent Codex session keeps final ownership of goals and verification. For parallel work it can spawn Codex subagent roles and keep the parent session live with brief status updates while children run. Team mode adds a durable named-team surface when coordination is worth the overhead. ### Boulder state @@ -51,7 +51,7 @@ Hephaestus stays the parent. For parallel exploration it spawns read-only Codex ### Where the boulder comes from -The full OmO has a second primary agent, **Sisyphus**, the orchestrator with `.omo/boulder.json` session continuity. The Codex package is the Hephaestus-only light port, so on Codex the durable progress state lives in `.omo/boulder.json` as written by [`$start-work`](./start-work.md) and the Stop-hook continuation — without the Sisyphus orchestration layer. +OmO's broader orchestration ideas show up in Codex through durable `.omo/boulder.json` progress, Stop-hook continuation, named team state, and reviewer/gate roles. [`$start-work`](./start-work.md) is the main visible path: it advances the plan until every checkbox is done and the final gate is satisfied. ### Reading more diff --git a/packages/web/content/docs/faq.md b/packages/web/content/docs/faq.md index 3f6ca84..170e2f6 100644 --- a/packages/web/content/docs/faq.md +++ b/packages/web/content/docs/faq.md @@ -3,10 +3,10 @@ Quick answers to common sticking points. Start with **Install & environment** if ### Install & environment **What is LazyCodex?** -A light port of OmO for Codex. It layers commands, skills, hooks, and model routing onto Codex so the agent plans before it edits, verifies before it claims done, and keeps project context across sessions. +OmO packaged for Codex. It layers commands, skills, hooks, model routing, agent roles, diagnostics, and project memory onto Codex so the agent plans before it edits and verifies before it claims done. **Is LazyCodex a replacement for OmO?** -No. It is a focused subset. The full OmO has deeper orchestration. LazyCodex takes the parts that work well inside Codex and packages them as a repeatable install. +No. OmO is the core harness. LazyCodex is the Codex distribution: the `npx` installer plus the `omo@sisyphuslabs` marketplace plugin path that makes the OmO harness repeatable inside Codex. **Can I ask Codex to install it for me?** Yes. Open Codex and give it the LazyCodex GitHub link or `lazycodex.ai`, then ask it to install. Or run `npx lazycodex-ai install` yourself. diff --git a/packages/web/content/docs/overview.md b/packages/web/content/docs/overview.md index f30ab20..b7adcef 100644 --- a/packages/web/content/docs/overview.md +++ b/packages/web/content/docs/overview.md @@ -1,4 +1,4 @@ -LazyCodex is a light port of [OmO](https://github.com/code-yeongyu/oh-my-openagent) into Codex. It does not ship the full harness — it ports one role, **Hephaestus**, the autonomous deep worker, and the workflows that keep its runs honest. Think [LazyVim](https://github.com/LazyVim/LazyVim) for [lazy.nvim](https://github.com/folke/lazy.nvim), but for Codex. +LazyCodex packages [OmO](https://github.com/code-yeongyu/oh-my-openagent) as the Codex agent harness for complex codebases: project memory, planning, execution, and verified completion inside Codex. Think [LazyVim](https://github.com/LazyVim/LazyVim) for [lazy.nvim](https://github.com/folke/lazy.nvim), but for Codex. > *"LazyVim made Neovim usable for the rest of us. LazyCodex does the same for Codex."* @@ -19,17 +19,17 @@ LazyCodex itself is close to a small install alias. `lazycodex-ai` runs the OmO ### Where it comes from -OmO is the full agent harness: a primary orchestrator (Sisyphus) with `.omo/boulder.json` session continuity, a deep worker (Hephaestus), specialist agents, multi-model routing, 54+ lifecycle hooks, and team mode. That is a lot. LazyCodex takes only the piece that matters for a focused Codex setup and packages it as a repeatable install. +OmO is the core agent harness: discipline agents, parallel orchestration, multi-model routing, skills, hooks, verified completion, diagnostics, and team mode. LazyCodex packages that harness for Codex through the `lazycodex-ai` installer and the `omo@sisyphuslabs` marketplace plugin. ### What you get -The Hephaestus deep worker, ported into Codex with: +The OmO harness, wired into Codex with: - Goal-oriented execution — you give it objectives, not step-by-step recipes. - A tight operating loop: **Explore → Plan → Implement → Verify → Manually QA**. -- Parallel explore subagents so it maps the terrain before writing anything. +- Parallel agent roles so it maps the terrain before writing anything. - The `$ulw-plan`, `$start-work`, and `$ulw-loop` workflows that keep complex work moving until it is verified. -- Skills, hooks, model routing, and verification defaults wired into Codex in one pass. +- Project memory, skills, hooks, MCP tools, model routing, diagnostics, and verification defaults wired into Codex in one pass. ### Remember these four @@ -46,7 +46,7 @@ Use `{your prompt} ultrawork` when the job needs the deep worker to run as one c ### How it fits together -LazyCodex is a thin distribution layer over [OmO](https://github.com/code-yeongyu/oh-my-openagent). The core engine is OmO; LazyCodex packages OmO's Hephaestus for Codex. +LazyCodex is a thin distribution layer over [OmO](https://github.com/code-yeongyu/oh-my-openagent). The core engine is OmO; LazyCodex packages the OmO harness for Codex. Credit: The LazyCodex name idea is inspired by [LazyVim](https://github.com/LazyVim/LazyVim). The Ultragoal and UltraQA ideas are inspired by [oh-my-codex](https://github.com/Yeachan-Heo/oh-my-codex), reimplemented from concept for this Codex setup. diff --git a/packages/web/lib/commands.ts b/packages/web/lib/commands.ts index 2427740..eb888b6 100644 --- a/packages/web/lib/commands.ts +++ b/packages/web/lib/commands.ts @@ -10,7 +10,7 @@ export const COMMANDS: readonly LazyCommand[] = [ { name: "$ulw-loop", glyph: "loop", - syntax: '$ulw-loop "task" [--strategy=reset|continue]', + syntax: '$ulw-loop "task" [--completion-promise=TEXT] [--strategy=reset|continue]', summary: "A self-referential loop that runs until VERIFIED completion.", facts: [ "Emits DONE when it reaches a completion claim", diff --git a/packages/web/lib/docs-content.generated.ts b/packages/web/lib/docs-content.generated.ts index e342c12..d6cfb0a 100644 --- a/packages/web/lib/docs-content.generated.ts +++ b/packages/web/lib/docs-content.generated.ts @@ -1,23 +1,23 @@ // AUTO-GENERATED — do not edit. Run: node ./scripts/generate-docs-content.mjs export const DOC_SOURCES: Record = { - "overview.md": "

LazyCodex is a light port of OmO into Codex. It does not ship the full harness — it ports one role, Hephaestus, the autonomous deep worker, and the workflows that keep its runs honest. Think LazyVim for lazy.nvim, but for Codex.

\n
\n

"LazyVim made Neovim usable for the rest of us. LazyCodex does the same for Codex."

\n
\n

Thin distribution

\n

LazyCodex itself is close to a small install alias. lazycodex-ai runs the OmO installer targeting the Codex platform, and the actual features come from the omo plugin.

\n

What gets installed

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
LayerWhat it means in Codex
Commands$init-deep, $ulw-plan, $start-work, $ulw-loop — workflow entry points.
SkillsReview, debugging, refactoring, frontend, LSP, rules injection, and more — specialist playbooks.
HooksAutomatic assistants that fire at session start, prompt submit, post-edit, post-compact, and stop.
MCP Serversgrep_app, context7, codegraph, git_bash, lsp — tool connections.
Model routingRole-based model profiles so planning, implementation, and verification each get the right model.
Agent rolesexplorer, librarian, plan, momus, metis, and executor/reviewer roles for subagent delegation.
\n

Where it comes from

\n

OmO is the full agent harness: a primary orchestrator (Sisyphus) with .omo/boulder.json session continuity, a deep worker (Hephaestus), specialist agents, multi-model routing, 54+ lifecycle hooks, and team mode. That is a lot. LazyCodex takes only the piece that matters for a focused Codex setup and packages it as a repeatable install.

\n

What you get

\n

The Hephaestus deep worker, ported into Codex with:

\n\n

Remember these four

\n
    \n
  1. $init-deep creates project memory.
    2. \n
  2. $ulw-plan "what to build" sets the work order.
    3. \n
  3. $start-work executes the plan.
    4. \n
  4. $ulw-loop "task" keeps going until verified.
    5. \n
\n

LazyCodex wires rules loading, skills, hooks, model routing, and verification habits around this flow. Browse the sidebar docs one section at a time when you need the details.

\n

The harness workflow

\n

Use {your prompt} ultrawork when the job needs the deep worker to run as one coordinated, evidence-bound loop instead of a single turn.

\n

How it fits together

\n

LazyCodex is a thin distribution layer over OmO. The core engine is OmO; LazyCodex packages OmO's Hephaestus for Codex.

\n

Credit: The LazyCodex name idea is inspired by LazyVim. The Ultragoal and UltraQA ideas are inspired by oh-my-codex, reimplemented from concept for this Codex setup.

\n\n", + "overview.md": "

LazyCodex packages OmO as the Codex agent harness for complex codebases: project memory, planning, execution, and verified completion inside Codex. Think LazyVim for lazy.nvim, but for Codex.

\n
\n

"LazyVim made Neovim usable for the rest of us. LazyCodex does the same for Codex."

\n
\n

Thin distribution

\n

LazyCodex itself is close to a small install alias. lazycodex-ai runs the OmO installer targeting the Codex platform, and the actual features come from the omo plugin.

\n

What gets installed

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
LayerWhat it means in Codex
Commands$init-deep, $ulw-plan, $start-work, $ulw-loop — workflow entry points.
SkillsReview, debugging, refactoring, frontend, LSP, rules injection, and more — specialist playbooks.
HooksAutomatic assistants that fire at session start, prompt submit, post-edit, post-compact, and stop.
MCP Serversgrep_app, context7, codegraph, git_bash, lsp — tool connections.
Model routingRole-based model profiles so planning, implementation, and verification each get the right model.
Agent rolesexplorer, librarian, plan, momus, metis, and executor/reviewer roles for subagent delegation.
\n

Where it comes from

\n

OmO is the core agent harness: discipline agents, parallel orchestration, multi-model routing, skills, hooks, verified completion, diagnostics, and team mode. LazyCodex packages that harness for Codex through the lazycodex-ai installer and the omo@sisyphuslabs marketplace plugin.

\n

What you get

\n

The OmO harness, wired into Codex with:

\n\n

Remember these four

\n
    \n
  1. $init-deep creates project memory.
    2. \n
  2. $ulw-plan "what to build" sets the work order.
    3. \n
  3. $start-work executes the plan.
    4. \n
  4. $ulw-loop "task" keeps going until verified.
    5. \n
\n

LazyCodex wires rules loading, skills, hooks, model routing, and verification habits around this flow. Browse the sidebar docs one section at a time when you need the details.

\n

The harness workflow

\n

Use {your prompt} ultrawork when the job needs the deep worker to run as one coordinated, evidence-bound loop instead of a single turn.

\n

How it fits together

\n

LazyCodex is a thin distribution layer over OmO. The core engine is OmO; LazyCodex packages the OmO harness for Codex.

\n

Credit: The LazyCodex name idea is inspired by LazyVim. The Ultragoal and UltraQA ideas are inspired by oh-my-codex, reimplemented from concept for this Codex setup.

\n\n", "installation.md": "

One command installs the OmO agent harness for Codex without a global package install.

\n

Prerequisites

\n\n

LazyCodex runs inside Codex. Codex must be installed and logged in before you start. If you are setting up for the first time, the Codex App is the easier path — you can open a project and run $command directly from the GUI.

\n
\n

Do NOT use npm install -g or bun add -g. Always invoke via npx.

\n
\n

Install

\n

The command is one line. No global install, no setup files.

\n
npx lazycodex-ai install\n
\n

This is exactly equivalent to npx --yes --package oh-my-openagent omo install --platform=codex.

\n

To skip the TUI and run a fully autonomous, prompt-free setup:

\n
npx lazycodex-ai install --no-tui --codex-autonomous\n
\n

The installer connects commands, skills, hooks, model routing, and verification defaults into your Codex configuration. It is strongly recommended to let an LLM agent run the install — the agent handles subscription detection, model selection, and provider auth automatically.

\n

After install, the next Codex launch asks you to approve the omo hooks in the startup review. Hooks do not run before approval.

\n

If the install feels like too many steps, you do not have to run the command yourself. Open Codex and give it the lazycodex.ai link, then ask it to install LazyCodex. The agent reads the docs and walks the setup.

\n
\n

Stuck? Join the LazyCodex Discord and ask Jobdori for help.

\n
\n

Install from the Codex marketplace (experimental)

\n

The npx installer above stays the primary path. As an additive, experimental alternative you can install from inside Codex itself: type /plugins, open the Add Marketplace tab ("Add a marketplace from a Git repo or local root."), and enter https://github.com/code-yeongyu/lazycodex, then install omo from the sisyphuslabs marketplace. Or from the CLI:

\n
codex plugin marketplace add https://github.com/code-yeongyu/lazycodex\ncodex plugin add omo@sisyphuslabs\n
\n

On the next launch, approve the omo hooks in Codex's startup review — hooks never run before approval. The first approved session prints LazyCodex bootstrap running in background — restart the session when it completes while a background worker finishes the setup (config blocks, agent roles, bin links, a pinned sg binary for the ast_grep MCP); restart when it is done. The marketplace path never touches Codex permission settings — autonomous mode remains the explicit npx lazycodex-ai install --no-tui --codex-autonomous choice.

\n

Upgrade with codex plugin marketplace upgrade sisyphuslabs. The next startup review shows the hooks as Modified — expected after every upgrade, because the plugin files changed and the previous trust hashes no longer match — re-approve them and the following session re-runs bootstrap on the new version. If anything looks pending or degraded, npx lazycodex-ai doctor explains what and why.

\n

Authentication

\n

Auth targets Codex itself, not LazyCodex. The Codex CLI logs in during its own setup; the Codex App logs in through the app UI. There is no separate LazyCodex login command.

\n

Once Codex is logged in, npx lazycodex-ai install handles subscription detection, model selection, and provider routing. If you let an LLM agent run the install, it walks the same process for you.

\n

To check what is configured:

\n
npx lazycodex-ai doctor\n
\n

doctor explains what is set up, what is missing, and why it matters. See Configuration for provider and routing details.

\n

Windows

\n

Native Windows works with both install paths.

\n\n

Let an agent do it

\n

It is strongly recommended to let an LLM agent run the install and walk the setup for you. The agent handles subscription detection, model selection, and provider auth automatically.

\n", "recommended-environment.md": "

The smoothest environment for LazyCodex is Ubuntu or macOS. The harness leans on shell, Git, Node.js/npm, Codex config files, and hooks — all of which behave predictably on Unix-like systems.

\n

Operating system

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
OSRecommendationNotes
UbuntuMost recommendedServer and dev environments both have predictable paths, shells, and package management.
macOSRecommendedGood for local development. Homebrew plus Node.js/npm is all you need.
WindowsNot recommendedNative Windows shells and path differences cause unnecessary friction with hooks, CLI, file permissions, and script execution.
\n

If you must use Windows, run Codex and LazyCodex inside WSL2 Ubuntu rather than native Windows. Keep the project on the WSL2 filesystem for the most stable experience.

\n

Before you install

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ItemExpected state
CodexCodex App or Codex CLI installed and logged in.
Node.js/npmA maintained Node.js LTS. npx ships with npm.
ProjectA repository opened in Codex that you want to work in.
GitA Git repository so changes can be tracked and reverted.
SecretsProvider keys live in the shell or Codex environment — never pasted into project files.
\n

You do not need to install Bun unless you are building LazyCodex from source. Normal install and usage go through the npx path.

\n

Check your versions first:

\n
node -v\nnpm -v\nnpx -v\n
\n

If they are missing, install Node.js:

\n
# Ubuntu or WSL2 Ubuntu\nsudo apt update\nsudo apt install -y nodejs npm\n\n# macOS\nbrew install node\n
\n

Author recommendations

\n\n", "getting-started.md": "

LazyCodex is most useful as a harness for complex codebases: project memory, planning, execution, verified completion, skills, hooks, model routing, and diagnostics. This page walks through install verification and the four commands you will reach for most often.

\n

Prerequisites

\n\n

LazyCodex connects OmO commands, skills, and hooks into Codex configuration. If Codex is working normally, the install flow is the same for App and CLI.

\n

Install

\n

The simplest approach: open a new task in Codex, give it the LazyCodex GitHub link, and ask it to install.

\n
https://github.com/code-yeongyu/lazycodex\n\nInstall LazyCodex from this repository.\n
\n

If you prefer running the command directly:

\n
npx lazycodex-ai install\n
\n

After install, reopen Codex and check that OmO commands and skills appear in the $ menu. The next launch asks you to approve the omo hooks in the startup review — hooks do not run before approval.

\n

If the status shows pending or degraded, run the diagnostic first:

\n
npx lazycodex-ai doctor\n
\n

Authentication

\n

LazyCodex has no separate login. The installer (or the agent running it) handles subscription detection, model selection, and provider auth. Codex App or Codex CLI must already be logged in, but that is a prerequisite rather than a LazyCodex-specific step.

\n

See Configuration for provider and routing details.

\n

The four commands

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
CommandUse it when
$init-deepThe repository is too large or too old to explain from memory.
$ulw-planThe work needs decisions before any code is written.
$start-workA plan exists and should be executed to completion.
$ulw-loopYou want the agent to keep going until the result is verified.
\n

Your first run

\n

Start by giving the agent project context with hierarchical AGENTS.md memory:

\n
$init-deep\n
\n

Then pick the command that matches your task.

\n

If you need to plan first — this reads the repository and writes a decision-complete plan without touching product code. Approve the plan before it executes.

\n
$ulw-plan "add a done-toggle helper to the small task app"\n
\n

If a plan already exists — execute it. All checkboxes must complete before it stops.

\n
$start-work\n
\n

If you want end-to-end verified completion — the loop keeps going until evidence proves the result.

\n
$ulw-loop "fix the payment flow failure and verify end to end"\n
\n

How to choose

\n

Start with $init-deep once per repository so agents have hierarchical AGENTS.md context to work from.

\n

For anything ambiguous, run $ulw-plan first. It interviews you, explores the codebase in parallel, and writes a decision-complete plan to plans/<slug>.md without touching product code.

\n

Hand that plan to $start-work to execute it: durable Boulder state, parallel subagents, strict TDD, and five evidence gates. It prints ORCHESTRATION COMPLETE when every checkbox is done.

\n

$ulw-loop is the tightest loop — use it for a single task that must run until an oracle verifies completion. It does not plan; it executes and verifies.

\n

A typical session

\n
$init-deep\n$ulw-plan "add rate limiting to the api gateway"\n$start-work plans/add-rate-limiting.md\n
\n

If the job is small and well-understood, skip the plan and loop directly:

\n
ulw fix the flaky checkout test\n
\n

See Feature coverage for the skills that add specialist judgment around these commands.

\n", - "faq.md": "

Quick answers to common sticking points. Start with Install & environment if you are setting up, First use if you are choosing a command, Execution & verification if something seems off during a run, and Conflicts & limits if you hit a wall.

\n

Install & environment

\n

What is LazyCodex?\nA light port of OmO for Codex. It layers commands, skills, hooks, and model routing onto Codex so the agent plans before it edits, verifies before it claims done, and keeps project context across sessions.

\n

Is LazyCodex a replacement for OmO?\nNo. It is a focused subset. The full OmO has deeper orchestration. LazyCodex takes the parts that work well inside Codex and packages them as a repeatable install.

\n

Can I ask Codex to install it for me?\nYes. Open Codex and give it the LazyCodex GitHub link or lazycodex.ai, then ask it to install. Or run npx lazycodex-ai install yourself.

\n

Is there a difference between Codex App and Codex CLI installs?\nThey follow the same flow. LazyCodex installs into the Codex environment. Use whichever surface you prefer — App or CLI.

\n

Do I need Bun?\nNo. Unless you are building LazyCodex from source, Bun is not required. Install and usage go through npx with plain Node.js/npm.

\n

Does it work on Windows?\nYes. Both the npx installer and the Codex marketplace path support Windows natively. The installer provisions Node.js and Git Bash automatically when they are missing, and shell hooks run through Git Bash. If you already have Node.js and Git for Windows installed, everything works out of the box. See the Windows section in Installation for environment variable overrides and bootstrap logs.

\n

First use

\n

What kind of tasks is LazyCodex best at?\nLarge, long-running work where planning and verification matter. Small questions or one-line fixes can go straight to Codex without the harness.

\n

Do I need to study every skill before using it?\nNo. Skills auto-activate when a task matches their domain. Learn the four commands first; dig into individual skills when you hit a specific need.

\n

Which commands should I learn first?\n$init-deep for project memory, $ulw-plan for planning, $start-work for executing a plan, and $ulw-loop for open-ended tasks that need verified completion.

\n

How do I know the install worked?\nOpen Codex and type $ in the input — you should see OmO commands and skills listed. On the CLI, typing ulw should activate ultrawork mode. The first real command is usually $init-deep.

\n

The $ menu does not show any commands after install.\nOpen a new Codex session to reload the plugin, then check whether the startup review has a pending omo hook approval. If it still does not show, run npx lazycodex-ai doctor to check install and skill loading state.

\n

Execution & verification

\n

Is npx lazycodex-ai doctor a real thing?\nYes. It runs the OmO doctor flow and reports what is configured, what is missing, and why. Use it whenever something looks off.

\n

Why does it ask me to approve hooks?\nCodex reviews hooks at startup. The omo hooks do not run until you approve them. After each upgrade the hooks show as Modified because the plugin files changed — re-approve to pick up the new version.

\n

What should I check after an upgrade?\nIf hooks show as Modified, re-approve them. If anything looks pending or degraded, run npx lazycodex-ai doctor for the full picture.

\n

$ulw-loop keeps finishing too quickly — what do I do?\nIteration alone does not fix vague completion criteria. Be specific about what you want collected, what verification must pass, and what the agent should investigate when data is missing. Or run $ulw-plan first to nail down the scope.

\n

Do I need a bigger token budget?\nLazyCodex is not a token-saving tool. It pushes good models and enough tokens through planning, execution, and verification. For large tasks, split work into smaller units before a single thread gets too heavy.

\n

How do I pick a thinking/reasoning level?\nDo not overthink it. Avoid low; use medium for everyday work; use high when failure cost is significant or review matters; save xhigh for genuinely heavy tasks.

\n

Can LazyCodex do computer-use?\nIt can, if the Codex session has computer-use tools connected. LazyCodex does not provide those tools itself — it directs the agent to use them during workflows and enforces stronger verification when they are available.

\n

Conflicts & limits

\n

Can I use it on desktop and continue on mobile/remote?\nLazyCodex installs into Codex, so it works wherever Codex works. The Codex App's desktop/mobile remote flow pairs well. Some features may only be fully available on the desktop app.

\n

Team mode shows up but thread creation fails.\nUpdate LazyCodex and Codex to latest, then run npx lazycodex-ai doctor. Team mode depends on Codex desktop app features that may differ between App and CLI.

\n

Can I use OMX alongside LazyCodex?\nNot recommended. Running both together can cause conflicts that burn tokens and fail silently. If the installer warns about a conflict, remove one. LazyCodex is meant to run as the sole thin layer on top of Codex.

\n", + "faq.md": "

Quick answers to common sticking points. Start with Install & environment if you are setting up, First use if you are choosing a command, Execution & verification if something seems off during a run, and Conflicts & limits if you hit a wall.

\n

Install & environment

\n

What is LazyCodex?\nOmO packaged for Codex. It layers commands, skills, hooks, model routing, agent roles, diagnostics, and project memory onto Codex so the agent plans before it edits and verifies before it claims done.

\n

Is LazyCodex a replacement for OmO?\nNo. OmO is the core harness. LazyCodex is the Codex distribution: the npx installer plus the omo@sisyphuslabs marketplace plugin path that makes the OmO harness repeatable inside Codex.

\n

Can I ask Codex to install it for me?\nYes. Open Codex and give it the LazyCodex GitHub link or lazycodex.ai, then ask it to install. Or run npx lazycodex-ai install yourself.

\n

Is there a difference between Codex App and Codex CLI installs?\nThey follow the same flow. LazyCodex installs into the Codex environment. Use whichever surface you prefer — App or CLI.

\n

Do I need Bun?\nNo. Unless you are building LazyCodex from source, Bun is not required. Install and usage go through npx with plain Node.js/npm.

\n

Does it work on Windows?\nYes. Both the npx installer and the Codex marketplace path support Windows natively. The installer provisions Node.js and Git Bash automatically when they are missing, and shell hooks run through Git Bash. If you already have Node.js and Git for Windows installed, everything works out of the box. See the Windows section in Installation for environment variable overrides and bootstrap logs.

\n

First use

\n

What kind of tasks is LazyCodex best at?\nLarge, long-running work where planning and verification matter. Small questions or one-line fixes can go straight to Codex without the harness.

\n

Do I need to study every skill before using it?\nNo. Skills auto-activate when a task matches their domain. Learn the four commands first; dig into individual skills when you hit a specific need.

\n

Which commands should I learn first?\n$init-deep for project memory, $ulw-plan for planning, $start-work for executing a plan, and $ulw-loop for open-ended tasks that need verified completion.

\n

How do I know the install worked?\nOpen Codex and type $ in the input — you should see OmO commands and skills listed. On the CLI, typing ulw should activate ultrawork mode. The first real command is usually $init-deep.

\n

The $ menu does not show any commands after install.\nOpen a new Codex session to reload the plugin, then check whether the startup review has a pending omo hook approval. If it still does not show, run npx lazycodex-ai doctor to check install and skill loading state.

\n

Execution & verification

\n

Is npx lazycodex-ai doctor a real thing?\nYes. It runs the OmO doctor flow and reports what is configured, what is missing, and why. Use it whenever something looks off.

\n

Why does it ask me to approve hooks?\nCodex reviews hooks at startup. The omo hooks do not run until you approve them. After each upgrade the hooks show as Modified because the plugin files changed — re-approve to pick up the new version.

\n

What should I check after an upgrade?\nIf hooks show as Modified, re-approve them. If anything looks pending or degraded, run npx lazycodex-ai doctor for the full picture.

\n

$ulw-loop keeps finishing too quickly — what do I do?\nIteration alone does not fix vague completion criteria. Be specific about what you want collected, what verification must pass, and what the agent should investigate when data is missing. Or run $ulw-plan first to nail down the scope.

\n

Do I need a bigger token budget?\nLazyCodex is not a token-saving tool. It pushes good models and enough tokens through planning, execution, and verification. For large tasks, split work into smaller units before a single thread gets too heavy.

\n

How do I pick a thinking/reasoning level?\nDo not overthink it. Avoid low; use medium for everyday work; use high when failure cost is significant or review matters; save xhigh for genuinely heavy tasks.

\n

Can LazyCodex do computer-use?\nIt can, if the Codex session has computer-use tools connected. LazyCodex does not provide those tools itself — it directs the agent to use them during workflows and enforces stronger verification when they are available.

\n

Conflicts & limits

\n

Can I use it on desktop and continue on mobile/remote?\nLazyCodex installs into Codex, so it works wherever Codex works. The Codex App's desktop/mobile remote flow pairs well. Some features may only be fully available on the desktop app.

\n

Team mode shows up but thread creation fails.\nUpdate LazyCodex and Codex to latest, then run npx lazycodex-ai doctor. Team mode depends on Codex desktop app features that may differ between App and CLI.

\n

Can I use OMX alongside LazyCodex?\nNot recommended. Running both together can cause conflicts that burn tokens and fail silently. If the installer warns about a conflict, remove one. LazyCodex is meant to run as the sole thin layer on top of Codex.

\n", "init-deep.md": "

$init-deep generates hierarchical AGENTS.md context so agents start from local guidance before touching a large repository. Run it once per project, and again whenever the architecture shifts enough that the existing context no longer reflects reality.

\n

What it produces

\n\n

When to run it

\n\n

How to use it

\n
$init-deep\n
\n

The command walks the tree, reads the files that define how the project actually works, and writes the context. Review the generated AGENTS.md files, trim anything stale, and commit them. Agents in later turns read that context before they edit, so the first session pays for every session after it.

\n

After init

\n

With context in place, move to $ulw-plan when the work needs a plan, or $ulw-loop for a single verified task.

\n", "ulw-plan.md": "

$ulw-plan is the strategic planning consultant (Prometheus). It turns an idea into a decision-complete work plan. It is a planner, NOT an implementer. When you say "do X" it produces a plan for X and never writes product code.

\n

The flow

\n
    \n
  1. Socratic interview — ask only the forks that exploration cannot resolve. When intent is fuzzy, research to best practice instead of interrogating.
    2. \n
  2. Parallel codebase exploration — fan out read-only subagents to ground every decision in the actual code, never in memory.
    3. \n
  3. Metis gap analysis — name every unknown the plan depends on and either close it or surface it as an explicit fork.
    4. \n
  4. Write the plan to plans/<slug>.md — one decision-complete plan a worker executes with zero further interview.
    5. \n
  5. Optional Momus high-accuracy review — an adversarial pass that tries to break the plan before it ships.
    6. \n
\n

Output

\n

Questions, research, and a work plan whose every todo carries references, acceptance criteria, a QA plan, and a commit boundary. The plan records status: awaiting-approval and waits — it never begins execution itself.

\n

Handoff

\n

Once you approve, hand the plan to $start-work, which executes it against durable Boulder state with the five evidence gates.

\n", "start-work.md": "

$start-work executes a Prometheus work plan until every top-level checkbox is done.

\n

How it works

\n\n

Syntax

\n
$start-work [plan-name] [--worktree <absolute-path>]\n
\n

Done

\n

It prints an ORCHESTRATION COMPLETE block when every checkbox is checked.

\n", "ulw-loop.md": "

$ulw-loop is a self-referential development loop that decomposes work into systematic, evidence-bound steps and runs until verified completion.

\n

How it works

\n

The agent works continuously and emits <promise>DONE</promise> when it believes the task is complete, but that does NOT end the loop. An Oracle must verify the result first. The loop ends only after the system confirms the Oracle verified it. If verification fails, it continues with the message: "Oracle verification failed. Continuing ULTRAWORK loop."

\n

Each step carries its own evidence: a real artifact, not a dry-run claim. Progress is checkpointed, so a long run survives restarts without losing what was already proven.

\n

Bootstrap

\n

Before the first run, the loop reads its full workflow reference (Bootstrap tier triage, the Execution Loop, and the Manual-QA channels table) so every later phase executes the same way. It only reads the sections the current phase needs.

\n

Manual-QA channels

\n

A step does not close on a status string. It closes on a captured artifact from a real surface — an HTTP call, a tmux session, or a browser — plus an adversarial pass and a cleanup receipt. See manual QA.

\n

Syntax

\n
$ulw-loop "task description" [--completion-promise=TEXT] [--strategy=reset|continue]\n
\n

Limits

\n

The iteration cap is 500 in ultrawork mode (100 in normal mode).

\n

Reading more

\n\n", "skills.md": "

Skills are specialist playbooks that LazyCodex loads on top of the command pillars. They auto-activate when a task matches their domain — you do not need to study or memorize them. Include ultrawork (or the short alias ulw) in your prompt and the harness picks the right skills internally.

\n

When you want to call a skill explicitly, put its name in the prompt: $review-work, $remove-ai-slops, $ulw-research, and so on.

\n

Commands

\n

The command pillars stay simple:

\n\n

Skills add specialist judgment around those pillars. The sections below describe each skill and how it is typically used.

\n

Skill index

\n

Most skills auto-activate when a request matches their domain, so you do not need to study or manually select every skill before using LazyCodex. When you want to be explicit, put the skill name in the prompt — for example $visual-qa, $git-master, or $ulw-research.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
SkillUse it for
init-deepHierarchical AGENTS.md context for large or old repos
ulw-planExplore-first planning before coding
ulw-loopEvidence-bound loop until verified completion
start-workExecute a plan with durable Boulder progress
review-workFive-lane parallel post-implementation review
remove-ai-slopsBehavior-preserving cleanup of AI-looking code
frontendDesigned UI work instead of generic layout filling
programmingStrict TypeScript, Rust, Python, or Go discipline, TDD-first
git-masterAtomic commits, rebase/squash, push safety, history investigation
visual-qaScreenshot/TUI diff plus dual-oracle visual QA
debuggingEvidence-led root-cause investigation
refactorBehavior-preserving restructure of existing code
ulw-researchMaximum-saturation research with codebase, web, official-docs, and OSS-repo swarms
LSPDiagnostics, definitions, references, symbols, and renames
lsp-setupConfigure language servers for a project
AST-grepStructural search and rewrite across code
rulesProject instructions from AGENTS, rules, and instruction files
comment-checkerFeedback after edit-like operations
\n

Skill highlights

\n
\n

review-work

\n

Five-lane parallel post-implementation review.

\n

After significant work, review-work launches five sub-agents in parallel — each covering a different angle: goal/constraint verification, hands-on QA execution, code quality, security, and context mining from git history and issues. All five must pass for the review to pass. One failure means the review fails.

\n

When it activates: After completing any meaningful implementation — especially when the change touches 3+ files or runs for 20+ minutes.

\n

Example: After finishing a PR, the user says:

\n
review my work\n
\n

The harness spawns five parallel reviewers in separate threads, each with a focused lens. The final verdict is PASS only when every lane agrees.

\n
\n

remove-ai-slops

\n

Behavior-preserving cleanup of AI-generated code smells.

\n

The safety invariant: regression tests lock behavior before a single line is deleted. Covers obvious comments, excessive defensive code, unnecessary abstractions, dead code, duplicates, and oversized modules (250+ pure LOC triggers a full modular refactoring). Workers run in parallel batches of five, and any test failure triggers an immediate revert.

\n

When it activates: When asked to clean, deslop, or remove AI-generated patterns.

\n

Example: Combining with refactor and programming for a full cleanup pass:

\n
ulw plan and manual qa, no behaviour changes, no regressions\n/refactor /remove-ai-slops through /programming\n
\n

The harness plans the cleanup first, locks behavior with tests, then dispatches parallel workers by slop category — safe to dangerous order.

\n
\n

frontend

\n

UI, UX, design, performance, accessibility, and visual QA — all in one router.

\n

Not a single rule file but a router. It reads design, perfection, and ui-ux-db references based on the task, then builds and verifies against the actual browser. Covers UI implementation, styling, layout, animation, Lighthouse 100, Core Web Vitals, accessibility, SEO, and React dev tools like react-scan and react-doctor.

\n

When it activates: Any task involving UI, styling, layout, animation, design, or performance auditing.

\n

Example:

\n
redesign the sidebar with better spacing and hit Lighthouse 100\n
\n

The skill routes to the right design references, builds to match the existing design system, then runs a real Playwright Chromium Lighthouse audit — never the Lighthouse CLI, never by weakening UX.

\n
\n

programming

\n

One philosophy across four languages: strict types, modern stacks, TDD.

\n

Applies to every .py, .pyi, .rs, .ts, .tsx, .mts, .cts, .go file. The skill gates on language, loads the matching reference set, and enforces: parse-don't-validate at boundaries, exhaustive variant matching, typed errors, no escape hatches (any, unwrap, @ts-ignore), 250 pure LOC ceiling per file, and mandatory TDD (RED → GREEN → REFACTOR).

\n

When it activates: Automatically on any code file edit in the supported languages.

\n

Example: The skill is always on. When editing TypeScript, it loads the TypeScript reference (Bun + Biome + strict tsconfig), enforces branded types and discriminated unions, and runs the post-write review loop: measure pure LOC, self-review seven questions, refactor if over 250 LOC.

\n
\n

debugging

\n

Hypothesis-driven runtime debugging across any language or binary.

\n

Every claim about why a bug happens must come from observed runtime state, not code reading. The skill runs a phased loop: setup and journal, form 3+ orthogonal hypotheses, investigate in parallel, escalate to independent verifiers after 2 failed rounds, confirm root cause by toggling, lock with a failing test, fix minimally, QA on the real surface, then clean up every debug artifact.

\n

When it activates: Crashes, silent failures, wrong responses, stuck processes, memory leaks, async misbehavior, or reverse engineering.

\n

Example:

\n
debug this — the API returns 200 but the body is empty\n
\n

The skill fires parallel investigation lanes, attaches real debuggers (pdb, node inspect, lldb, dlv), and does not close the bug until the root cause is confirmed by toggling and a failing test goes GREEN.

\n
\n

refactor

\n

Codemap-aware, LSP- and AST-grep-powered restructuring.

\n

Maps the codebase before touching anything, evaluates test coverage to set the verification strategy, plans atomic steps with rollback points, then executes with LSP renames and AST-grep structural rewrites. Any test failure during execution triggers an immediate stop and revert.

\n

When it activates: Requests to refactor, restructure, extract, simplify, or modernize code.

\n

Example:

\n
refactor the validation logic into its own module --scope=module\n
\n

The skill builds a dependency graph of the target, runs characterization tests to pin current behavior, then executes the restructuring step by step — verifying after each step.

\n
\n

visual-qa

\n

Screenshot and TUI diff plus dual-oracle visual QA.

\n

Captures reference and actual evidence — screenshots for web UIs, tmux capture-pane for terminal UIs — then runs a bundled pixel-diff or column-width script. Two parallel read-only oracle passes evaluate: one for design-system and functional integrity, one for visual fidelity and CJK text precision. The final verdict is a single good/bad score.

\n

When it activates: After building or changing any UI, or when asked to verify visual correctness.

\n
\n

git-master

\n

Atomic commits, rebase/squash, push safety, history investigation.

\n

Handles commit message style detection, semantic grouping, fixup autosquash, blame, bisect, log -S, and questions like "who wrote this" or "when was this added."

\n

When it activates: Any git operation — committing, rebasing, squashing, history search.

\n
\n

ulw-research

\n

Maximum-saturation research mode (formerly ultraresearch).

\n

Orchestrates parallel explore and librarian swarms across the codebase, the web, official documentation, and OSS repositories. Runs a recursive EXPAND loop driven by leads that workers return, verifies findings empirically by running code, and produces cited synthesis with optional reports.

\n

When it activates: Only on explicit demand — the word ulw-research, the legacy alias ultraresearch, or any request for deep research or an ultra-precise investigation.

\n

Example:

\n
ulw-research the typeclaw architecture — map every module and find the official docs\n
\n

The skill fans out 10+ parallel search lanes across GitHub, official docs, and web sources, recursively expands promising leads, then synthesizes a cited report.

\n
\n

LSP

\n

Language-server diagnostics, definitions, references, symbols, and safe renames.

\n

Gives the agent language-server precision via MCP tool calls. Runs diagnostics after every edit, finds definitions and references across the workspace, and performs safe renames through the language server's own workspace edit — not text find-and-replace.

\n

When it activates: Automatically after edit-like tool calls (diagnostics), and on demand for navigation and renames.

\n
\n

AST-grep

\n

Structural search and rewrite across 25 languages.

\n

Finds code by syntactic shape rather than text — every function call matching a pattern, every import shaped like X. Rewrites are deterministic and always previewed with dryRun=true before applying. Pairs with the refactor skill for safe, large-scale codemods.

\n

When it activates: Structural code matching, pattern-based search, or deterministic rewrites (strip as any, migrate require() to import, find empty catch blocks).

\n
\n

lsp-setup

\n

Language-server installation and workspace wiring.

\n

Configures language servers when a project does not already expose reliable diagnostics, definitions, references, and safe renames. It detects the language stack, installs or points to the right server, and validates that LSP calls work before higher-level coding or refactor skills depend on them.

\n

When it activates: When diagnostics are missing, definitions cannot be resolved, or a project needs LSP support before a refactor or programming task.

\n
\n

rules

\n

Project instruction injection from repository and user rule files.

\n

Automatically loads project instructions from sources such as AGENTS.md, CONTEXT.md, .omo/rules/, .claude/rules/, .github/instructions/, and .github/copilot-instructions.md. There is no command to run — the harness treats these rules as active context when the plugin is enabled.

\n

When it activates: At session start and prompt submission, so agents inherit project constraints before planning or editing.

\n
\n

comment-checker

\n

Immediate feedback after edit-like operations.

\n

After code changes, comment-checker inspects comments near the edited lines. If it flags comment drift — a comment that no longer matches the code below it — the agent must fix or justify the comment before proceeding. This catches stale comments at the moment they are introduced rather than during a later review.

\n

When it activates: After write, edit, patch, or other edit-like tool calls when the plugin has the guardrail enabled.

\n
\n

Where skills live

\n

LazyCodex installs skills as part of the OmO plugin. OmO can also load skills from project and user locations such as .codex/skills, ~/.codex/skills, .opencode/skills, ~/.config/opencode/skills, .claude/skills, .agents/skills, and ~/.agents/skills.

\n

LazyCodex installs the Codex Light setup with:

\n
npx lazycodex-ai install\n
\n

That installer wires the Codex marketplace plugin as omo@sisyphuslabs while keeping the public package alias easy to remember.

\n

Each skill carries deep internal references — detailed playbooks, language-specific recipes, and per-phase instructions — but none of that is something you need to read. The harness reads it for you when the skill activates.

\n

The command pillars and the disciplines behind them are covered in depth: ulw-plan, ulw-loop, start-work, TDD, manual QA, and git workflow.

\n", "ultrawork.md": "

ultrawork is the headline mode. Include ultrawork (or the short alias ulw) anywhere in your prompt — like adding ultrathink — and the harness switches to maximum-precision, outcome-first, evidence-driven orchestration. Skills activate internally; you do not need to name them.

\n
\n

"Plan, execute, verify, and keep the evidence attached."

\n
\n

The principle is simple. An agent saying it is done does not mean the work is done. The work is done when observable evidence verifies it.

\n

Usage

\n

Just include the word in your prompt. Nothing else to configure.

\n
ulw add authentication\n
\n
fix the flaky checkout test ultrawork\n
\n

The harness reads the task, picks the right skills (programming, debugging, refactor, etc.), and runs the evidence-bound loop automatically. You do not choose skills yourself unless you want to be explicit — for example $review-work or $ulw-research.

\n

What it enforces

\n\n

Relationship to $ulw-loop

\n

$ulw-loop is the command form of ultrawork discipline. The latest flow stores request, goals, success criteria, and an evidence ledger under .omo/ulw-loop:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
FileRole
.omo/ulw-loop/brief.mdOriginal request and persistent constraints
.omo/ulw-loop/goals.jsonGoals and success criteria
.omo/ulw-loop/ledger.jsonlpass, fail, block, steering, checkpoint records
\n

Saying "done" is not enough. Each success criterion requires evidence captured from a real surface, and that evidence must pass before the loop stops.

\n

The exact syntax and flags live in the $ulw-loop command docs.

\n

Failure limits

\n

The loop does not run forever. The latest $ulw-loop workflow uses these caps:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ConditionLimit
Iterations on one goal without a full pass5 cycles
Same failure on the same criterion3 times
\n

Evidence over hope

\n

The loop does not stop at "I wrote some code." It stops when the result is confirmed by evidence — what check ran and what it showed — not by the agent's expected status report.

\n

Position among commands

\n

$ulw-loop is one of several commands, each for a different shape of work.

\n

The typical flow: $ulw-plan produces a decision-complete plan, $start-work executes it checkpoint by checkpoint, and $ulw-loop keeps open-ended work running until a verifier approves. Detailed syntax for each command is in the Commands section.

\n", - "discipline-agents.md": "

LazyCodex ports a single discipline agent from OmO into Codex: Hephaestus, the autonomous deep worker. There is no Sisyphus orchestrator in the Codex package — Hephaestus is the one role, and it carries the whole run itself with read-only subagents for parallel exploration.

\n

What Hephaestus is

\n

Named after the Greek god of the forge. Goal-oriented: you give it objectives, not step-by-step recipes, and it executes them end-to-end. "The Legitimate Craftsman." Methodical, thorough, obsessive — built for deep architectural reasoning, complex debugging, and cross-domain synthesis.

\n

Installed roles

\n

As of 4.12.1, the following roles are installed. When Codex exposes agent_type, the role is set directly; otherwise the role description is included in the message as a fallback.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
RolePrimary use
explorerInternal codebase context: structure, call flows, test locations.
librarianExternal docs, library contracts, latest API research.
planPlan drafting and task decomposition.
momus / metisMissing decisions, edge cases, risk review.
lazycodex-executorExecuting specific task units from a plan.
lazycodex-code-reviewerPost-implementation code quality review.
lazycodex-qa-executorReal-execution-based QA.
lazycodex-gate-reviewerPre-completion verification gates.
lazycodex-clone-fidelity-reviewerClone and sync operation fidelity checks.
\n

Parent session ownership

\n

Even with multiple roles, completion judgment is never handed wholesale to a sub-agent. The parent Codex session keeps ownership of goals, constraints, and final judgment. Sub-agents are used to read terrain, find gaps, or assist review.

\n

The operating loop

\n

Hephaestus runs a short, tight loop on every unit of work:

\n
    \n
  1. Explore — map the terrain. Read the code with tools, never speculate. Fire 2-5 parallel explore subagents before writing anything.
    2. \n
  2. Plan — chart the course. Record files to modify, specific changes, and dependencies via update_plan.
    3. \n
  3. Implement — build with precision. Surgical edits that match codebase style (naming, indentation, imports, error handling) even when a greenfield would read differently.
    4. \n
  4. Verify — prove it works. LSP diagnostics on changed files, related tests, and build — in parallel where possible.
    5. \n
  5. Manually QA — drive the artifact through its real surface (HTTP call, tmux, browser), then write the final message.
    6. \n
\n

Non-goals

\n\n

Delegation, not orchestration

\n

Hephaestus stays the parent. For parallel exploration it spawns read-only Codex subagent roles (multi_agent_v1.spawn_agent) and keeps the parent session live with brief status updates while children run. It does not hand the run off to a separate orchestrator — it owns the goal, delegates the grunt work, and verifies the results itself.

\n

Boulder state

\n

$start-work uses .omo/boulder.json to persist progress and the Stop-hook continuation to keep plan execution moving. This is the core visible behavior: checkboxes advance, and when all are done it prints ORCHESTRATION COMPLETE.

\n

Where the boulder comes from

\n

The full OmO has a second primary agent, Sisyphus, the orchestrator with .omo/boulder.json session continuity. The Codex package is the Hephaestus-only light port, so on Codex the durable progress state lives in .omo/boulder.json as written by $start-work and the Stop-hook continuation — without the Sisyphus orchestration layer.

\n

Reading more

\n\n", + "discipline-agents.md": "

LazyCodex installs OmO's discipline-agent surface into Codex. Hephaestus remains the autonomous deep-worker voice for end-to-end implementation, while specialist roles support exploration, external research, planning, review, QA, and completion gates.

\n

What Hephaestus is

\n

Named after the Greek god of the forge. Goal-oriented: you give it objectives, not step-by-step recipes, and it executes them end-to-end. "The Legitimate Craftsman." Methodical, thorough, obsessive — built for deep architectural reasoning, complex debugging, and cross-domain synthesis.

\n

Installed roles

\n

The current install provides these roles. When Codex exposes agent_type, the role is set directly; otherwise the role description is included in the message as a fallback.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
RolePrimary use
explorerInternal codebase context: structure, call flows, test locations.
librarianExternal docs, library contracts, latest API research.
planPlan drafting and task decomposition.
momus / metisMissing decisions, edge cases, risk review.
lazycodex-executorExecuting specific task units from a plan.
lazycodex-code-reviewerPost-implementation code quality review.
lazycodex-qa-executorReal-execution-based QA.
lazycodex-gate-reviewerPre-completion verification gates.
lazycodex-clone-fidelity-reviewerClone and sync operation fidelity checks.
\n

Parent session ownership

\n

Even with multiple roles, completion judgment is never handed wholesale to a sub-agent. The parent Codex session keeps ownership of goals, constraints, and final judgment. Sub-agents are used to read terrain, find gaps, or assist review.

\n

The operating loop

\n

Hephaestus runs a short, tight loop on every unit of work:

\n
    \n
  1. Explore — map the terrain. Read the code with tools, never speculate. Fire 2-5 parallel explore subagents before writing anything.
    2. \n
  2. Plan — chart the course. Record files to modify, specific changes, and dependencies via update_plan.
    3. \n
  3. Implement — build with precision. Surgical edits that match codebase style (naming, indentation, imports, error handling) even when a greenfield would read differently.
    4. \n
  4. Verify — prove it works. LSP diagnostics on changed files, related tests, and build — in parallel where possible.
    5. \n
  5. Manually QA — drive the artifact through its real surface (HTTP call, tmux, browser), then write the final message.
    6. \n
\n

Non-goals

\n\n

Delegation and orchestration

\n

The parent Codex session keeps final ownership of goals and verification. For parallel work it can spawn Codex subagent roles and keep the parent session live with brief status updates while children run. Team mode adds a durable named-team surface when coordination is worth the overhead.

\n

Boulder state

\n

$start-work uses .omo/boulder.json to persist progress and the Stop-hook continuation to keep plan execution moving. This is the core visible behavior: checkboxes advance, and when all are done it prints ORCHESTRATION COMPLETE.

\n

Where the boulder comes from

\n

OmO's broader orchestration ideas show up in Codex through durable .omo/boulder.json progress, Stop-hook continuation, named team state, and reviewer/gate roles. $start-work is the main visible path: it advances the plan until every checkbox is done and the final gate is satisfied.

\n

Reading more

\n\n", "model-routing.md": "

Multi-model routing sends each part of a run to the model that fits it best, instead of running everything on one model. LazyCodex installs OmO's routing defaults into Codex so a serious repository is not bottlenecked by a single context window or price point.

\n

Current baseline

\n

The 4.12.1 bundled model-catalog.json centers the default profile on gpt-5.5:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ProfileModelReasoning
Defaultgpt-5.5high
Plan modegpt-5.5xhigh
Workergpt-5.5high
Verifiergpt-5.5high
\n

The actual model name you see may differ as Codex and OpenAI update their model lineup. This doc focuses on how LazyCodex uses model profiles, not on comparing specific models.

\n

What gets routed

\n\n

Why role profiles exist

\n

Role-based profiles separate work by nature:

\n\n

This pairs with Agent Roles. Even when multiple roles move in parallel, each role's model profile is tracked in the Codex configuration.

\n

How it fits the harness

\n

Routing is part of the harness setup that npx lazycodex-ai install wires into Codex. It detects the available subscriptions and provider auth, then maps roles to models so you do not hand-configure each one.

\n

Provider auth

\n

Auth targets Codex itself, not LazyCodex. Once Codex is logged in, the installer's subscription detection and provider routing take over. If you let an LLM agent run the install, it walks the same detection and selection for you.

\n

User notes

\n\n

Customizing it

\n

Routing and provider settings live in the configuration. See Configuration for the fields that control which model handles which role, and how to override the defaults per project.

\n", "hooks-lifecycle.md": "

Hooks and lifecycle are how the harness keeps a long run moving without you re-prompting every turn. OmO installs lifecycle hooks into Codex that observe each turn and decide what happens next.

\n

Trigger matrix

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
EventWhat fires
SessionStartProject rules loading, telemetry, auto-update check, bootstrap provisioning, CodeGraph bootstrap.
UserPromptSubmitProject rules re-injection, ultrawork trigger detection, $ulw-loop steering.
PreToolUseGit Bash MCP guidance on Bash calls, $ulw-loop goal budget protection on goal creation.
PostToolUseComment checker, LSP diagnostics, CodeGraph init guidance, apply_patch rule matching, thread title hygiene.
Stop / SubagentStop$start-work continuation, LazyCodex executor evidence verification.
PostCompactGit Bash notification, project rules, and LSP diagnostics cache resets.
\n

The core mechanism

\n

A Stop-hook fires when a turn ends. If a plan is still in progress, the hook re-injects the next turn automatically — the agent continues from durable progress state instead of waiting for you to say "continue". The run only stops when the plan is complete or a gate fails in a way that needs a human.

\n

Where progress lives

\n

Progress state is written to .omo/boulder.json and survives across turns and sessions. That is what lets $start-work resume a plan after a restart, and what keeps $ulw-loop honest about how far it has actually gotten.

\n

Approval and trust

\n

Hooks never run before approval. On the first launch after install, Codex's startup review asks you to approve the omo hooks. After every upgrade the hooks show as Modified — expected, because the plugin files changed and the previous trust hashes no longer match — re-approve and the next session re-runs bootstrap on the new version.

\n

Evidence gates

\n

During execution the lifecycle enforces five evidence gates before a step can close: plan reread, automated verification, manual-QA, adversarial QA, and cleanup. A step that cannot pass its gates does not advance, regardless of what the status text claims.

\n

Installed components

\n

The hooks above are thin entry points into these installed components:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ComponentResponsibility
rulesProject rules at session start, prompt submit, apply_patch, and post-compact.
bootstrapLazyCodex install state and provisioning checks.
telemetrySession start recording.
comment-checkerComment feedback after edit-like tool calls.
lspLanguage-server diagnostics after edit-like tool calls and cache reset after compact.
ultraworkUltrawork trigger detection at prompt submit.
ulw-loopLoop steering and goal budget protection.
start-work-continuation$start-work execution continuation.
git-bashGit Bash MCP guidance on Bash calls and post-compact.
codegraphCodeGraph bootstrap and init guidance.
teammodeThread title hygiene checks.
lazycodex-executor-verifySub-agent evidence verification.
\n

Reading more

\n\n", "git-workflow.md": "

Git work runs through the git-master skill. It is exact, conservative, and evidence-led: the agent reads the repository state before it infers anything, and never commits, rebases, pushes, force-pushes, resets, or stash-pops unless you explicitly asked for that operation.

\n

Mode gate

\n

Every request is classified first:

\n\n

Investigative requests report findings and stop.

\n

Commit mode

\n

Commits are atomic by behavior, module, and revertability. The agent detects message style from recent history (dominant pattern, language, casing — it does not default to Conventional Commits unless the repo uses them), inspects the full diff, and stages by path or hunk so each commit contains only its group. Implementation and its direct tests land together; unrelated concerns split into separate commits. Before each commit it verifies git diff --staged --stat; after, git log -1 --oneline.

\n

Rebase and merge

\n

History rewriting is a shared-impact operation. The agent never rebases or rewrites main, master, dev, release, or protected branches unless you named that exact operation. If commits may already be pushed, it asks before force-pushing and uses --force-with-lease, never plain --force. Conflicts are resolved by intent — never a blind ours/theirs. If a rebase goes wrong, git rebase --abort is the first move; the reflog is the recovery path, explained before use.

\n

Push safety

\n

Before any write to history: the current branch is known, dirty work is accounted for, upstream/pushed status is known or explicitly unknown, the operation matches your request, and the recovery path is known. Afterward it runs the cheapest relevant verification and leaves the worktree state explicit.

\n

Reading more

\n\n", "tdd.md": "

Strict test-driven development is the discipline that lets the harness call work "done" without hoping. Every change follows the red → green → refactor loop, in that order. Reverse it and you have written speculative code.

\n

The order

\n
    \n
  1. Red. Write a failing test that names the behavior in Given / When / Then. Run it. Confirm it fails for the right reason — not a typo or a missing import.
    2. \n
  2. Green. Write the minimum code to make it pass. Resist the second case until the first passes; the second case is the next red.
    3. \n
  3. Refactor. With the test green, restructure ruthlessly. If the test is hard to refactor against, the test is bad — fix it before the code.
    4. \n
\n

The test pyramid

\n

Every feature ships all three rungs: many fast units (pure-function correctness across happy, edge, boundary, and error paths, < 10 ms each), some integrations against the real downstream via testcontainers or httptest (< 1 s each), and a few E2E scenarios that drive the binary through its real surface and assert the observable outcome. A feature with zero E2E coverage is undone, even if every unit passes.

\n

Deterministic, or it is broken

\n

A test that passes 9 of 10 times is failing 10% of the time. Forbidden in test bodies unless time itself is the system under test: setTimeout(resolve, N), await sleep(N), "wait long enough for X". The replacement is subscribe-first, timeout-bound — register the listener before the trigger, then race against an explicit circuit breaker that fails with a useful message on timeout. The whole repo must pass bun test in one process, one go, no isolation flags, no retries.

\n

Prompt tests assert behavior, not text

\n

When testing code that builds an LLM prompt, never pin the current wording (toContain("You are Sisyphus"), toMatchSnapshot, toBe(EXPECTED_PROMPT)). Assert the structural invariant the logic enforces — the conditional branch, the negative branch, the redaction, the skill inclusion/exclusion. Test what would break the behavior, never what would only break a diff.

\n

The five evidence gates

\n

During execution the lifecycle enforces five gates before a step can close: plan reread, automated verification, manual QA, adversarial QA, and cleanup. A step that cannot pass its gates does not advance, regardless of what the status text claims.

\n

Reading more

\n\n", "manual-qa.md": "

Manual QA is the gate that turns "it should work" into "it works, here is the proof". No step closes on a status string; it closes on a captured artifact from a real surface, plus an adversarial pass and a cleanup receipt. Two skills carry this: visual-qa for UI surfaces, review-work for whole-implementation review.

\n

visual-qa

\n

For any UI you built or changed — web page or TUI — visual QA runs three phases. First it captures objective reference evidence with a bundled diff script: image-diff for screenshots (similarity score, hotspots, alphaChannelIntact), tui-check for terminal captures (maxWidth, overflowLines, borderMisaligned, wide-char columns). That JSON is reference, not the verdict.

\n

Then it dispatches two read-only oracle subagents in parallel:

\n\n

The harness synthesizes the two passes into one PASS | REVISE | FAIL verdict with located findings.

\n

review-work

\n

After significant implementation, review-work launches five parallel background subagents. All five must pass for the review to pass; if one fails, the review fails.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
LaneRoleAsks
1Goal VerifierDid we build what was asked?
2QA ExecutorDoes it actually work?
3Code ReviewerIs the code well-written?
4Security AuditorIs it secure?
5Context MinerDid we miss any context?
\n

Oracle lanes receive the diff plus full file contents in the prompt (they cannot read files). A crashed, BLOCKED:, or inconclusive lane is never counted as a pass — it is respawned smaller, and if the retry budget is exhausted it stays INCONCLUSIVE while the aggregate result still emits.

\n

Adversarial classes and cleanup

\n

Within $start-work, every checkbox probes each applicable adversarial class and records the observable result for each; skipped classes need a one-line not-applicable reason in the ledger. Every QA resource — scripts, tmux assets, browser sessions, PIDs, ports, containers, temp dirs — is registered as its own teardown todo and executed with a captured receipt. No QA asset is left running.

\n

Reading more

\n\n", - "configuration.md": "

LazyCodex is a thin distribution layer over OmO. The configuration that the installer writes into Codex controls model routing, hooks, skills, and the agent roles the harness uses.

\n

Zero-config by default

\n

LazyCodex ships with sensible defaults and works immediately after install. You only need to touch configuration when the defaults do not fit your repository. There are no config files to create in advance — install and start working.

\n
npx lazycodex-ai install\n
\n

No global install. Always npx. This is shorthand for npx --yes --package oh-my-openagent omo install --platform=codex.

\n

Codex target

\n

LazyCodex always targets Codex. The --platform=codex argument is baked into the lazycodex-ai bin's install path, so the harness connects to the OpenAI Codex CLI and not another platform. You do not pass --platform yourself.

\n

Prerequisites:

\n\n

Where config lives

\n\n

Install flags

\n

The default installer is interactive (TUI). It detects subscriptions, helps with model selection, and walks provider auth.

\n
npx lazycodex-ai install\n
\n

For a fully autonomous, prompt-free setup, add both flags together:

\n
npx lazycodex-ai install --no-tui --codex-autonomous\n
\n

--no-tui --codex-autonomous are passed through to omo install — the lazycodex-ai bin does not interpret them itself. It is strongly recommended to let an LLM agent run the install: the agent handles subscription detection, model selection, and provider auth automatically.

\n

What you can tune

\n\n

Hooks & lifecycle

\n

Hooks never run before approval. On the first launch after install, Codex's startup review asks you to approve the omo hooks. After every upgrade the hooks show as Modified — expected, because the plugin files changed and the previous trust hashes no longer match. Re-approve and the next session runs the new version's bootstrap.

\n

Provider & model settings

\n

Provider and model settings are managed by OmO, not LazyCodex directly. During install, OmO reads the Codex configuration and the bundled model-catalog.json to align model profiles — this is the model routing layer.

\n\n
\n

Do not fabricate provider keys. Supply the key your chosen provider documents, via the environment, and let the installer's routing interpret it.

\n
\n

Diagnosing config

\n

If something looks pending or degraded, run:

\n
npx lazycodex-ai doctor\n
\n

It explains what is misconfigured and why, and points at the specific field to fix. It checks plugin cache, hooks, MCP servers, agent roles, and Codex config state.

\n

Re-running setup

\n

The installer is idempotent. Re-running npx lazycodex-ai install rewrites the config blocks, agent roles, and bin links on top of what is there, so it is safe to run after editing configuration by hand.

\n

See the CLI reference for every command the installer exposes.

\n", + "configuration.md": "

LazyCodex is a thin distribution layer over OmO. The configuration that the installer writes into Codex controls model routing, hooks, skills, and the agent roles the harness uses.

\n

Zero-config by default

\n

LazyCodex ships with sensible defaults and works immediately after install. You only need to touch configuration when the defaults do not fit your repository. There are no config files to create in advance — install and start working.

\n
npx lazycodex-ai install\n
\n

No global install. Always npx. This is shorthand for npx --yes --package oh-my-openagent omo install --platform=codex.

\n

Codex target

\n

LazyCodex always targets Codex. The --platform=codex argument is baked into the lazycodex-ai bin's install path, so the harness connects to the OpenAI Codex CLI and not another platform. You do not pass --platform yourself.

\n

Prerequisites:

\n\n

Where config lives

\n\n

Install flags

\n

The default installer is interactive (TUI). It detects subscriptions, helps with model selection, and walks provider auth.

\n
npx lazycodex-ai install\n
\n

For a fully autonomous, prompt-free setup, add both flags together:

\n
npx lazycodex-ai install --no-tui --codex-autonomous\n
\n

--no-tui --codex-autonomous are passed through to omo install — the lazycodex-ai bin does not interpret them itself. It is strongly recommended to let an LLM agent run the install: the agent handles subscription detection, model selection, and provider auth automatically.

\n

What you can tune

\n\n

Hooks & lifecycle

\n

Hooks never run before approval. On the first launch after install, Codex's startup review asks you to approve the omo hooks. After every upgrade the hooks show as Modified — expected, because the plugin files changed and the previous trust hashes no longer match. Re-approve and the next session runs the new version's bootstrap.

\n

Provider & model settings

\n

Provider and model settings are managed by OmO, not LazyCodex directly. During install, OmO reads the Codex configuration and the bundled model-catalog.json to align model profiles — this is the model routing layer.

\n\n
\n

Do not fabricate provider keys. Supply the key your chosen provider documents, via the environment, and let the installer's routing interpret it.

\n
\n

Diagnosing config

\n

If something looks pending or degraded, run:

\n
npx lazycodex-ai doctor\n
\n

It explains what is misconfigured and why, and points at the specific field to fix. It checks plugin cache, hooks, MCP servers, agent roles, and Codex config state.

\n

Re-running setup

\n

The installer is idempotent. Re-running npx lazycodex-ai install rewrites the config blocks, agent roles, and bin links on top of what is there, so it is safe to run after editing configuration by hand.

\n

See the CLI reference for every command the installer exposes.

\n", "deploy.md": "

The docs site at lazycodex.ai deploys automatically to Cloudflare Workers. There is no manual publish step for the web — a push to main that touches the web package ships it.

\n

Trigger

\n

The Web Deploy (Cloudflare Workers) workflow runs on push to main when packages/web/** or the workflow file itself changes, and on manual workflow_dispatch. A concurrency group keyed by ref serializes runs and never cancels an in-flight deploy.

\n

Build

\n

Inside packages/web, the prebuild step regenerates lib/docs-content.generated.ts from content/docs/*.md. The site is then built with OpenNext for Cloudflare (pnpm exec opennextjs-cloudflare build).

\n

Deploy

\n

cloudflare/wrangler-action@v4 runs wrangler deploy (or deploy --env <environment> when an environment is supplied) against the web-production environment, whose URL is https://lazycodex.ai.

\n

Post-deploy smoke checks

\n

The workflow fails the job if any check breaks:

\n\n

A PageSpeed Insights pass audits the live URL for Lighthouse 100/100/100/100 across performance, accessibility, best-practices, and SEO, on both mobile and desktop. It is non-blocking here because PSI shared quota throttles frequent CI; the gating Lighthouse check runs in web-ci.yml via real Playwright Chromium.

\n

Local preview

\n
cd packages/web\npnpm preview   # opennextjs-cloudflare build && preview\npnpm deploy    # build && deploy (requires Cloudflare auth)\n
\n

Reading more

\n\n", "cli.md": "

The lazycodex-ai CLI is the entry point for installing and diagnosing the harness. It is meant to be run through npx — never install it globally.

\n

Forwarding to OmO

\n

The bin reads its arguments and forwards them to oh-my-openagent. The install subcommand is special-cased to lock the Codex platform target; everything else passes through as-is.

\n

install expands to:

\n
npx lazycodex-ai install\n# → npx --yes --package oh-my-openagent omo install --platform=codex\n
\n

Arguments after install are appended verbatim:

\n
npx lazycodex-ai install --no-tui --codex-autonomous\n# → npx --yes --package oh-my-openagent omo install --platform=codex --no-tui --codex-autonomous\n
\n

Other subcommands forward without the platform lock:

\n
npx lazycodex-ai <args...>\n# → npx --yes --package oh-my-openagent omo <args...>\n
\n

install

\n
npx lazycodex-ai install\n
\n

Installs the OmO agent harness into Codex: commands, skills, hooks, model routing, and verification defaults in one pass.

\n

To skip the TUI and let the installer run autonomously:

\n
npx lazycodex-ai install --no-tui --codex-autonomous\n
\n

--dry-run

\n

Place --dry-run as the first argument to print the resolved npx command without executing it:

\n
npx lazycodex-ai --dry-run install --no-tui --codex-autonomous\n
\n

Output:

\n
npx --yes --package oh-my-openagent omo install --platform=codex --no-tui --codex-autonomous\n
\n

--dry-run is stripped before forwarding, so the remaining arguments are interpreted exactly as they would be in a real run. Use it to verify the exact omo call before executing.

\n

doctor

\n
npx lazycodex-ai doctor\n
\n

Prints a health report: what is configured, what is missing, and why. Checks plugin cache, hooks, MCP servers, agent roles, and Codex config state. Run this first when a hook is pending, a skill is not loading, or routing looks wrong.

\n

Prerequisites

\n\n
\n

Do not use npm install -g or bun add -g. Always invoke via npx.

\n
\n

Marketplace alternative

\n

As an additive, experimental path you can install from inside Codex: type /plugins, open the Add Marketplace tab, and enter https://github.com/code-yeongyu/lazycodex, then install omo from the sisyphuslabs marketplace. Or from the CLI:

\n
codex plugin marketplace add https://github.com/code-yeongyu/lazycodex\ncodex plugin add omo@sisyphuslabs\n
\n

Upgrade with codex plugin marketplace upgrade sisyphuslabs. After an upgrade the hooks show as Modified — expected, because plugin files changed and the previous trust hashes no longer match. Re-approve and the next session runs the new version's bootstrap.

\n

The npx installer above stays the primary path. See Installation for the full walkthrough.

\n

Exit behavior

\n

The bin executes the resolved command with inherited stdio and exits with that command's status code. If npx itself fails to spawn, it prints the error and exits non-zero.

\n

In-session commands

\n

Once installed, LazyCodex registers OmO commands inside Codex. These are $command invocations in the Codex input — not shell commands. Syntax and usage flows are collected in the Commands section.

\n" }; @@ -409,8 +409,8 @@ export const DOC_TOC: Record = { }, { "level": 3, - "id": "delegation-not-orchestration", - "text": "Delegation, not orchestration" + "id": "delegation-and-orchestration", + "text": "Delegation and orchestration" }, { "level": 3, diff --git a/packages/web/lib/github-stars-format.ts b/packages/web/lib/github-stars-format.ts index c61ac9d..e0f6f77 100644 --- a/packages/web/lib/github-stars-format.ts +++ b/packages/web/lib/github-stars-format.ts @@ -1,4 +1,4 @@ -export const FALLBACK_GITHUB_STARS = 1_864 +export const FALLBACK_GITHUB_STARS = 2_375 export function formatStarsCount(stars: number): string { if (stars >= 1_000_000) { diff --git a/packages/web/lib/site-config.ts b/packages/web/lib/site-config.ts index 5b851de..4b4dc56 100644 --- a/packages/web/lib/site-config.ts +++ b/packages/web/lib/site-config.ts @@ -8,34 +8,34 @@ export const SITE_CONFIG = { siteUrl: "https://lazycodex.ai", docsPath: "/docs", version: "v0.2.2", - eyebrow: "A LIGHT PORT OF OMO'S HEPHAESTUS, FOR CODEX", + eyebrow: "OMO AGENT HARNESS FOR CODEX", wordmark: "LazyCodex", - heroLineA: "The Hephaestus deep-worker agent, ported light into Codex.", + heroLineA: "The one and only agent harness for complex codebases.", heroLineB: { - prefix: "A focused slice of ", - slot: "OmO", - suffix: " — goals not recipes, ", - keyword: "verified completion", + prefix: "Project memory, planning, execution, and ", + slot: "verified completion", + suffix: " inside ", + keyword: "Codex", period: ".", }, - harnessPillars: ["goals not recipes", "parallel exploration", "verified completion"], + harnessPillars: ["project memory", "parallel agents", "verified completion"], ultraworkTagline: "ultrawork turns the harness into a verified run.", ultraworkExample: "ulw add authentication", omoIntro: { kicker: "Where it comes from", - title: "A light port of OmO's Hephaestus", - body: "OmO is the full agent harness — a primary orchestrator, a deep worker, specialist agents, multi-model routing, and dozens of lifecycle hooks. LazyCodex does not ship all of that. It ports one role, Hephaestus, into Codex as a focused, repeatable setup: the deep worker plus the workflows that keep its runs honest.", - omoLabel: "OmO — the full harness", + title: "OmO, packaged for Codex", + body: "LazyCodex packages OmO as the Codex agent harness for complex codebases. It brings the discipline agents, parallel orchestration, skills, hooks, model routing, diagnostics, and verified-completion defaults into a repeatable Codex setup.", + omoLabel: "OmO — the core harness", omoPoints: [ - "Sisyphus orchestrator with boulder.json session continuity", - "Hephaestus deep worker + specialist agents", - "54+ lifecycle hooks, multi-model routing, team mode", + "Discipline agents: Sisyphus, Hephaestus, Oracle, Librarian", + "Parallel orchestration, multi-model routing, team mode", + "Lifecycle hooks, skills, diagnostics, and project memory", ], - lazyLabel: "LazyCodex — the Hephaestus port", + lazyLabel: "LazyCodex — the Codex distribution", lazyPoints: [ - "Hephaestus only: goals, not step-by-step recipes", - "$ulw-plan / $start-work / $ulw-loop workflows", - "Skills, hooks, and verification defaults for Codex", + "npx installer plus Codex marketplace plugin path", + "$init-deep / $ulw-plan / $start-work / $ulw-loop", + "Agent roles, MCP tools, hooks, and verification defaults", ], }, hephaestus: { @@ -57,7 +57,7 @@ export const SITE_CONFIG = { kicker: "What LazyCodex wires into Codex", title: "Harness the whole codebase", intro: - "LazyCodex installs OmO as a serious agent harness for complex repositories: project memory, planning, execution, skills, hooks, model routing, and verification defaults in one pass.", + "LazyCodex should be judged by the features it actually installs: project memory, planning, execution, verified completion, skills, hooks, model routing, and diagnostics.", points: [ { label: "Context that survives", @@ -76,8 +76,8 @@ export const SITE_CONFIG = { builtInSkills: { title: "Built-in skill coverage", summary: - "Skills auto-activate when a task matches their domain, so you do not need to study every one first. Add a skill name to your prompt when you want to call it explicitly; ulw-research is the maximum-saturation mode for deep codebase, web, official-docs, and OSS-repo research.", - skills: ["ulw-research", "review-work", "remove-ai-slops", "frontend", "programming", "visual-qa", "LSP", "AST-grep"], + "The command layer stays simple. The skill layer adds specialist judgment for review, cleanup, frontend work, programming discipline, LSP diagnostics, structural search, rules loading, and post-edit feedback.", + skills: ["init-deep", "review-work", "remove-ai-slops", "frontend-ui-ux", "programming", "LSP", "AST-grep", "comment-checker"], }, // Copy grounded in content/docs/ultrawork.md and ulw-loop.md — see .omo/evidence/copy-ledger.md. ulwDemo: {