The Force

A Star Wars–themed multi-agent council for Claude Code.

A multi-agent automation system for Claude Code — seven specialized subagents, each named and modeled after a Star Wars character whose personality maps onto its job, three orchestrating slash commands, and a fail-closed safety layer that runs entirely on your machine. It exists to take routine maintenance work (bug fixes, small features, PR review, proposal review) off your plate and hand it to a small council of agents that plan, execute, and review each other before anything reaches you — so the time you'd spend babysitting a terminal goes back to whatever you'd rather be doing.

Why it's called that

Seven agents, each named for a Star Wars archetype that maps cleanly onto its job: a wise router who triages before acting (Yoda), a fussy protocol droid who plans and never touches code directly (C-3PO), a mechanic who does the actual work (R2-D2), an unsentimental critic who reviews the code as written (Anakin), a guardian who checks the security perimeter (Obi-Wan), a drafter who writes the policy before anyone swings a lightsaber (Padmé), and a cold second opinion who reviews the plan with zero investment in it (Windu). The names aren't decoration — they're a mnemonic for what each agent is and isn't allowed to do.

Architecture

flowchart TD
    H[Human: task or proposal path] --> Y[Yoda — router]

    Y -->|Tier 0: trivial fix| R[R2-D2 — executor]
    Y -->|Tier 1-3: needs a plan| C[C-3PO — planner]
    C -->|file map + verify command| R

    R -->|Tier 2-3: review gate| A[Anakin — code reviewer]
    A -->|Tier 3 only: trust boundary| O[Obi-Wan — security reviewer]
    A -->|findings, one corrective loop| R
    O -->|findings, one corrective loop| R

    A --> OUT[Report to human + PR text]
    O --> OUT
    R -->|Tier 0-1, no review needed| OUT

    P[Padmé — proposal drafter] -.->|/propose| W[Windu — cold reviewer]
    W -.->|READY: yes| Y

Loading

Agent	Role	Tools	Can edit code?
Yoda	Single entry point. Triages every task into a tier (trivial / focused / feature / trust-boundary) and summons only the agents that tier needs. Never guarantees safety itself — that's the hook's job.	Read, Grep, Glob, Task	No
C-3PO	Plans. Surveys the codebase once, writes a numbered, atomic checklist to ./.council/TODO.md (with a mandatory branch-isolation step 0), and delegates to R2-D2 with exact files + a verify command.	Read, Grep, Glob, Task, Write	No
R2-D2	Executes. The only agent that writes code, runs commands, or touches git. Owns the debug ladder (read the evidence → instrument → reproduce in isolation → capture runtime state → bisect) — never fixes without a confirmed root cause.	Read, Write, Edit, Grep, Glob, Bash	Yes
Anakin	Reviews correctness, design, state, tests, and maintainability in one aggressive pass. Judges the code as written, not the author's intent. Read-only.	Read, Grep, Glob, Bash (read-only git/lint/test)	No
Obi-Wan	Reviews the security perimeter before anything touching a trust boundary ships: auth, tenant isolation, input validation, idempotency, secrets, error leakage. Read-only.	Read, Grep, Glob	No
Padmé	Drafts proposals. Turns a rough idea or issue into a structured spec (goal, scope, design, trust boundaries, guards, acceptance criteria) grounded in the real codebase.	Read, Grep, Glob, Write	No (proposal docs only)
Windu	Cold-reviews a finished proposal with zero drafting context, against a pre-ship checklist (auth, idempotency, tenant isolation, failure/rollback, observability). Best run in a separate session so nothing leaks in from drafting.	Read, Grep, Glob	No

How they hand off

Everything routes through Yoda, which reads the task, states a one-line tier decision, and calls only what's needed — a one-line typo fix never wakes the whole council. For anything beyond a trivial fix, C-3PO surveys the repo exactly once and writes a plan to ./.council/TODO.md, so R2-D2 never re-discovers the codebase from scratch and never has to guess what "done" means. R2-D2 does the work, ticking off TODO steps as their verify commands pass. For feature-sized changes, Anakin reviews the diff in one pass and its findings get transcribed back into the TODO's "Findings to resolve" section — R2-D2 gets exactly one corrective loop per gate, not an open-ended argument. Anything touching a trust boundary additionally goes to Obi-Wan before it's allowed to ship. Separately, Padmé and Windu run a planning-only pipeline: Padmé drafts a proposal, Windu reviews it cold, and only once Windu says READY: yes does the proposal become a /council task. Every handoff between agents passes a file path, never pasted content — each agent's heavy context stays inside its own window.

The three slash commands

/propose <issue # | feature description | path to existing proposal.md>

Shapes a proposal before any code gets written. If you point it at an existing doc, it skips straight to Windu's cold review. Otherwise Padmé drafts a spec from the template in templates/PROPOSAL_TEMPLATE.md, grounded in your actual codebase, then Windu reviews it with zero drafting context. You iterate the document until Windu returns READY: yes.

/propose 786
/propose "add per-tenant rate limiting to the webhook ingest endpoint"
/propose ./docs/PROPOSAL_rate-limiting.md

/council <path to proposal, or a described task>

The single entry point for getting work done. Yoda triages the task into a tier and runs only the agents that tier needs, then reports once in a tight final format (RESULT, DID, REVIEW, VERIFY).

/council ./docs/PROPOSAL_rate-limiting.md
/council "fix the null pointer in the export CSV button"

/ship [optional extra context]

Once the council (or your own hand-fixed change) passes review, /ship reads ./.council/TODO.md, confirms every definition-of-done box is checked and no findings are unresolved, and generates a PR title + description as markdown — for you to copy. It never runs gh pr create, never pushes, never opens anything itself.

/ship
/ship "also mention this closes #786"

(Two bonus commands, /review and /review-pr, apply the rulesets in rules/ directly to a diff or an open PR without spinning up the council — useful for a quick pass on someone else's code.)

The safety model

Agents are not the safety boundary — an LLM deciding not to run a command is a suggestion, not a guarantee. The actual guarantees live in three places:

1. guard.sh — a fail-closed PreToolUse hook. It intercepts every Bash and PowerShell tool call, before it runs, regardless of which agent issued it. If the hook can't do its job — no working Python interpreter, unparseable input, an unexpected exception — it blocks rather than allows. A safety check that fails open on error isn't a safety check. It denies, by pattern match on the actual command text:

• destructive filesystem/DB ops (rm -rf /, git reset --hard, DROP TABLE, mkfs, fork bombs, writes to raw disk devices)
• any external action — git push, gh pr create/merge/comment, gh issue create/comment, posting to Slack/Discord webhooks — because the council produces text and diffs locally; the human takes every external action by hand, always
• Windows-specific destructive verbs the Bash deny-list would otherwise miss (Remove-Item -Recurse, Format-Volume, Stop-Computer, download-and-iex patterns)
• writes to ~/.claude/ itself from a shell command (reads stay allowed, so agents can still consult their own config — only writes are blocked, forcing config changes through install.sh deliberately rather than a stray sed -i)

2. The lint + test gate. A change is only "verified" when typecheck, lint, and the test suite all pass — never typecheck alone. C-3PO bakes a CI-gate checklist into every TODO.md; if a project genuinely lacks one of the three, that box is marked n/a — <reason> explicitly rather than silently skipped. Yoda's ship gate requires all three green before it will produce PR text.

3. The diff-snapshot mechanism. Because edit/write tool calls are auto-approved during a council run (so it can actually work unattended), R2-D2 captures a baseline.patch at run start (any pre-existing uncommitted WIP) and a run.diff at run end (the full delta vs. origin/main) using only git diff/git merge-base — commands that never prompt and never choke on a dirty index. This is the visibility backstop: even though nothing was approved edit-by-edit, you get one reviewable patch and a one-line diffstat summarizing exactly what changed.

A PostToolUse hook, verify-todo.sh, runs after every edit and flags (without blocking) signs of the plan lying to itself — a checked-off step with no verify: anchor, unchecked acceptance criteria sitting under a claimed "done," or unresolved findings — so drift becomes visible instead of trusted.

Setup

Requires Claude Code and a working python3 / python / py on your PATH (guard.sh needs one to parse tool-call JSON; it fails closed without it).

git clone https://github.com/prsrwt/The-Force.git
cd The-Force
./install.sh

install.sh copies agents/, commands/, hooks/, rules/, and templates/ into ~/.claude/, and merges settings.snippet.json's hooks + permissions into your existing ~/.claude/settings.json (it merges — it won't clobber your theme, model, or other settings). Restart Claude Code afterward.

Windows note: the Notification/Stop hooks call notify.ps1 for a desktop toast + sound. install.sh resolves the absolute path for you. On macOS/Linux, swap those two hook commands in ~/.claude/settings.json for your own notifier (terminal-notifier, notify-send) — notify.ps1 is Windows-only.

Everything here is global, not per-project: agents and commands work the same way in any repo you run Claude Code from.

Repo layout

agents/       the seven subagent definitions (frontmatter + prompt)
commands/     /propose, /council, /ship, /review, /review-pr
hooks/        guard.sh, verify-todo.sh, notify.ps1
rules/        example PR-review ruleset the agents apply (customize freely)
templates/    PROPOSAL_TEMPLATE.md — the canonical proposal doc shape
docs/         HANDOFF.md — the shared-state convention agents use to hand off work
settings.snippet.json   hooks + permissions block, merged in by install.sh
install.sh    copies everything into ~/.claude/ and merges settings

Why I built this

I kept losing hours to the same loop: small fix comes in, I context-switch, write it, review my own work (badly, because I wrote it), then write the PR description from scratch. None of that needs to be a human in the loop for every step — it needs a plan, someone to execute it, and someone else to check it who isn't biased by having written it. So I split those into agents that can't do each other's job (the reviewer can't edit, the planner can't touch code) and put a hook underneath all of it that doesn't trust any of them with anything destructive or external. The payoff isn't that it's fully autonomous — it's that most of the maintenance grind now runs in the background while I get to spend that time on the thing I was actually trying to protect it for.