iTranslated by AI

The content below is an AI-generated translation. This is an experimental feature, and may contain errors. View original article
💨

Delegating Design to Claude and Implementation to Codex: Introducing dual-loop-simple

に公開

3-Line Summary

  • I created a skill that lets Claude Code handle only the "design" while delegating "implementation, review, and fixes" entirely to Codex CLI.
  • It involves 5 phases, takes 10–20 minutes, and rejects execution on the main branch.
  • I want to hand it over to Codex.

The Trigger

I downgraded my Claude Code usage from 20x to 5x and subscribed to ChatGPT Pro. Since I have Codex, I wanted to take advantage of it, but I found myself falling into the habit of completing everything with Claude Code, or perhaps I just found the switching process tedious.

I use Claude Code's /feature-dev quite heavily, and I wanted to keep that conversational design process but offload the actual implementation to Codex.

Role Task
Claude (main) Intent understanding, conversational design, orchestration
Codex Implementation, committing, review, and fixes

This likely already exists, but here we are.

dual-loop and dual-loop-simple

I originally created a skill called dual-loop, but it became too heavy with "8 phases, up to 7 parallel subagents, A/B design options, and multiple fix loops." So, I created a simpler version.

Item dual-loop dual-loop-simple
Number of phases 8 5
Parallel subagents Max 7 0–1 (Explore optional)
Design options A/B 2 options 1 option
Task breakdown Explicit tasks.md Codex discretion
Fix loops Max 5 times Fixed at 1 time
state.json Yes (Resumable) None
Estimated time 30–60 minutes 10–20 minutes

I trimmed down various parts, making it a skill solely for handing off to Codex.

Flow of the 5 Phases

Phase 0: Prerequisite Check

  • main / master branch → Denied
  • If there are uncommitted changes → Ask whether to stash, discard, keep, or abort.
  • If codex --version / which ai-commit-msg fails → Abort.

Phase 1: Intent Understanding + Conversational Design

  1. Extract What / Where / Constraints from the user utterance into intent.md.
  2. If there is a mention of existing code, launch only one Explore subagent to generate exploration.md.
  3. Claude presents one design option → User approval.
  4. Finalize design.md.

This stage is entirely Claude's domain. We refine the details through conversation.

Phase 2: Codex Autonomous Implementation

codex exec "Implement the feature described in .planning/dual-loop-simple/design.md.
- Break the work into logical commits yourself.
- Use ai-commit-msg for each commit message.
- Run project tests if present." > /tmp/dls-impl.log 2>&1

Task breakdown and commits are left to Codex. The design is handed off entirely. The stdout must never be returned to the main process (redirected to /tmp/, checking only tail -5 to confirm exit).

Phase 3: Codex Review + One Automated Fix

codex exec "Adversarially review the branch diff against design.md.
Tag findings [CRITICAL]/[WARNING]/[INFO]. Write to review.md."

Count the number of [CRITICAL] items with grep -c:

  • 0 items → Proceed to summary.
  • 1 or more items → Execute only 1 fix → Re-review → Record remaining items in the summary.

Not looping is the key to the simple version. It eliminates the risk of infinite loops.

Phase 4: Summary

Summarize the changed files, review results, and remaining issues in summary.md.

Core Rules for Saving Context

Even in the simple version, I inherited 4 rules from dual-loop:

  1. Main does not read the full contents of generated files — Read only tmp files extracted via grep / sed -n.
  2. Do not return codex exec stdout to main — Redirecting to > /tmp/dls-*.log is mandatory.
  3. Subagent launch is limited to 1 optional instance — No parallel fan-out.
  4. Do not create state — Single-pass flow, no resume support.

Rule 1 is particularly effective. Even if review.md is 500 lines long, main only reads the output of grep -c '\[CRITICAL\]' (a single number) and /tmp/dls-critical.md (containing grep -A3 '\[CRITICAL\]').

Read policy table:

Type Example Main Access
Code files src/** Read Forbidden (Only via Explore)
Artifacts exploration.md, review.md Full Read Forbidden (Via grep)
Main-created files intent.md, design.md, summary.md Read/Edit Allowed
tmp /tmp/dls-* Read Allowed
git diff git diff main..HEAD Read Allowed (Exception)

When to Use

Cases to choose 'simple':

  • Design is already somewhat solidified.
  • Adding a single feature or a small refactoring.
  • When you want to throw it to Codex and see the results quickly in 10–20 minutes.

Cases to choose 'dual-loop' (main):

  • Requirements are vague, and you need to compare design alternatives.
  • You need to investigate extensively with parallel Explore.
  • You need to run multiple review/fix cycles for large-scale tasks.

The premise is that you can switch to dual-loop if you feel it's "insufficient." The reverse is not anticipated.

Design Trade-offs

Things discarded

  • Comparison of Design A/B options — If it gets stuck on one option, adjusting it through 2 rounds of dialogue usually resolves it.
  • Multiple fix loops — If CRITICAL issues are not resolved in one round, it's a signal that the Codex-side premise is broken. Don't run it mechanically; move to human-in-the-loop.
  • state.json / resume — Since the goal is 10-minute completion, the need to resume is low.

Things retained

  • Design approval gate — Skipping this makes the cost of redoing a "misaligned implementation" the highest.
  • 1 optional Explore — Fired only when depending on existing code. Skipped for purely new features.
  • ai-commit-msg enforcement — Local LLM (qwen3.5:4b) provides sufficient quality commit messages in 5 seconds.

Usage Image

User: Add pagination to user search API using dual-loop-simple
Claude:
  Phase 0: Check OK
  Phase 1: Confirm intent.md → Launch Explore → Present design.md (limit/offset method)
  User: Approve
  Phase 2: codex exec ... (3 commits generated, test pass)
  Phase 3: 0 CRITICAL items in review
  Phase 4: Write summary.md, propose /ship

I wanted to keep the tempo as brisk as possible, but...

Summary

  • It is fast to divide roles between Claude's dialogue design power and Codex's autonomous implementation power.
  • Memory load for orchestration becomes zero if made into a Skill.
  • Use dual-loop for elaborate control, and dual-loop-simple when you want to flow through tasks quickly.

It turned out well, but I still habitually include /feature-dev out of habit. Perhaps I need a skill/hook that suggests, "Wouldn't it be better to use this skill for this content?"

Discussion