{"slug": "show-hn-dev-loop-parallel-coding-agents-supervised-not-just-spawned", "title": "Show HN: Dev-loop – parallel coding agents, supervised not just spawned", "summary": "Developer choiyounggi released Dev-loop, a Claude Code plugin that combines a TDD/PDCA/Reflexion verification loop with a semantic-layer knowledge base of software best practices, enabling supervised parallel coding agents across multiple sessions. The plugin, installable via the Claude Code plugin marketplace, applies globally to all projects and supports both single-task implementation and goal decomposition with dependency-graph scheduling, with optional Orca CLI integration for enhanced supervision.", "body_md": "**English** | [한국어](/choiyounggi/dev-loop/blob/main/README.ko.md)\n\nA Claude Code plugin that merges two things into one self-contained tool:\n\n— a methodology-grounded verification loop (TDD / PDCA / Reflexion) for driving one task, or many parallel tasks, to \"done\".[loop-orchestrator](https://github.com/choiyounggi/loop-orchestrator)— a case-routed, semantic-layer knowledge base of software best-practices and edge cases, plus a planning methodology that grounds every design decision in it.[dev-llm-wiki](https://github.com/choiyounggi/dev-llm-wiki)\n\nAnd it scales past one session: the `orchestrate`\n\nskill is a **multi-session\norchestrator** over the same loop — it decomposes a goal into a dependency\ngraph, schedules parallel workers with a ready-set scheduler, and supervises\nthem **Orca-natively** when the Orca CLI is installed (raw tmux otherwise).\nSee [Orca integration](#orca-integration--supervision-not-just-spawning).\n\n**The one change from upstream loop-orchestrator:** the plan step is no longer an\noptional, pluggable role. It is **fixed to the bundled wiki-plan methodology** —\nevery non-trivial task plans by routing each design decision to a page in the\nbundled\n\n`wiki/`\n\nbefore any code is written. The rest of the loop is unchanged.On top of that, dev-loop adds a **knowledge-capture loop**: your sessions emit\nverified insights, and `knowledge-flush`\n\nresearches, de-dups, routes, and opens a\nreviewed PR that grows the wiki over time.\n\nInstalled via the Claude Code plugin marketplace, so the skills and hooks apply\n**globally across every project** you work in:\n\n```\n/plugin marketplace add choiyounggi/dev-loop\n/plugin install dev-loop@dev-loop\n```\n\nNothing is repo-scoped: the wiki-grounded loop, the `★ Insight`\n\ncapture\ninstruction, and the harvest hook are active in any repository you open.\n\nRun it two ways:\n\n**One task or one feature**→ the`loop-implement`\n\nskill — the**single implementer**. Step 2 runs`wiki-plan`\n\nonce to produce an ordered task list where each task names the exact wiki pages that ground it; the loop then executes those tasks**in the plan's order**, and per task runs:`0 define done → 1 analyze + load the task's named wiki pages → 3 tests (Red) → 4 implement (apply the pages' directives, no improvisation) → 5 run → 6 self-review → 6.5 independent test-quality audit → 7 judge (report the WIKI references applied) → 7b reflect + retry (bounded)`\n\n. There is no separate executor — the wiki-executor discipline (load only named pages, decisions win, BLOCKED-on-gap) is folded into this loop.**A whole goal, split across parallel worker sessions**→ the`orchestrate`\n\nskill: intake → decompose (approval gate) → dispatch loop: plan (wiki-plan) → implement + review (each session runs`loop-implement`\n\n) → integration test → pre-merge gate → merge. There is no wave barrier: a dependency graph plus slot accounting starts each task the moment its own dependencies are approved and a slot is free, so a finished worker is refilled instead of waiting out its batch's slowest member. A worker that finds its task far larger than the brief assumed can propose splitting it mid-run.**Substrate: Orca when detected — offered at the task-split gate — drives spawn** On Orca each phase is a tracked Task + Dispatch, and the coordinator blocks on pushed*and supervision*; otherwise raw tmux.`worker_done`\n\n/`escalation`\n\n/`question`\n\nmail instead of polling status files on a timer — so a worker's blocking question reaches you in seconds. On tmux the original status-file poll is unchanged. Either way, worker sessions escalate a guardrails`ask`\n\ninstead of blocking, and a dead worker is detected fast rather than stalling the run.\n\n`wiki-plan`\n\nmakes the planner do a **wiki routing sweep**: read `INDEX.md`\n\n, then\neach touched domain's `index.md`\n\n, and for every design decision find the page\nthat owns it — recording a `decision → wiki page`\n\nmap. Decisions are written as\nconcrete values/code (never \"as appropriate\"), so the implementing pass executes\ninstead of guessing. A decision no page covers is marked `[no-wiki]`\n\nand becomes\nan ingest candidate. This is not a configurable role and cannot be turned off.\n\nThe wiki lives at the plugin root (`wiki/`\n\n, `INDEX.md`\n\n, `AGENTS.md`\n\n,\n`templates/`\n\n); the wiki skills resolve their paths against `${CLAUDE_PLUGIN_ROOT}`\n\n.\n\nLike loop-orchestrator, dev-loop runs fully generic with **no** config, but you\ncan map its **capability roles** to your real tools so the loop uses them:\n\n| Role | Map to |\n|---|---|\n`verify` |\nyour project's test / build / QA command (the loop's run step) |\n`knowledge` |\nyour domain/team wiki or knowledge MCP (external facts) |\n`explore` |\ncode/symbol search (LSP, ripgrep, a source-search CLI) |\n`tacit` |\npast incidents / danger-zone lore |\n`design` |\nFigma / visual-spec MCP (UI work) |\n`intake` |\nissue tracker (orchestrate's work-list) |\n\n(`plan`\n\nis **not** a role — the plan step is fixed to `wiki-plan`\n\n. And the bundled\nbest-practice `wiki/`\n\nneeds no config; `knowledge`\n\nis a *separate* external wiki.)\n\nSet it up with ** /dev-loop:configure**, which writes\n\n`~/.claude/dev-loop/tools.json`\n\n(global) or `<repo>/.dev-loop/tools.json`\n\n(per-repo, team-shared). Precedence is\ngit-config style: `defaults < ~/.claude/dev-loop/tools.json < <repo>/.dev-loop/tools.json`\n\n.\nA SessionStart hook nudges you (at most weekly, then never) if you haven't\nconfigured anything — silence it with `DEV_LOOP_CONFIG_NUDGE=0`\n\n. Legacy\n`loop-orchestrator`\n\nconfig paths are still read as a fallback. See\n`references/tool-profile.md`\n\nand `examples/tools.example.json`\n\n.`orchestrate`\n\ntreats Orca as a first-class substrate, not a terminal spawner.\nWhen the `orca`\n\nCLI is on your PATH the coordinator offers it at the task-split\ngate, and from then on the whole run flows through Orca orchestration:\n\n**Provenance**— one Run per orchestration; every task*phase*(plan / implement / rework / merge-prep) is a tracked Task + Dispatch, so \"who is doing what, and did it settle\" is queryable state, not a guess.**Event-driven waits**— the coordinator blocks on pushed`worker_done`\n\n/`escalation`\n\n/`question`\n\nmail (`orca-wait.sh`\n\n) instead of polling status files on a timer. A worker's blocking`ask`\n\nreaches the coordinator in seconds and is answered with`orchestration reply`\n\n; a dead Orca runtime is a distinct exit, never a silent timeout.**Env-carrying worker start**—`orca-worker-start.sh`\n\ncomposes the worktree, an agent terminal that carries the guardrails escalation contract (`GROUNDWORK_ESCALATION_DIR`\n\n/`GROUNDWORK_TASK_ID`\n\n), and the Dispatch binding; on re-entry it probes for a live agent first, so one worktree never ends up with two agents.**Liveness is two questions**—`orca-worktree-alive.sh`\n\n(is the terminal there?)*and*`orca-worker-stalled.sh`\n\n(is the pane actually moving?) — because a wedged worker passes the first check for hours.\n\nWithout Orca, the same run gets the same protections over **raw tmux**,\nfile-based: a worker writes a blocking question with `ask-coordinator.sh`\n\nand\nthe watch surfaces it (exit 6); a silent pane surfaces as a stall (exit 7) with\na classify-then-act playbook (chooser / usage-limit / finished-but-silent); an\non-screen chooser is answered with allowlisted key events\n(`send-prompt.sh keys`\n\n); and every launch pre-seeds the status record, so a\nworker that dies during planning is caught instead of waited out. The\nguardrails escalation contract is identical on both substrates.\n\n**One setup note for auto-mode coordinators (tmux):** the launcher starts each\nworker as `claude --permission-mode bypassPermissions`\n\n, which an auto-mode\npermission classifier flags as privilege escalation — it cannot see the\nguardrails deny-net that makes it safe. If your coordinator session runs in\nauto mode, the three worker-management scripts (`launch-session.sh`\n\n,\n`send-prompt.sh`\n\n, `watch-status.sh`\n\n) need pre-approval. The coordinator\nhandles this at onboarding: it probes read-only\n(`install-permission-rules.sh --check`\n\n), and if the rules are missing it asks\nyou **once** — on your explicit yes it runs the bundled installer (idempotent,\nbacked-up, atomic; never silent), otherwise it shows you the snippet to paste\nyourself. `safe-cleanup.sh`\n\nis deliberately excluded so destructive verbs keep\ntheir normal review, and a blocked coordinator stops and re-asks rather than\nworking around the classifier.\n\nThe wiki is meant to grow from what you actually learn. Three moving parts:\n\n-\n**Capture (global, automatic).** A SessionStart hook injects a standing instruction: whenever, in any repo, you discover a verified best-practice or a real edge case worth persisting, emit a compact`★ Insight`\n\nblock (trigger / directive / why / evidence / domain / tags). -\n**Harvest (automatic, offline).** A Stop hook scrapes those blocks from the session transcript into a local queue (`~/.dev-loop/queue/`\n\n). It dedupes against both the session's queue file and the already-flushed store (`.processed.jsonl`\n\n), caps a session at 10 rows as a runaway backstop, and cleans up emptied queue files. It never edits the wiki and never opens a PR — harvesting is cheap and non-blocking. -\n**Flush → verified PR (automatic, or on-demand).** The queue is drained by the`knowledge-flush`\n\npipeline. For**each** candidate it must, before any PR:**research & verify** the best-practice against real sources (official docs, primary references) and assign a confidence (verified / field-tested / unverified — never a fabricated citation),**check existing layers** for duplicates to merge into and pages to link (naming the page ids it actually read),**check open** so sibling flushes don't pile up duplicate PRs — each candidate is folded into an in-flight PR, dropped as a pending duplicate, or ingested as new,`knowledge/*`\n\nPRs**decide the target layer/category**(or justify a new category),- then run\n`wiki-ingest`\n\nand write an`INGEST_REPORT.md`\n\n.\n\nIt opens\n\n**one PR per flush** and**never auto-merges**. Each contributor's PR is committed and opened under** their own git/gh identity**(never a hardcoded account, never an assistant); the repo owner reviews the open`dev-loop:knowledge`\n\nPRs and merges or rejects each one.Two ways it runs:\n\n**Automatic**— the`hooks/auto-flush.sh`\n\nStop hook fires the pipeline in a detached, headless`claude`\n\nrun when the queue crosses a threshold and the rate-limit window has elapsed, so PRs appear without you doing anything. Guarded: kill switch`DEV_LOOP_AUTOFLUSH=0`\n\n, once per`DEV_LOOP_AUTOFLUSH_INTERVAL`\n\n(default 3600s), only at`DEV_LOOP_AUTOFLUSH_MIN`\n\n(default 3) pending items, single-flight lock, and recursion-safe. Needs`claude`\n\n+`gh`\n\non PATH and gh authenticated; if either is missing it silently no-ops and you fall back to manual.**Manual**— invoke`/dev-loop:knowledge-flush`\n\nany time to drain the queue now.\n\n`hooks/pre-flush-pr-gate.sh`\n\n(PreToolUse) **blocks** `gh pr create`\n\non a\nknowledge branch unless the `INGEST_REPORT.md`\n\nexists and has all four sections\n(`## Verified best-practice`\n\n, `## Existing-layer check`\n\n, `## Open-PR check`\n\n,\n`## Routing decision`\n\n) filled with real content. The Existing-layer check must\ncarry a `Pages read: <id>, …`\n\nline, and each id is resolved against the\ncheckout's `wiki/`\n\n— a report citing pages that don't exist fails closed. The\ngate is narrowly scoped to knowledge-flush PRs, so it never interferes with\nordinary `gh pr create`\n\nin any repo.\n\n| Skill | Role |\n|---|---|\n`loop-implement` |\nThe single implementer — consumes the wiki-plan and executes its tasks in order (loading each task's named wiki pages) through the verification loop. Plan step = wiki-plan. |\n`orchestrate` |\nThe multi-session orchestrator — split one goal into parallel worker sessions, each running loop-implement — over Orca when detected (Task/Dispatch tracking, event-driven `worker_done` /`ask` /`escalation` waits, native liveness), else tmux with a hardened watch (worker question channel, stall surfacing, allowlisted chooser keys). Scheduling is a dependency graph plus slot accounting, not wave barriers: `ready-set.sh` says what may start now, the slot count is proposed at Gate 1 and bounded by `LO_MAX_SESSIONS` , and a failed dependency surfaces as a reported deadlock rather than a silent wait. Per-role model selection: a cheap worker model, a strong planner/auditor. Workers escalate guardrails `ask` s instead of blocking, may propose splitting an over-large task mid-run, and dead workers are detected. |\n`wiki-plan` |\nThe fixed plan methodology — route each decision to a wiki page, decompose into ordered, page-navigated tasks. |\n`wiki-ingest` |\nAdd verified knowledge to the right semantic layer (used by knowledge-flush). |\n`wiki-query` |\nAnswer a question from the wiki with citations. |\n`wiki-lint` |\nHealth-check the wiki. |\n`knowledge-flush` |\nResearch + verify + route queued insights → one reviewed wiki PR. |\n`configure` |\nSet up the capability-role tool profile (map your wiki, test command, etc.). |\n\n```\ndev-loop/\n├── .claude-plugin/{plugin,marketplace}.json\n├── AGENTS.md INDEX.md templates/     # wiki schema + routing entry + page/brief/session-prompt templates\n├── wiki/                             # 10-domain semantic-layer knowledge base\n├── skills/                           # the 8 skills above (user-invocable; appear in the / menu by skill name)\n├── agents/test-quality-auditor.md    # bundled independent test auditor (loop step 6.5)\n├── hooks/\n│   ├── hooks.json\n│   ├── preflight.sh                  # SessionStart: git/tmux/jq advisory\n│   ├── insight-instruction.sh        # SessionStart: inject ★ Insight capture instruction (global)\n│   ├── config-nudge.sh               # SessionStart: nudge to /dev-loop:configure if unconfigured (weekly)\n│   ├── loop-gate.sh                  # Stop: verification-loop integrity gate\n│   ├── harvest-insights.sh + harvest.js  # Stop: harvest insights → queue\n│   ├── auto-flush.sh                 # Stop: auto-run knowledge-flush (guarded) → PR\n│   └── pre-flush-pr-gate.sh          # PreToolUse: enforce the flush pre-PR pipeline\n├── scripts/resolve-tools.sh          # capability-role profile resolver (no `plan` role)\n├── tests/                            # bats suites — hooks (harvest, flush gate, loop gate) + orchestration scripts; CI runs them on ubuntu + macos\n├── references/tool-profile.md\n└── docs/                             # inherited design notes (loop-orchestrator lineage)\n```\n\nKnowledge PRs (manual or auto-opened) are committed under **each contributor's own\ngit/gh identity** — never a hardcoded account and never an assistant, with no\n`Co-Authored-By`\n\ntrailer. Every contributor opens a PR from their own account; the\nrepo owner reviews and merges/rejects.\n\nForked from **loop-orchestrator** and **dev-llm-wiki** (both by choiyounggi).\nSee `docs/`\n\nfor the inherited loop design (note: those docs predate the\nfixed-plan-step change described above). MIT — see `LICENSE`\n\n.", "url": "https://wpnews.pro/news/show-hn-dev-loop-parallel-coding-agents-supervised-not-just-spawned", "canonical_source": "https://github.com/choiyounggi/dev-loop", "published_at": "2026-08-12 04:21:29+00:00", "updated_at": "2026-08-12 04:41:40.084976+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-tools"], "entities": ["choiyounggi", "Claude Code", "Dev-loop", "loop-orchestrator", "dev-llm-wiki", "Orca"], "alternates": {"html": "https://wpnews.pro/news/show-hn-dev-loop-parallel-coding-agents-supervised-not-just-spawned", "markdown": "https://wpnews.pro/news/show-hn-dev-loop-parallel-coding-agents-supervised-not-just-spawned.md", "text": "https://wpnews.pro/news/show-hn-dev-loop-parallel-coding-agents-supervised-not-just-spawned.txt", "jsonld": "https://wpnews.pro/news/show-hn-dev-loop-parallel-coding-agents-supervised-not-just-spawned.jsonld"}}