Skip to content

Latest commit

 

History

History
228 lines (156 loc) · 18.6 KB

File metadata and controls

228 lines (156 loc) · 18.6 KB

Code Crew

A downloadable famous-programmer code review crew for Codex, Claude Code, Hermes, Cursor, and AgentSkills-compatible agents (GitHub Copilot, Gemini CLI, and the other hosts of the open agentskills.io format).

Code Crew packages named software-engineering reasoning lenses for working through code quality, system design, and code improvement. Think of it as a reusable review discipline you can ask for when a diff deserves more than one opinion. Foreman dispatches the right persona specs as independent subagents, each follows its process, and Foreman synthesizes the returned reports.

This is a review-and-improvement shop for software. The crew is designed to attack a piece of code or a system from multiple angles, with built-in disagreement so you don't get a comfortable consensus that misses what's wrong.

Problems Code Crew Solves

Problem Code Crew response
Single-pass reviews miss classes of defects Knuth + Hickey + Torvalds (K+H+T: Donald Knuth, Rich Hickey, Linus Torvalds) blind passes cover rigor, simplicity, and maintainer reality separately
Persona roleplay fabricates plausible findings Mandatory diff-grounded verifier drops uncited claims before synthesis
Bigger crews feel thorough but degrade output Default stays at the measured 3-persona preset; sextet is opt-in
Agent edits drift into drive-by refactors Implementation discipline requires stated assumptions, surgical scope, and concrete verification

Code Crew and built-in review

Codex, Claude Code, and Cursor now have capable built-in review workflows. Use those when you want the host's quickest default bug scan. Code Crew is useful when you explicitly want several recognizable engineering lenses and an auditable pass from each one.

Reach for Code Crew when you want multi-lens engineering judgment rather than a bug scan:

  • persona-diverse passes designed to argue (rigor vs. simplicity vs. maintainer reality), with dissent preserved when lenses disagree on the land/block decision
  • design critique and refactoring judgment, not just diff review
  • the same review discipline portable across every host you use, instead of a different built-in per tool
  • public prompts, experiment artifacts, and limitations you can inspect under experiments/

A 2026 study of deployed code-review agents found that 12 of 13 had average signal ratios below 60%, reinforcing the need to treat plausible findings skeptically (Chowdhury et al.). Code Crew therefore puts a verifier between the blind passes and synthesis. That verifier is a defensive design choice; its incremental effect has not yet been measured independently in this repo.

The package contains Markdown instructions only: no scripts, hooks, MCP servers, dependencies, or background processes. Prompt-only does not make a skill automatically trustworthy, but it does make the complete behavior inspectable in this repository.

Install

The canonical distributable package is plugins/code-crew/. It is prompt-only: it adds reusable skill instructions and persona references, not running software.

Codex:

codex plugin marketplace add gmentat/code-crew
codex plugin add code-crew@code-crew

The first command tells Codex where this repo's plugin marketplace lives. Most users run it once per Codex profile or machine; after that, the second command installs code-crew from that marketplace.

Codex installs plugins/code-crew/: a .codex-plugin/plugin.json manifest, the code-crew skill, and the full persona and workflow files under skills/code-crew/references/.

Claude Code:

claude plugin marketplace add gmentat/code-crew --sparse .claude-plugin plugins
claude plugin install code-crew

Hermes:

hermes skills install gmentat/code-crew/plugins/code-crew/skills/code-crew \
  --category software-development \
  --yes

The GitHub repo-path form lets Hermes track the source and installs the explicitly referenced files under references/ and examples/ together with SKILL.md.

OpenClaw-compatible runtimes: the package includes plugins/code-crew/openclaw.plugin.json. OpenClaw documents local-path installs (openclaw plugins install ./plugins/code-crew from a clone, or openclaw skills install ./plugins/code-crew/skills/code-crew for the bare skill); this repository has not yet verified them against a live OpenClaw binary. Prefer a clone + local-path install over the git: source form — OpenClaw documents SKILL.md-at-source-root for git skill installs, subdirectory git installs are undocumented, and this repo nests the package under plugins/code-crew/. See INSTALL.md.

Cursor: install Code Crew as a native Agent Skill by copying plugins/code-crew/skills/code-crew/ into your project's .cursor/skills/ (or ~/.cursor/skills/ for all projects). The package also ships a Cursor plugin manifest at plugins/code-crew/.cursor-plugin/plugin.json and an explicit-invocation rule for older installations. See CURSOR.md.

For local development and fallback manual installs, see INSTALL.md.

After install

Installing Code Crew makes the code-crew skill available to the host agent. It does not run in the background or review every change automatically; you ask for it when you want the crew.

In Codex, use it in one of three ways:

  • Type /skills, choose code-crew, then write the review request.
  • Invoke it explicitly in the prompt: $code-crew review the current diff.
  • Ask naturally: Use Code Crew to review this PR with the default Knuth + Hickey + Torvalds crew.

In fresh Codex sessions the installed skill may appear as code-crew:code-crew. That is expected. Code Crew is not exposed as a callable review tool; it is a skill the host agent loads when selected or invoked.

Codex may route clearly matching review or architecture prompts to the skill based on its SKILL.md name and description, but users should not rely on it running automatically for every coding task. The predictable path is explicit invocation.

Code Crew does not currently provide /code-crew commands. If command support becomes useful, it should be a thin convenience layer over the same skill, not a separate behavior path.

What's measured

Headlines from experiments/ (read each run's SUMMARY.md for full details):

pp means percentage points. For example, +7pp means recall moved from roughly 20% to 27%, not a 7% relative increase.

The recall headlines below are raw recall. The original fixed-precision primary metric was not computable in the main run because all arms scored far below the 0.70 precision threshold under the skeptic judge, so the public claims use the raw recall analysis and carry that caveat.

  • Multi-perspective beats naive single Claude on PR review recall (+7 percentage points, paired n=50, p=0.004).
  • Three personas beat six. The K+H+T triple (Knuth + Hickey + Torvalds: Donald Knuth, Rich Hickey, and Linus Torvalds) beats the full sextuplet by +6.4 percentage points recall at n=50 (p=0.047) with better precision and lower fabrication. The default recommended crew is 3, not 6.
  • Named archetypes don't improve recall over generic numbered reviewers (Δ ≈ 0, p=0.50). What they do is produce ~18% more semantic divergence between passes, which surfaces as auditable disagreement. Names are for interpretability, not output quality.
  • Preserved-dissent synthesis ≠ better outputs. Dissent visibility is a UX product (reviewer can see who said what); it doesn't improve recall over consensus synthesis.
  • K+H+T is the best tested default, not a magic formula. A follow-up triple search tested 10 of 20 possible 3-persona combinations and found no challenger with a better point estimate, but several challengers are statistical ties and the untested 10 remain open.
  • Direct-naming briefs ("X — author of TAOCP, ...") underperformed archetype-inspired briefs (−3.9pp recall, −3.5pp precision, +9.9pp fabrication; paired n=50). Don't rewrite persona briefs to lead with the person's name and accomplishments.

The repo includes the harness, protocol, analysis scripts, and committed run artifacts so anyone can inspect these claims or re-run the experiment. See the experiment README for the current runner requirements.

Research grounding

Code Crew's design and empirical claims are grounded in the multi-agent-debate, persona-prompting, and persona-fabrication research literature. See RESEARCH.md for the verified canonical reference list with one-paragraph summaries — including:

  • Zheng et al. 2024 When "A Helpful Assistant" Is Not Really Helpful — personas don't reliably improve LLM task performance on average.
  • Luz de Araujo et al. EMNLP 2025 Principled Personas — irrelevant biographical surface attributes can swing performance by ~30pp.
  • Hu et al. 2026 Expert Personas Improve LLM Alignment but Damage Accuracy (PRISM) — accomplishment-list framings degrade closed-form work.
  • Du et al. 2023 Multi-Agent Debate + Liang et al. EMNLP 2024 Encouraging Divergent Thinking — the canonical multi-agent setup and the Degeneration-of-Thought failure mode the K+H+T crew is designed against.
  • Kong et al. NAACL 2024 Role-Play Prompting + Salewski et al. NeurIPS 2023 In-Context Impersonation — what the role description does, not the persona name.
  • Wang et al. ICLR 2023 Self-Consistency — the cheap baseline every multi-agent design has to beat.
  • Deshpande et al. EMNLP 2023 Toxicity in ChatGPT + Kim et al. 2024 Persona is a Double-edged Sword — persona-induced fabrication and the role-play accuracy hit.
  • Agarwal 2026 Refute-or-Promote — ten reviewers unanimously endorsed a non-existent OpenSSL vulnerability; adversarial and empirical gates rejected most candidates. This supports verification as a general design principle, not the effectiveness of Code Crew's specific verifier.
  • Chowdhury et al. 2026 (MSR 2026) — 12 of 13 deployed code-review agents had average signal ratios below 60%; automated review should augment rather than replace human judgment.

The full literature synthesis that informed individual design decisions (a 4-survey LLM workflow report, with broader citations not all independently verified) lives at experiments/2026-06-01-dissent-ablation/RESEARCH_PERSONA_PROMPTING.md.

Why Knuth + Hickey + Torvalds?

The default is K+H+T Classic: Knuth for rigor, Hickey for simplicity/data/time, and Torvalds for maintainer reality. In full: Donald Knuth, Rich Hickey, and Linus Torvalds, used here as reasoning archetypes rather than impersonations. The names are not magic. They are memorable review contracts for three complementary engineering lenses.

Synthetic roles may become useful specialized presets, but they need to beat this default in the harness before replacing it. For v0, K+H+T is the public default because it is the best-tested composition and the easiest version to explain.

It is especially useful when:

  • you want a code review that surfaces what each tradition would actually say
  • you are designing a system and want competing architectural lenses, not the consensus pattern
  • you suspect your code has a problem but the team has talked themselves into liking it
  • you are choosing between paradigms (OO vs. data-oriented, types vs. dynamism, TDD vs. design-first) and want each tradition's strongest case
  • you want disagreement on purpose — engineers who would actually argue with each other

What the crew is

Each persona is a reasoning archetype inspired by the public work, papers, code, talks, and operating style of a real software engineer or computer scientist. None of them claim to speak for the actual person, invent quotations from them, endorse anything in their name, or impersonate them. Several are still living and active; the system uses these archetypes as decision contracts, not identity simulations.

Invocation model

Multi-lens runs are orchestrated by Foreman. Each selected lens is launched as its own subagent or independent execution context, preferably in parallel when the lenses do not depend on each other. The subagents return blind-pass reports; Foreman alone synthesizes the reports and speaks for the crew as a whole.

A single assistant response that roleplays several people in sequence is not a crew run. Single-lens advisory use is allowed, but it should be labeled as one lens rather than a multi-agent review.

Roster

The crew is in AGENTS.md. Specs are in agents/ and agents/council/.

Default crew of 3 (validated by the persona ablation; this is the recommended starting point):

  • Knuth — algorithmic rigor, literate programming, "premature optimization is the root of all evil"
  • Hickey — simple-not-easy, data-oriented, value-and-time reasoning
  • Torvalds — pragmatic systems engineering, brutal code review, ship working code

Extended roster (use for specific angles or one-at-a-time as single-lens calls; adding them to the default 3 measurably degrades synthesis quality):

  • Dijkstra — formal correctness, structured programming, brutal critique of sloppy thinking
  • Liskov — abstraction, substitution, type discipline, system architecture
  • Pike — Unix philosophy, "data structures, not classes," small composable tools

Operations 7 (synthetic 2026 specialist roles for autonomous code work):

  • Foreman — code-review orchestrator; picks the lenses, runs blind passes, synthesizes, gates action
  • Surveyor — codebase cartographer; git archaeology, blast-radius mapping, prior art
  • Forge — AI coding-agent coordinator (Claude Code / Cursor / Aider / autonomous); the only ops role that writes code directly
  • Sentry — security, secrets, license, supply chain, AI provenance; gates external action
  • Telemeter — observability, SLOs, error budgets; reads production back into review
  • Ledger — engineering economics, tech-debt accounting, cost-of-feature
  • Scribe — theory transmission, ADRs, onboarding memory; the operational arm of Naur

Council 6 (extended specialist lenses):

  • Brooks — software project management, conceptual integrity, "no silver bullet"
  • Lamport — distributed systems, formal verification, TLA+
  • Hoare — concurrent computing, the "billion-dollar mistake" (null), correctness contracts
  • Beck — TDD, XP, "make the change easy, then make the easy change"
  • Naur — programming as theory building, mental models over text
  • Armstrong — Erlang, "let it crash," fault tolerance

How to use

Use Foreman as the dispatcher:

  • "Foreman: dispatch Dijkstra as a single-lens subagent on this diff."
  • "Foreman: dispatch Hickey as a single-lens subagent to find the simple version."
  • "Foreman: dispatch Torvalds as a single-lens subagent to decide whether this patch is acceptable."
  • "Foreman: dispatch Liskov as a single-lens subagent to audit the abstraction."
  • "Foreman: dispatch Knuth and Torvalds as independent blind-pass subagents, then synthesize the disagreement."
  • "Foreman: dispatch Beck and Hickey as independent blind-pass subagents; Beck covers the smallest test, Hickey checks whether the design should exist in that shape."

Useful pairings:

Knuth + Torvalds: rigor vs. shipping. They will disagree by design.

Hickey + Beck: data-first vs. test-first. Hickey explicitly criticized TDD; Beck invented it.

Liskov + Hickey: abstraction/types vs. data-oriented composition.

Dijkstra + anyone-pragmatic: he was famously dismissive of working systems; useful as the rigor floor that nothing reaches.

Pike + Kay/OOP-heavy thinkers (Kay not in roster but represented through Liskov's abstraction lens): "data structures, not classes" against the OO mainstream.

Lamport + Torvalds: prove correctness vs. test-and-ship.

Naur alone: when the team has the code right but doesn't share the theory of why, Naur is the only voice that captures what's missing.

For a full code-review run, the operating rhythm is: Foreman dispatches each lens as an independent blind-pass subagent, candidates are merged, claims are checked, and the recommendation is recorded.

Files

  • AGENTS.md — crew manifest and roster
  • project_workflow.md — autonomous code-improvement loop (how ops + archetypes interact on real work)
  • code_review_methods.md — concrete review and improvement methods the crew uses
  • crew_disagreements.md — built-in disagreement map (the seams the system is designed around)
  • safety_floor.md — autonomy boundaries, AI provenance, refusal rules (binding)
  • INSTALL.md — install paths for Codex, Claude Code, Hermes, Cursor, OpenClaw, and AgentSkills-compatible agents
  • NOTICE — license boundary for MIT project files vs CC BY SWE-PRBench-derived experiment data
  • PRIVACY.md — what the prompt-only package does and does not collect
  • CURSOR.md — Cursor install and usage (native Agent Skill on 2.4+, project rule for older versions)
  • plugins/code-crew/ — distributable plugin/skill package
  • plugins/code-crew/CURSOR.md — Cursor usage from the plugin package alone
  • agents/ — core persona files (historical archetypes)
  • agents/operations/ — synthetic ops-agent files (Foreman, Surveyor, Forge, Sentry, Telemeter, Ledger, Scribe)
  • agents/council/ — extended council persona files
  • runs/ — local formal run history, ignored by default unless a run is intentionally published with git add -f

Release hygiene

Cut public releases from tracked Git contents, for example with git archive HEAD or GitHub's source archive. Do not publish a manual zip of a local working tree: ignored directories such as /runs/, /docs/superpowers/, and local tool config folders are developer-local unless intentionally added to Git.