Toru Claude Agents

Toru Claude Agents

A dev workflow for Claude Code that won't call your work done until your tests, linter and build exit zero — and won't call it mergeable until a security audit passes. Seven specialists run it. Install is two commands.

Built by ToruAI — this is how we work with Claude Code, packaged as we actually use it.

Quick Start

Inside Claude Code:

/plugin marketplace add ToruAI/toru-claude-agents
/plugin install toru-claude-agents@toru-claude-agents

Then restart Claude Code so the new agents and skills load. That's the whole install — memory comes with the plugin, and your own settings.json, agents and skills are untouched.

/scout what does this codebase do?          ← try it first, read-only
/dev-cycle implement user authentication    ← the actual workflow

Three things to know before you install

• It costs ~1.1k tokens of always-on context. Seven agent descriptions plus fourteen skill descriptions. Nothing else loads until you invoke it. Don't take our word for it — claude plugin details toru-claude-agents prints the measured number.
• It blocks git push. Agents commit as much as they like; publishing stays your decision, because it's the one thing an agent can't take back. How to remove it.
• These agents aren't built to agree with you. Sentinel doesn't soften findings — "this is exploitable", not "this could potentially be a concern". Bob says so before building when the spec is contradictory. Scout reports that your premise was wrong rather than answering the question you asked. If you want an assistant that nods, install something else.

git clone https://github.com/ToruAI/toru-claude-agents.git
cd toru-claude-agents
./install.sh              # Global install to ~/.claude/
./install.sh --local      # Local install to ./.claude/ (current project only)
./install.sh --dry-run    # Preview exactly what it would change — read this first

Why this instead of a bigger collection

Most collections hand you a hundred agents and leave the orchestration to you. This is the opposite bet: a small roster wired into one pipeline with objective exit conditions.

/dev-cycle   →   /dev-qa   →   /dev-security   →   /dev-rc   →   /dev-finish
  plan+build     tests,lint    Sentinel audit     last gate    commit+learnings

Exit conditions are machine-checked, not vibes: tests pass, lint clean, types clean, audit green. If they don't, the loop goes back to work. Session state lives in a file, so closing your terminal doesn't lose the thread.

That's the trade: fewer agents, but they run a process. If you want breadth, the big collections are genuinely better at breadth.

The Team

Four agents do the development work: