Claude Code: 5 Workflows That Make 14 Commands Actually Useful

01: Set Up Project Context First

1. /init: Onboard to a New Repository

When entering an unfamiliar repository, many developers immediately ask Claude to fix an issue. If the project will see ongoing development, run /init first. It reads the project structure and generates or updates a project-level CLAUDE.md file capturing directory layout, common commands, tech stack, and fixed conventions. This turns one-time chat context into reusable project context for all future tasks.

Best for: first time adopting a repo, major structural changes, or when CLAUDE.md is severely outdated. Do not assume /init means Claude fully understands the entire codebase; generated test commands, deploy commands, and security boundaries still warrant manual review.

2. /memory: Store Long-Term Project Rules

Rules that apply to every future task—e.g., "Always suggest tests first", "Prefer composition over inheritance", "Never use any without explicit permission"—belong in long-term memory via /memory, not repeated in each session. Decision rule: will this rule still hold in two weeks? If it only relates to today's requirement, keep it out of memory to avoid context bloat.

02: Long Tasks Lose Control via Context, Not Code

3. /btw: Handle Side Questions Without Polluting Main Task

Mid-coding questions like /btw refresh token vs session cookie trade-offs? are common but often unrelated to the current change. /btw isolates these side queries so the main task doesn't branch into a sprawling tree. Suitable for terminology checks, syntax confirmation, quick comparisons. Not a background parallel task; complex follow-ups deserve a separate task or new session.

4. /context: Diagnose Before Compressing

When responses repeat, constraints are dropped, and the model seems to lose focus, the instinct is to run /compact. Better: first run /context to see what fills the context—chat length, tool output volume, or a heavy instruction. Identifying the root cause prevents the same bloat from returning quickly after compression.

5. /compact: Keep What Matters, Discard the Rest

After a long task, only the current goal, confirmed decisions, key files, and open questions need retention. Failed attempts, disproven hypotheses, and abandoned approaches can be dropped. /compact compresses the conversation into a shorter, workable context. Warning: compression is not lossless archival. Critical commands, interface contracts, failure reasons, and must-keep decisions should be written to project files, issues, or task records before compacting.

6. /cost: Monitor Spend, Don't Guess

Multi-turn agent operations, large file reads, and retries silently increase cost. /cost shows current session usage; check before expanding a task. It reports past usage only—not a predictor. Model, account, cache hits, and context length all affect the next run. Treat it as a bill review, not a universal savings formula.

03: Let the Terminal Do Some Work

7. ! command: Run Shell Commands Inside the Session

Instead of switching to a terminal, copying output, and pasting back, run commands directly: ! git status, ! npm test, ! npm install. The article also shows ! git add . but cautions that staging changes modifies the working tree and should not be grouped with read-only commands. Safer sequence: ! git status, explicitly specify files, then ! git diff --cached to verify staged content. The ! prefix suits short tests, version checks, status reads, and known scripts—not a permission bypass for destructive, network, credential, or production commands.

8. /model: Switch Models When Task Nature Changes

Complex architecture analysis, cross-file debugging, and code review benefit from heavier models. Simple renames, formatting, or boilerplate do not. Use /model when the task type shifts, not because a response felt slow. A better model cannot rescue a poorly defined task; clear inputs and tests remain essential.

9. /effort: Adjust Reasoning Depth Without Changing Model

Where supported, /effort acts as a reasoning-investment knob. Increase for complex problems needing deeper thought; decrease for localized, mechanical work. Distinction: /model swaps the model; /effort adjusts response strategy within the current model's capabilities. Available tiers and model support must be verified via /help and current docs.

10. /fast: Speed for Low-Risk Iteration, Not Complex Debugging

Prototyping, quick direction trials, and small scoped edits suit speed priority. For complex debugging, critical code review, or causal explanation, speed-first degrades quality. Do not treat /fast as a fixed multiplier; without controlled same-task, same-account, same-environment benchmarks, speed gains and quality impact are unverifiable.

04: Don't Trust Generated Code Immediately

11. /review: Separate Generation from Review

The most dangerous step after Claude writes code is assuming it's correct. /review deliberately splits generation and review. Recommended sequence:

! git diff
/review
! npm test

First see what changed, then invoke a dedicated review pass focusing on diffs, edge cases, logic risks, and maintenance cost, finally run the project's own tests. Example review output:

Line 42: potential null reference — handle missing key
Line 87: inefficient loop — consider using map instead
Line 103: security risk — sanitize user input

These are checklist items, not final verdicts. /review does not replace tests, security scans, or human sign-off; it adds an independent perspective.

05: When Things Break, Don't Reinstall First

12. /clear: Reset a Polluted Session

When a session loops or an early wrong assumption contaminates later reasoning, adding more prompts worsens the mess. /clear wipes the current session context, letting you restart from project files and a clear task. Before clearing, ensure key decisions are persisted to CLAUDE.md, issues, code comments, or task records—otherwise they disappear with the context.

13. /doctor: Diagnose Environment Issues

Command failures, permission anomalies, unclear install state, or terminal integration glitches: run /doctor before reinstalling. It checks Claude Code's own config and environment for obvious problems. Not a universal fixer; network, proxy, org policies, third-party MCPs, and project build errors require separate investigation. Think of it as narrowing the search space.

14. /terminal-setup: Fix Terminal Integration

If Claude Code's terminal interaction is misconfigured, /terminal-setup addresses the integration layer, not the project. After running, verify shell, OS, and permissions are supported. If you only forgot a command name, /help is faster.

In fact, /help may be the single most durable entry point. Claude Code updates rapidly; today's command list may change by next quarter. The reliable habit is knowing where to look when memory fails.

06: The 5 Workflows Worth Remembering

The 14 entry points map cleanly to five workflow categories:

First time in a project : /init, verify CLAUDE.md; truly enduring rules go to /memory.

Long task gets heavy : side questions via /btw; diagnose with /context then /compact; optionally /cost for usage check.

Need project commands : ! git status, ! git diff, test commands; confirm risk before write operations.

Task difficulty shifts : consider /model, /effort; only use /fast for low-risk speed phases.

Ready to deliver : view diff → /review → run tests → human acceptance.

Environment anomaly : /doctor first; terminal issues → /terminal-setup; session pollution → /clear; forgotten commands → /help.

The minimal viable workflow compresses to these six steps. Ultimately, the commands are just entry points; engineering constraints—accurate project docs, controlled context, bounded permissions, appropriate model-task fit, and tested code—determine whether the workflow runs stably.

07: Reference Materials

Claude Code Commands — code.claude.com

Claude Code Interactive Mode — code.claude.com

Claude Code Memory — code.claude.com

Claude Code Costs — code.claude.com

Claude Code Model Configuration — code.claude.com

Claude Code Code Review — code.claude.com

Claude Code Changelog — code.claude.com