I don’t run claude anymore. I run claude-cowork to think through strategy and write plans. claude-review to audit those plans for gaps. claude-focus for deep single-repo coding. Same binary, completely different behavior — because each alias loads a different system prompt that changes what Claude pays attention to, how it responds, and which patterns it reaches for.
Most people use Claude Code in one mode: general purpose. It’s decent at everything and excellent at nothing. The fix is five lines in your .zshrc.
The Setup
# ~/.zshrc or ~/.bashrc
alias claude-cowork='claude --system-prompt "$(cat ~/.claude/modes/cowork.md)"'
alias claude-review='claude --system-prompt "$(cat ~/.claude/modes/review.md)"'
alias claude-focus='claude --system-prompt "$(cat ~/.claude/modes/focus.md)"'
alias claude-ship='claude --system-prompt "$(cat ~/.claude/modes/ship.md)"'Each mode file is a short system prompt — 50 to 200 lines — that defines three things:
- What to prioritize. Strategy vs code quality vs shipping speed.
- How to respond. Collaborative brainstorming vs adversarial review vs terse execution.
- Which patterns to follow. Playbook methodology vs code standards vs deploy checklist.
That’s it. No plugins, no extensions, no build step. Shell aliases loading text files.
The Modes
claude-cowork — Strategy and Planning
The thinking mode. Reads business docs, asks questions before proposing solutions, writes plans instead of code. When you say “we need to harden security,” it doesn’t jump to settings.json — it asks what the threat model is, writes a phased plan, and connects each phase to a specific risk.
Key behaviors the prompt installs:
- Read context docs (context.md, playbook.md, principles.md) before responding
- Think in terms of plays, actions, and outcomes
- Write plans to disk, not code
- Ask clarifying questions — don’t assume
claude-review — Adversarial Audit
The skeptic. Reads whatever you point it at and looks for gaps, risks, and incorrect assumptions. Groups findings by severity. Suggests specific fixes, not just “this could be better.” Verifies claims by researching actual tool behavior instead of trusting the document’s premises.
Key behaviors:
- Read the entire artifact before commenting
- Group findings: critical → medium → low
- Every finding includes what the plan claims, what’s actually true, and a specific fix
- Independently verify technical claims — don’t trust the document
claude-focus — Deep Single-Repo Coding
The workhorse. Reads the plan from ../plans/, then executes. Stays in one repo. Doesn’t wander into business strategy or adjacent systems. Writes code, writes tests, makes commits. Minimal discussion, maximum output.
Key behaviors:
- Check for a plan file before starting — ask if there isn’t one
- Stay in the current repo — don’t read files outside it
- Write code and tests, not proposals
- Commit incrementally with clear messages
claude-ship — Deploy and Verify
The closer. Runs builds, checks CI, creates PRs, verifies after deploy. Follows the deploy checklist. Reports status without asking permission. If the build fails, it fixes and retries before escalating.
Key behaviors:
- Run the full build and test suite before creating a PR
- Follow the deploy checklist (build → test → PR → deploy → verify)
- Smoke test after deploy — don’t declare success before verification
- Report what happened, don’t ask what to do next
The Real Power: Handoffs
Any single mode is useful. The handoffs between them are where it gets interesting.
claude-cowork: "We need to harden Claude Code security on the Mac Mini"
→ writes plans/cc-security-hardening.md
claude-review: "Review plans/cc-security-hardening.md"
→ finds 3 critical gaps, suggests restructuring around sandbox-first
claude-cowork: "Update the plan to address the review findings"
→ rewrites the plan with sandbox as Phase 1
claude-focus: "Implement the settings.json from plans/cc-security-hardening.md"
→ applies the config, runs verificationEach mode reads the artifacts the previous mode created. The plan file is the handoff contract. No mode needs to know what the other modes did — it reads the file and does its job.
This works because the modes have no shared context. The review session doesn’t know what the planning session was thinking, so it can’t be biased by it. The focus session doesn’t know about the review findings — it just sees the updated plan. Clean handoffs through files on disk.
Writing Your Own Modes
Start with one mode that addresses your biggest pain point. If you keep getting into strategy discussions when you want to code, write a focus mode. If your plans keep shipping with gaps, write a review mode.
A mode prompt has three sections:
## Role
You are [role description]. Your job is [primary objective].
## Priorities
1. [Most important behavior]
2. [Second most important]
3. [Third]
## Patterns
- [Specific instruction for common situation]
- [Specific instruction for common situation]
- [What NOT to do]Keep it under 200 lines. Claude’s context window is valuable — don’t fill it with instructions it won’t follow because there are too many to track. A focused 80-line prompt beats a comprehensive 400-line one.
Version-control your mode files. They evolve as your workflow matures. The review mode I use today is the third iteration — each round of use revealed behaviors I wanted to add or remove.
Why This Works
General-purpose Claude Code is trying to be good at everything simultaneously. It hedges. It asks if you want a plan or code. It offers alternatives when you want execution. It’s playing defense because it doesn’t know what game you’re playing.
A mode prompt removes the ambiguity. “You are reviewing this plan for gaps” is a clear job. Claude stops hedging and starts doing. The quality of output in each mode is noticeably higher than general-purpose mode because Claude isn’t spending reasoning tokens figuring out what you want — you already told it.
Five lines in .zshrc. Fifteen minutes to write your first mode file. Permanently better workflow.