crew

Build a crew of named, persona-driven Claude Code agents that persist memory, log their work, and reflect conversationally on accumulated experience.

What is a "crew"?

A crew is a small set of Claude Code agents you build for yourself, each with a distinct identity:

• A name (Interstellar-style by default — TARS, CASE, KIPP, PLEX — though custom names are first-class).
• A persona — focus areas, working style, anti-patterns, strong opinions.
• A directory tree at ~/.claude/agent-state/<name>/ for memory and activity logs.
• A subagent definition at ~/.claude/agents/<name>.md so other agents can delegate to it.
• A shell alias so you can start a top-level Claude session as that agent (tars, case, etc.).

The point isn't novelty — it's making generic roles concrete. "Software engineer" is too broad to be useful; TARS the SE who pushes for tests early on Go backends is a tool you can reach for. Names give you something to reason about ("can I delegate this to TARS?", "would CASE handle this differently?"), and the persistent state lets each crew member accumulate judgment over time.

Why crew?

Named identity makes delegation tangible. Generic subagents are stateless function calls. Crew members have a persona, history, and accumulated learnings — you can have a manager agent (CASE) that decides which crew member to delegate to, and the choice carries meaning beyond "an SE will do this."

Personalization at the role level. Two software engineers on a real team aren't interchangeable — one prefers TDD, one optimizes for ship velocity, one specializes in performance work. Crew lets you encode that distinction.

Persistence enables learning. Activity logs accumulate. Memory files grow. Reflection (/dream) finds patterns and discusses them with you in real time. Over weeks, a crew member's judgment sharpens in directions you've shaped through corrections — without you having to manually edit prompts every time.

Dual-mode invocation. Each crew member works two ways:

1. As a subagent — another agent delegates to them via the Agent tool.
2. As a top-level session — you type tars in a shell and converse directly.

Same persona file feeds both modes.

The two skills

/recruit

Creates a new crew member. Walks through naming (suggests Interstellar-style candidates, accepts custom names), persona elicitation (3–5 targeted questions about focus / style / anti-patterns), and full scaffolding: persona file, state directory tree, shell alias.

/dream <name>

Reflection cycle for a crew member. A subagent reads the accumulated activity log, existing memory, and prior dream-reflection blocks — then surfaces findings to you in chat, always with cited log evidence, never speculative. You walk them one at a time: apply (memory edit, persona refinement), refine then apply, or pass on with a one-line reason. A single ## Dream reflection block is appended to today's log recording what was applied and what was passed on; future dreams read that block to avoid re-surfacing the same patterns. No queue, no review step.

Lifecycle of a crew member

  /recruit ──→ persona + state dir + alias
                          │
                          ▼
              Sessions accumulate logs
              (top-level or as subagent)
                          │
                          ▼
                  /dream <name>
        subagent finds cited patterns
                          │
                          ▼
           conversation: apply / refine / pass
                          │
                          ▼
          single "## Dream reflection" block
          appended to today's log file
          (Applied: ... / Passed on: ... + reasons)
                          │
                          ▼
        next dream reads it, won't re-surface
        the same patterns

Installation

This plugin contains two skills. The crew member personas you create are personal and stay on your machine — they're not part of the plugin.

As a Claude Code plugin (recommended)

If you have a marketplace configured (see Claude Code plugin docs), add this repo as a source. Then enable in ~/.claude/settings.json:

{
  "enabledPlugins": {
    "crew@your-marketplace": true
  }
}

Local development / direct install

Clone this repo, then add to your shell rc file:

# Add to your existing CLAUDE_LOCAL_PLUGINS array, or create one:
CLAUDE_LOCAL_PLUGINS=(
  ~/work/crew-plugin
  # ...other plugins
)

_claude_plugin_flags() {
  local flags=""
  for p in "${CLAUDE_LOCAL_PLUGINS[@]}"; do
    flags+=" --plugin-dir $p"
  done
  echo "$flags"
}

alias c='claude $(_claude_plugin_flags)'

The plugin's skills load when you launch Claude with the --plugin-dir flag.

Without any plugin infrastructure

Symlink or copy the skills into ~/.claude/skills/:

ln -s ~/work/crew-plugin/skills/recruit ~/.claude/skills/recruit
ln -s ~/work/crew-plugin/skills/dream   ~/.claude/skills/dream

Quick start

In a Claude Code session with the plugin loaded:

/recruit

The skill will ask what role and style you want, suggest 3–5 names, and walk you through persona elicitation. After a few minutes you'll have your first crew member. The skill creates a one-time ~/.claude/crew-aliases.sh file and prints a single line to add to your ~/.zshrc (or ~/.bashrc):

[ -f ~/.claude/crew-aliases.sh ] && source ~/.claude/crew-aliases.sh

After sourcing your rc file (or opening a new terminal), you can run your crew member as a top-level session by typing their name. Future recruit runs only append to crew-aliases.sh — your rc file is never touched again.

File layout

What the skills create:

~/.claude/agents/
  tars.md                         # subagent definition (used by Agent tool)
  case.md                         # ...

~/.claude/agent-state/
  tars/
    memory/                       # persistent learned preferences/patterns
    log/                          # daily activity log (raw material for /dream;
                                  # also where /dream appends its reflection blocks)

~/.claude/crew-aliases.sh         # all crew shell aliases, one per crew member

The recruit skill manages all of this. You can edit any of these files by hand at any time — it's just markdown and shell aliases.

Recommended permissions for autonomous crew members

Crew members like a "software engineer" persona benefit from broad permissions so they can git, test, push, and open PRs without per-tool prompts. Add to ~/.claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(git add*)", "Bash(git commit*)", "Bash(git push*)",
      "Bash(git checkout*)", "Bash(git switch*)", "Bash(git fetch*)",
      "Bash(git pull*)", "Bash(git merge*)", "Bash(git rebase*)",
      "Bash(git worktree*)", "Bash(git stash*)", "Bash(git restore*)",
      "Bash(gh pr*)", "Bash(gh issue*)", "Bash(gh run*)", "Bash(gh api*)",
      "Bash(npm test*)", "Bash(npm run*)", "Bash(npx*)", "Bash(yarn*)",
      "Bash(mvn*)", "Bash(./mvnw*)", "Bash(gradle*)", "Bash(./gradlew*)",
      "Bash(go test*)", "Bash(go build*)", "Bash(go run*)",
      "Bash(pytest*)", "Bash(make*)"
    ]
  }
}

Note: these apply to all your Claude Code sessions, not just crew members — Claude Code permissions are user-global. If you want strict scoping (crew members only), pass a separate settings file via --settings ~/.claude/agents/<name>-settings.json on the alias. Trade-off: scoping breaks subagent inheritance — when another agent delegates to a scoped crew member, the parent's narrower permissions apply.

Things that are deliberately not in the recommended allowlist (still prompt for safety):

• git push --force (matches git push* — relies on persona discipline; safe in worktree-isolated work).
• Branch deletes (git branch -D, git push --delete).
• gh repo create / gh repo delete.
• Anything destructive outside the worktree.

Design philosophy

A few principles the skills lean on:

Cited evidence over creative writing

/dream is the riskiest part of the system — without grounding, an agent reflecting on its own work tends to hallucinate plausible-sounding "improvements" that drift the persona over time. The skill enforces a rule: every finding must cite specific log entries. Patterns cited twice or more are stronger than one-off observations. Findings without citations are dropped before they reach the conversation.

Passed-on reasons are the real feedback signal

When you pass on a finding, the dream-reflection log block captures a one-line reason. Future dreams read those reasons and avoid re-surfacing the same idea. Without this, you'd see the same suggestion cycle back every dream and quickly disable the system. A curt reason is fine — capture something.

The activity log is the only ground truth

Reflection only works if there's something to reflect on. Crew member personas are scaffolded with an instruction to append a short log entry at end of each meaningful session — three sections: what I did / what worked / what got corrected. Keep entries terse; they're raw material, not prose. /dream appends its own ## Dream reflection blocks to the same daily log file — same surface, no separate archive.

Persona changes are the highest-risk approval

Memory updates are reversible (delete the file). Persona changes drift identity. /dream always confirms persona edits twice and re-shows the diff before applying.

Dual-mode pushback

Crew members can push back on ambiguous tasks. In top-level mode this is conversational — the agent asks before doing anything. In subagent mode there's no back-and-forth (a subagent gets one message in, returns one message out), so pushback has to be structured into the return: a Status: blocked — clarification needed response with explicit questions, no code written, no PR opened. The calling agent routes those questions to you and re-invokes when answered.

Worktree isolation as a safety net

Crew members that write code (like a software engineer) are often configured to work in their own git worktree at <repo>/.worktrees/<branch-slug>/. This lets them operate alongside other crew members and you without conflicts, and bounds the blast radius of any autonomous action — the worktree is throwaway, the parent repo is untouched.

Customizing personas

The recruit skill walks you through persona elicitation, but the resulting ~/.claude/agents/<name>.md is just a markdown file. Edit it any time. Common customizations:

• Tighten or loosen the verification mandate.
• Add domain-specific knowledge (frameworks, internal tooling).
• Adjust the autonomy boundary (what requires approval).
• Reference other skills the persona should preferentially use.

Edits take effect on the persona's next invocation.

What this plugin does NOT include

• Your specific crew members. Each user creates their own via /recruit. The TARS one user has and the TARS another user has should be different — different specializations, different opinions, different orgs.
• Permission settings. Recommended above, but never auto-installed — permissions are personal.
• Shell rc edits. The recruit skill prints a one-line edit instruction the first time you run it; the user applies it manually.

What's not built yet

• Cross-agent dreaming. One crew member running /dream for another (e.g., CASE running dream for TARS) is documented as a pattern in the dream skill but not exercised. Mechanically it works today.
• Scheduled dreaming. /dream runs on demand. Wrapping it in a recurring schedule (e.g., weekly per crew member) is straightforward via Claude Code's schedule skill once cadence and signal-to-noise feel right.

License

MIT (or your choice — update before publishing).