{"id":48029771,"url":"https://github.com/berrzebb/consensus-loop","last_synced_at":"2026-04-04T13:54:20.565Z","repository":{"id":344769123,"uuid":"1182171751","full_name":"berrzebb/consensus-loop","owner":"berrzebb","description":"Claude Code PostToolUse hook that enforces tag-based two-party consensus between Claude and an external AI auditor (GPT/Codex). Drop in one directory, configure via JSON. Includes auto-sync, planning doc normalization, and inline quality checks.","archived":false,"fork":false,"pushed_at":"2026-03-16T13:19:34.000Z","size":122,"stargazers_count":2,"open_issues_count":0,"forks_count":2,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-03-16T20:06:03.648Z","etag":null,"topics":["ai-agents","automation","claude-code","code-review","consensus","gpt","hooks","llm"],"latest_commit_sha":null,"homepage":null,"language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/berrzebb.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":"audit.mjs","citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-03-15T06:13:44.000Z","updated_at":"2026-03-16T13:19:37.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/berrzebb/consensus-loop","commit_stats":null,"previous_names":["berrzebb/consensus-loop"],"tags_count":null,"template":false,"template_full_name":null,"purl":"pkg:github/berrzebb/consensus-loop","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/berrzebb%2Fconsensus-loop","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/berrzebb%2Fconsensus-loop/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/berrzebb%2Fconsensus-loop/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/berrzebb%2Fconsensus-loop/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/berrzebb","download_url":"https://codeload.github.com/berrzebb/consensus-loop/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/berrzebb%2Fconsensus-loop/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":31402276,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-04T10:20:44.708Z","status":"ssl_error","status_checked_at":"2026-04-04T10:20:06.846Z","response_time":60,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["ai-agents","automation","claude-code","code-review","consensus","gpt","hooks","llm"],"created_at":"2026-04-04T13:54:20.492Z","updated_at":"2026-04-04T13:54:20.556Z","avatar_url":"https://github.com/berrzebb.png","language":"JavaScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# consensus-loop\n\n\u003e **⚠️ This project has evolved into [quorum](https://github.com/berrzebb/quorum) — a multi-model AI development harness with agent-to-agent communication and consensus-based delivery. New development happens there. This repo is frozen at v2.5.0.**\n\n[![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.19108370.svg)](https://doi.org/10.5281/zenodo.19108370)\n\n**AI writes code. A different AI reviews it. Nothing ships without consensus.**\n\nA Claude Code plugin that enforces a cross-model audit gate on every code change. Claude implements, GPT/Codex reviews, and a human-in-the-loop retrospective ensures the team learns from each cycle.\n\n```bash\nclaude plugin marketplace add berrzebb/claude-plugins\nclaude plugin install consensus-loop@berrzebb-plugins\n```\n\nThat's it. All hooks, skills, agents, and MCP tools are auto-registered.\n\n---\n\n## The Problem\n\nAI coding tools generate code fast. They also generate bugs fast, skip tests, drift from requirements, and self-validate their own blind spots. Instruction-based corrections (\"always write tests\") fade across sessions. **The model cannot reliably catch its own mistakes through self-review.**\n\n## The Solution\n\nStructure beats instruction. consensus-loop makes it **structurally impossible** to ship unreviewed code:\n\n1. **You write** → Claude implements in an isolated git worktree\n2. **A different model reviews** → GPT/Codex independently audits the evidence\n3. **Nothing merges without consensus** → `[APPROVED]` requires auditor sign-off, not self-promotion\n4. **The team learns** → Mandatory retrospective after each cycle, session-gate enforced\n\n```\nplanner → scout (RTM) → orchestrator → implementer (worktree) → verify → audit → retro → merge → loop\n```\n\n---\n\n## Quick Start\n\n### 1. Install\n\n```bash\nclaude plugin marketplace add berrzebb/claude-plugins\nclaude plugin install consensus-loop@berrzebb-plugins\n```\n\n### 2. Configure\n\n```bash\n# Copy example config to your project\ncp ~/.claude/plugins/cache/berrzebb-plugins/consensus-loop/*/examples/config.example.json \\\n   .claude/consensus-loop/config.json\n\n# Copy prompt templates\ncp -r ~/.claude/plugins/cache/berrzebb-plugins/consensus-loop/*/examples/en/templates/ \\\n      .claude/consensus-loop/templates/\n```\n\nEdit `config.json` — set your tags and paths:\n\n```json\n{\n  \"consensus\": {\n    \"watch_file\": \"docs/feedback/claude.md\",\n    \"trigger_tag\": \"[REVIEW_NEEDED]\",\n    \"agree_tag\": \"[APPROVED]\",\n    \"pending_tag\": \"[CHANGES_REQUESTED]\"\n  }\n}\n```\n\n### 3. Use\n\n```\n/consensus-loop:orchestrator     # Start a work session\n/consensus-loop:planner          # Design new tracks interactively\n/consensus-loop:verify           # Check done-criteria before submission\n/consensus-audit                 # Trigger manual audit\n/consensus-status                # Show current loop state\n```\n\n---\n\n## Real-World Reference: SoulFlow Orchestrator\n\nconsensus-loop was built to manage [SoulFlow Orchestrator](https://github.com/berrzebb/SoulFlow-Orchestrator) — a 32MB TypeScript codebase with 141 workflow nodes, 9 AI providers, and 188 deterministic tools.\n\n**Results from production use:**\n\n| Metric | Value |\n|--------|-------|\n| Tracks planned | 17 (+ 2 parallel support tracks) |\n| Tracks RTM-scanned | 13 in 3 scout runs |\n| Broken cross-track links found | 8 (automatically, in one pass) |\n| Orphan tests identified | 7 |\n| Parallel workers per session | Up to 3 (background, worktree-isolated) |\n| Test suite | 104 tests across 21 suites |\n\n**What RTM looks like in practice:**\n\nA single scout run on 5 foundation tracks produced 3-way traceability matrices revealing:\n- Backend code: ~90% verified across all 5 tracks\n- Frontend: consistently `wip` (intentionally deferred to Track 15)\n- Concrete next steps: PA-5 (ArtifactStore extraction) and PAR-4 (workflow fanout) identified as the only true `open` items\n\nThe scout eliminated redundant exploration — implementers received pre-verified RTM rows and skipped straight to coding.\n\n**In action — orchestrator analyzing RTM state and proposing parallel distribution:**\n\n![Orchestrator identifies unblocked tracks from RTM, checks scope overlap between candidates, and proposes 3 parallel agents](assets/orchestrator-rtm-scope-analysis.png)\n\n*The orchestrator reads RTM state across all tracks, identifies 4 unblocked tracks (14, 17, P1, P2), checks file scope overlap between every pair (only P1 vs P2 has a dependency warning), and proposes 3 parallel agents with non-conflicting scopes.*\n\n**Orchestrator distributing RTM-based work to parallel agents:**\n\n![Orchestrator analyzes scope overlap, splits tasks into non-conflicting agents, and distributes RTM rows](assets/orchestrator-scope-distribution.png)\n\n*The orchestrator detects that PA-7 and RP-4+SO-6 touch different directories, assigns them to separate agents, and each agent receives only its RTM open rows.*\n\n**Parallel worktree agents executing in the background:**\n\n![Two worktree-isolated agents running simultaneously with real-time status tracking](assets/parallel-worktree-agents.png)\n\n*Agent A (PA-7 import boundary) and Agent B (RP-4+SO-6 binding tests) execute in isolated worktrees. The orchestrator tracks completion status and waits for both to finish before proceeding to merge.*\n\n**Full cycle completion — done-criteria verification + evidence integration:**\n\n![Implementer passes all 8 done-criteria categories, 105 tests pass, two parallel workers complete and proceed to evidence integration](assets/done-criteria-verification-complete.png)\n\n*Both parallel workers pass all done-criteria (CQ, T, CC, CL, CV — all PASS, 105 tests including 27 new + 78 regression). The orchestrator integrates evidence from both worktrees and proceeds to audit → retrospective → squash merge.*\n\n**Audit trigger + retrospective gate enforcement:**\n\n![Orchestrator triggers manual audit, agent recognizes retro-marker gate and defers retrospective until after APPROVED verdict](assets/audit-trigger-retro-gate.png)\n\n*The orchestrator triggers `/consensus-audit`. The agent recognizes that retrospective must wait for `[APPROVED]` verdict (retro-marker.json → session-gate.mjs). Structural guardrails enforce protocol order — the agent cannot skip ahead.*\n\n**Cross-model audit verdict — [CHANGES_REQUESTED] with specific evidence:**\n\n![GPT/Codex auditor issues CHANGES_REQUESTED verdict citing missing file and scope mismatch, while independently verifying RTM rows](assets/auditor-changes-requested.png)\n\n*The independent auditor (GPT/Codex) issues `[CHANGES_REQUESTED]` citing a missing test file and scope mismatch. The second audit independently verifies RTM rows — \"The files and tests cited by the RTM do exist.\" The agent then performs retrospective on the rejection, identifying what went wrong and what to improve.*\n\n**Emergent double verification — main-branch audit catches what worktree verification missed:**\n\n![Second audit classifies 5 rejections into infrastructure issues (CC-2/CV stale) vs substantive code issues (CC-1 claim-code mismatch), with correction plan](assets/double-verification-evidence.png)\n\n*The main-branch audit discovers 3 substantive CC-1 issues that passed worktree-local verification: has_role gating mismatch, BMS25 score initialization, ordinal rank seed. This is the emergent double verification in action — two structurally independent verification passes catch different failure classes.*\n\n**Correction cycle resolution — all CC-1 issues fixed, remaining issues classified:**\n\n![Third audit shows all 3 CC-1 bugs resolved, remaining issues classified as infrastructure (CC-2 diff baseline) vs substantive (T-2 write path test)](assets/correction-cycle-resolution.png)\n\n*After correction: all CC-1 claim-code mismatches resolved (has_role ✅, lexical_scores ✅, _last_scores ✅). Remaining issues cleanly classified — CC-2 is infrastructure (git diff baseline), T-2 is substantive (write path assertion missing). The protocol's correction cycle converges.*\n\n**Final audit pass + full retrospective — protocol cycle complete:**\n\n![Fourth audit passes all substantive criteria, CC-2 remains as known infrastructure gap, followed by structured 4-phase retrospective](assets/final-audit-pass-retrospective.png)\n\n*All 5 RTM rows pass CQ, T, CC-1, CL, CV. Only CC-2 (infrastructure diff baseline) remains. The orchestrator proceeds to retrospective: what went well (parallel distribution, double verification), what went wrong (CC-2 gap, WIP commit missing, audit hook trigger), memory cleanup, and bidirectional feedback. The full protocol cycle — plan → scout → distribute → implement → verify → audit → correct → re-audit → retrospective → merge — is complete.*\n\n**Session gate release + handoff — cycle complete, next session prepared:**\n\n![Session-gate released via session-self-improvement-complete, session summary table showing outputs across code/audit/paper/discovery/memory, next session handoff to K2→K3→Track 15](assets/session-complete-handoff.png)\n\n*`echo \"session-self-improvement-complete\"` releases the gate. Session summary: 8 files + 155 tests produced, 4 audit rounds completed, paper advanced v0.3→v0.4 with 8 Figures, emergent double verification discovered. Handoff specifies next tasks: K2 (Retriever Vector Closure) → K3 (Multimodal Reference) → Track 15 FE.*\n\n**Handoff file update — session state persisted for next session:**\n\n![Handoff file written with completed task states (K1/K4 done with agent_id, worktree paths, results), next tasks (K2 not-started), paper status, and commit summary table](assets/handoff-write-session-state.png)\n\n*The orchestrator writes `session-handoff.md` with full state: completed tasks (K1 4 files/48 tests, K4 4 files/105 tests), agent IDs, worktree branches, correction history, protocol changes, paper status (v0.4), and next session targets. This enables any future session to resume without re-exploration.*\n\n---\n\n## Full Cycle Walkthrough (Test Harness)\n\nThe test harness is a standalone TypeScript project (3 tracks, 9 work-breakdowns, 44 tests) built to validate every stage of the protocol in isolation. Each screenshot below shows a real execution — not a mockup.\n\n### Phase 1: Plan — Requirements + Track Design\n\nThe planner defines tracks with dependency ordering, work-breakdown items per track, verification scenarios, and intentionally planted defects for audit rejection testing.\n\n![Requirements definition showing 3 tracks (data-layer → service-layer → api-layer), 10 verification scenarios, and 3 planted defects mapped to specific WBs](assets/th-01-harness-requirements.png)\n\n*3 tracks with sequential dependency (data → service → api), 9 work-breakdown items, 10 scenarios covering the full cycle. 3 planted defects (test-gap, security-drift, scope-mismatch) are assigned to specific WBs — the auditor must catch all three.*\n\n### Phase 2: Build — Project Scaffold + Quality Gates\n\nThe implementer creates the project structure, implements source code, and passes all quality gates (tsc, eslint, vitest) before entering the consensus cycle.\n\n![Project structure showing src/data, src/service, src/api with 34 passing tests, file tree, and planted defect table](assets/th-02-project-complete.png)\n\n*The project is a real TypeScript codebase — not stubs. 34 tests pass across 3 test files. The defect table maps each planted issue to its WB, expected rejection code, and exact file location.*\n\n### Phase 3: Scout — Deterministic RTM Generation\n\nThe scout uses MCP tools (`code_map`, `dependency_graph`) to analyze the codebase and generate 3-way Requirements Traceability Matrices — Forward, Backward, and Bidirectional.\n\n![Scout executes code_map (17 symbols across 9 files) and dependency_graph (9 components), analyzing the actual codebase via MCP tools](assets/th-03-scout-mcp-tools.png)\n\n*No LLM inference at this stage — only deterministic tools. `code_map` extracts 17 symbols (functions, classes, interfaces, types) with exact line ranges. `dependency_graph` maps import chains and connected components. These facts feed the RTM.*\n\n![Forward RTM with 4 rows for data-layer showing Exists/Impl/Test Case/Connected columns, Backward RTM tracing 3 test files to requirements, Bidirectional summary](assets/th-04-rtm-matrices.png)\n\n*Forward RTM maps each Req ID to its implementation file, verification status, test case, and downstream consumer. Backward RTM traces each test file back to its requirement — detecting orphan tests. The bidirectional summary reveals gaps: SL-2 has no direct test (the planted defect).*\n\n### Phase 4: Audit — Cross-Model Rejection\n\nThe auditor (GPT/Codex) independently verifies each RTM row. When evidence claims don't match the codebase, specific rejection codes are issued with file:line evidence.\n\n![Auditor issues CHANGES_REQUESTED for SL-2 with rejection code test-gap, while SL-1 and SL-3 pass independently](assets/th-05-audit-test-gap-rejection.png)\n\n*SL-2 claimed `fixed` status but `tests/service/validator.test.ts` does not exist — T-1 violation. The auditor issues `test-gap` with a Completion Criteria Reset specifying exactly what to fix. SL-1 and SL-3 are judged independently and pass.*\n\n### Phase 5: Correct — SendMessage Reuse + Re-Audit\n\nThe orchestrator sends corrections to the existing implementer agent via `SendMessage` (no new spawn). After correction, evidence is resubmitted and re-audited.\n\n![claude.md tag promoted from REVIEW_NEEDED to APPROVED after correction round 2, audit-history.jsonl records both rejection and approval entries](assets/th-06-correction-cycle-approval.png)\n\n*The correction cycle is visible in the diff: `[REVIEW_NEEDED]` → `[APPROVED]` tag promotion. The audit-history.jsonl shows the full trail — round 1 rejected (`test-gap`), round 2 approved. The tag in `claude.md` is promoted by `respond.mjs`, not by the implementer (no self-promotion).*\n\n### Phase 6: Enforce — Scope Validation + Upstream Delay\n\nStructural enforcement runs automatically — not as guidelines but as code. The orchestrator validates scope overlap before parallel distribution, and `enforcement.mjs` auto-blocks downstream tracks when upstream rejection count exceeds threshold.\n\n![dependency_graph + Grep reveals error-handler.ts imports Response/RouteHandler from routes.ts — scope overlap detected, parallel spawn blocked](assets/th-07-scope-overlap-validation.png)\n\n*AL-1 (routes.ts) and AL-2 (error-handler.ts) share types via import. The orchestrator detects this overlap and falls back to sequential execution — preventing merge conflicts that parallel worktrees would cause.*\n\n![3 consecutive security rejections on AL-1 trigger blockDownstreamTasks(), AL-2 status updated to \"blocked (upstream delay: AL-1 security rejected 3x)\"](assets/th-08-upstream-delay-enforcement.png)\n\n*After 3 consecutive `security` rejections on AL-1, `enforcement.mjs` automatically blocks AL-2 (which depends on AL-1). The handoff is updated with the reason string. This prevents wasted work — downstream agents won't start until the upstream issue is resolved.*\n\n### Results\n\n| Metric | Value |\n|--------|-------|\n| Scenarios executed | 10/10 pass |\n| Planted defects caught | 3/3 (test-gap, security, scope-mismatch) |\n| Correction cycles | 2 (SL-2 test-gap, AL-1 security) |\n| Downstream auto-blocks | 1 (AL-2 blocked by AL-1 upstream delay) |\n| Tech debt auto-captured | 4 items → work-catalog.md |\n| Final test count | 44 pass (4 files) |\n\n```bash\n# Run the test harness yourself\ncd test-harness \u0026\u0026 npm install \u0026\u0026 npm run quality\n```\n\n---\n\n## Lightweight Entry: Audit Gate Only\n\nDon't need the full orchestration? Use just the audit gate:\n\n**What you get:**\n- Every file edit → cross-model audit (async, non-blocking)\n- `[trigger_tag]` → `[agree_tag]` or `[pending_tag]` with specific file:line rejection codes\n- Quality rules (ESLint, npm audit) run inline on matching edits\n- Session gate blocks commits until retrospective completes\n\n**What you skip:**\n- Orchestrator/implementer multi-agent workflow\n- Scout + RTM traceability\n- Work breakdown planning\n\n**How:** Install the plugin normally, then disable the skills you don't need. The hook cycle (`index.mjs` → `audit.mjs` → `respond.mjs` → `session-gate.mjs`) works independently of the orchestration layer.\n\n---\n\n## How It Works\n\n### Full Development Cycle\n\n```\nplanner ─── Interactive 6-phase requirement definition\n    ↓\nscout ─── dependency_graph + code_map → 3-way RTM (Forward/Backward/Bidirectional)\n    ↓\norchestrator ─── Distribute Forward RTM rows → scope validation → parallel background spawn\n    ↓\n┌─── Track A (worktree) ──────┐  ┌─── Track B (worktree) ──────┐\n│  implementer: RTM rows only  │  │  implementer: RTM rows only  │\n│  → verify (8 categories)     │  │  → verify (8 categories)     │\n│  → submit RTM-based evidence │  │  → submit RTM-based evidence │\n│  → audit (async, background) │  │  → audit (async, background) │\n│  [pending] → fix failed rows │  │  [approved] → WIP commit     │\n│  [approved] → WIP commit     │  │                               │\n└──────────────────────────────┘  └──────────────────────────────┘\n    ↓\nretrospective (session-gate enforced) → merge (squash) → handoff → next RTM row\n```\n\n### Verification Categories (8)\n\n| # | Category | What it checks |\n|---|----------|---------------|\n| 1 | Code Quality (CQ) | Per-file eslint + tsc + forbidden patterns |\n| 2 | Test (T) | Test execution + direct test per claim + no regressions |\n| 3 | Claim-Code (CC) | Evidence matches git diff |\n| 4 | Cross-Layer (CL) | BE→FE contracts documented |\n| 5 | Security (S) | OWASP TOP 10 + input validation + auth guards |\n| 6 | i18n (I) | Locale keys in all supported locales |\n| 7 | Frontend (FV) | Page loads, DOM, console errors, build |\n| 8 | Coverage (CV) | Statement ≥ 85%, Branch ≥ 75% per changed file |\n\n### Deterministic MCP Tools (7)\n\nThese tools provide **facts, not inference** — used by all roles:\n\n| Tool | What it does |\n|------|-------------|\n| `code_map` | Cached symbol index with line ranges |\n| `dependency_graph` | Import/export DAG, connected components, topological sort, cycle detection |\n| `audit_scan` | Pattern scan (type-safety, hardcoded strings, console.log) |\n| `coverage_map` | Per-file coverage percentages from vitest JSON |\n| `rtm_parse` | Parse RTM markdown → structured rows, filter by req_id/status |\n| `rtm_merge` | Row-level merge of worktree RTMs with conflict detection |\n| `audit_history` | Query persistent audit history — verdicts, rejection patterns, risk detection |\n\n### Hook Cycle\n\n```\nCode Edit → PostToolUse (index.mjs)\n    ├─ watch_file + trigger_tag → spawn audit (detached, async)\n    ├─ gpt.md newer → auto-sync (promote/demote tags)\n    ├─ planning file → normalize\n    └─ quality rule match → run check inline\n```\n\nAudit runs in background. Hook returns immediately. No blocking.\n\n---\n\n## Key Design Decisions\n\n**1. Structure over instruction.** Behavioral constraints enforced by code (session-gate, audit.lock) are more reliable than behavioral constraints enforced by prompts. You can't instruct Claude to consistently catch `test-gap` across sessions. But you can build a gate that makes it structurally impossible to proceed until a peer model confirms.\n\n**2. Facts over inference.** The 6 MCP tools provide deterministic data — file existence, import chains, coverage percentages, symbol indices. Models judge; tools measure. This makes results stable across model changes.\n\n**3. Policy as data.** All audit criteria, rejection codes, and evidence formats are in editable markdown files (`templates/references/`). To change audit standards, edit a file. No code changes.\n\n**4. Fail-open safety.** Every hook fails open — errors pass through silently. The system never locks you out. `session-gate.mjs` errors → pass. Audit failures → pass. Config missing → graceful defaults.\n\n**5. Scout once, implement many.** The scout generates a Requirements Traceability Matrix (RTM) once per track. All subsequent agents work from those facts, not from re-exploration. Cost: ~8K tokens (one-time). Savings: ~5K tokens per worker per round.\n\n---\n\n## Architecture\n\n### Roles\n\n| Role | What it does | Model |\n|------|-------------|-------|\n| **Planner** | Interactive 6-phase requirement definition | Opus |\n| **Scout** | Read-only 3-way RTM generation using deterministic tools | Opus |\n| **Orchestrator** | Task distribution, agent tracking, correction cycles | Inherited |\n| **Implementer** | Code in worktree, test, submit evidence, handle corrections | Sonnet |\n| **Auditor** | Independent per-row verification of RTM evidence | GPT/Codex |\n\n### Skills (5)\n\n| Skill | Purpose |\n|-------|---------|\n| `consensus-loop:orchestrator` | Session orchestration — scout, distribute, track, correct |\n| `consensus-loop:verify` | Done-criteria verification (8 categories) |\n| `consensus-loop:merge` | Squash-merge worktree with structured commit |\n| `consensus-loop:planner` | Interactive track definition + work breakdown |\n| `consensus-loop:guide` | Evidence package writing guide |\n\n### Agents (2)\n\n| Agent | Purpose |\n|-------|---------|\n| `consensus-loop:implementer` | Headless worker in worktree — code, test, evidence |\n| `consensus-loop:scout` | Read-only RTM generator — 3-way traceability |\n\n---\n\n## Porting to Another Project\n\n```bash\n# 1. Install\nclaude plugin marketplace add berrzebb/claude-plugins\nclaude plugin install consensus-loop@berrzebb-plugins\n\n# 2. Configure (edit tags + paths)\n# 3. Edit templates/references/ for your team's policies\n```\n\nMinimal config for English projects:\n\n```json\n{\n  \"plugin\": { \"locale\": \"en\" },\n  \"consensus\": {\n    \"watch_file\": \"docs/review/author.md\",\n    \"trigger_tag\": \"[REVIEW_NEEDED]\",\n    \"agree_tag\": \"[APPROVED]\",\n    \"pending_tag\": \"[CHANGES_REQUESTED]\"\n  }\n}\n```\n\n---\n\n## Contributing\n\n| Contributor | Contributions |\n|---|---|\n| [@berrzebb](https://github.com/berrzebb) | Core architecture, RTM system, MCP tools, multi-agent orchestration |\n| [@dandacompany](https://github.com/dandacompany) | Security fixes (#1 shell injection, #2 plugin support), locale path traversal + ESM require fix |\n\n---\n\n## License\n\nMIT\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fberrzebb%2Fconsensus-loop","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fberrzebb%2Fconsensus-loop","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fberrzebb%2Fconsensus-loop/lists"}