Try Intent-System→
Product

Three threads, six steps — how Intent-System actually runs

The Design / Implementation / Review threads are not metaphors. Implementation and Review are two Claude sessions, each on /loop 5m, each in its own cwd. The design thread runs at human pace; the other two run continuously. Today this produces roughly 10 packets in 3 hours per active domain.

Intent-System · Step 2 of 7↑ Overview
  1. 01Current Flow
  2. 023 Threads × 6 Steps
  3. 03Intent Tree
  4. 04Unified Intents
  5. 05Human + AI Assignment
  6. 06Review & Closeout Loop
  7. 07Roadmap
Design threadhuman + LLMImplementation threadClaude /loop 5mReview threadClaude /loop 5m · separate cwdApprove → merge → re-evaluate next packet (back to ③)▸ Issue▸ submit PR▸ Decline + comment▸ updated PR①Intent treePurpose / Context / Means②Generate packetsLLM slices work from intent③Cut as GitHub Issuespacket → issue (carries why)④Implement → open PRClaude /loop 5m (impl cwd)⑥Apply review commentspush, re-request review⑤PR reviewClaude /loop 5m (review cwd)

Approve on ⑤ rewinds the loop to ③ — the next packet is re-evaluated against the post-merge state, not the pre-PR plan.

Both Claude threads are launched via intent-cli; impl and review run in physically separate cwds (e.g. <your-repo> vs <your-repo>Review).

The six steps

①
Design
Build the intent tree
Purpose / User Context / Means. Human + LLM dialogue. Promotion states keep confidence explicit.
②
Design
Generate packets
The LLM slices the intent tree into packets — work units one level above an Issue that carry references to intent and explicit verification points. Before a packet is finalised, the design thread checks the latest merged code, drives the running app itself (Computer Use for native flows, the Playwright CLI for web flows) to see what is actually there, and folds that screen-level observation back into the packet. When what it sees does not match intent, it emits an adjustment or bug-fix packet on the spot. Implementers receive grounded context, not just text.
③
Design
Cut packets as GitHub Issues
Packets with high enough DIF and resolved dependencies become Issues in the implementation repo. By the time work reaches the Issue, why we build this is already attached.
④
Implementation
Read Issue, implement, open PR
Claude on /loop 5m picks up an untouched Issue, reads the corresponding packet / intent, implements, and opens a PR against ai-develop.
⑤
Review
PR review against packet / intent
A separate Claude /loop 5m running in a different cwd diffs the PR against the packet and intent. Approve → merge and return to ③. Decline → write a PR comment and hand off to ⑥. The physical cwd separation is what prevents a single session from grading its own homework.
⑥
Implementation
Apply review comments, push, re-request review
The implementation thread applies the review feedback to its own PR, pushes, and hands the updated PR back to ⑤.
Why this works

Same thread, /loop 5m, separate cwds

  • 5-minute interval. Matches Claude's prompt-cache TTL (5 minutes), so the next wake re-enters with a warm context. Longer intervals pay a cache miss for no gain; shorter intervals burn the cache without amortising it.
  • Same thread. Don't spawn a fresh session each wake. /loop continues the same thread so prior judgments carry forward — review consistency depends on this.
  • Separate cwds for impl and review. Implementation and review run in physically different worktrees (e.g. <your-repo> vs <your-repo>Review). One Claude session cannot grade its own homework when it literally cannot see the other side's local state.
  • Fire the first wake once. After intent-cli registers the loop, kick it once. Configuration mistakes surface immediately instead of after the first natural fire.
How to start the loops

The intent-cli prompt, in two lines

If the Claude thread is already familiar with intent-cli, the short form below is enough. Fill in <domain> / <target repo> / <cwd> and send.

Implementation loop

Ask intent-cli to set up the implementation-and-pr-comment-update loop
for <target repo> in <domain>, running under Claude on a 5-minute interval.
cwd is <cwd>. Use the same thread with /loop 5m, and fire the first wake once.

Review / next-slice loop

Ask intent-cli to set up the review-and-next-slice loop
for <target repo> in <domain>, running under Claude on a 5-minute interval.
cwd is <cwd>. Use the same thread with /loop 5m, and fire the first wake once.

A concrete example: intent-system itself

We run the loop in production on intent-system itself, the CLI that drives it. Two cwds, one for each loop.

# intent-system — implementation
intent-cli に聞いて、intent-cli の J-Tech-Japan/intent-system 向け implementation-and-pr-comment-update loop を Claude で 5分間隔に設定してください。cwd は /Users/<you>/dev/GitHub/intent-system。同一スレッド /loop 5m で設定し、最初の wake を1回実行してください。

# intent-system — review / next-slice
intent-cli に聞いて、intent-cli の J-Tech-Japan/intent-system 向け review-and-next-slice loop を Claude で 5分間隔に設定してください。cwd は /Users/<you>/dev/GitHub/IntentSystemReview。同一スレッド /loop 5m で設定し、最初の wake を1回実行してください。

Note the cwd pairing — the review loop always runs against a separate worktree (the *Review suffix). That separation is what makes the AI reviewer a real reviewer.

Claude vs Codex

Local /loop vs cloud automation

Claude is the engine for the local /loop 5m threads described on this page — implementation and review, each in its own cwd, each carrying judgment forward inside one thread. Codex sits on the cloud-automation side, running in parallel but not on this /loop mechanism. They are two layers of the same overall system, not two flavours of the same thing.

Try Intent-System→