Pumasi

English | 한국어 | 中文 | 日本語 | Español

pumasi
Parallel coding orchestration — Claude as PM, Codex CLI as your dev team.

Delegate the building to Codex. Keep the thinking for Claude.

Using OMO, Codex, or another host? The current session remains the controller;
start --host omo selects Claude Code as the default worker. Explicit task or
default commands still win. Use the direct Node runner without installing
Claude-specific hooks: host/worker guide. The examples
below describe the original Claude Code host mode.

Quick Start • Why pumasi? • How it works • Features • Requirements

Quick Start

1. Add the marketplace (once)

2. Install

Restart Claude Code after installation.

3. Install prerequisites

4. Run

Or trigger naturally — pumasi auto-activates when 3+ independent modules are detected.

Why pumasi?

- Claude does not write code — It designs interfaces, writes signatures, and sets requirements. Codex does the actual implementation. Claude tokens stay cheap.
- N modules in parallel — Three independent modules take the same wall time as one. Five modules, same story.
- Zero-token validation — Each task gets a bash-based gate (type-check, build, test). Gates run without consuming Claude tokens.
- Dependency-aware rounds — Tasks with dependencies get split into rounds. Round 1 completes before Round 2 starts. No integration surprises.
- Codex-aware instructions — Codex does not infer context. Pumasi writes absolute paths, function signatures, required imports, and hard constraints into every instruction — but never the function body.

How it works

7-phase workflow

Features

Role separation

When to use pumasi

When NOT to use pumasi

- Bug fixes or modifications to existing code (context injection becomes too heavy)
- Single-file work (no parallel benefit)
- Tasks…