{"slug": "how-boris-cherny-uses-claude-code", "title": "How Boris Cherny Uses Claude Code", "summary": "Boris Cherny, creator of Claude Code at Anthropic, shared 13 practical tips for using the tool, including running 5 instances simultaneously in separate git checkouts, using Opus 4.5 with thinking mode for all tasks, and maintaining a shared CLAUDE.md file that the team updates via PR comments. His workflow emphasizes parallel sessions, plan mode, and slash commands to maximize efficiency.", "body_md": "Boris created Claude Code at Anthropic. When asked how he uses it, he shared 13 practical tips from his daily workflow. His setup is \"surprisingly vanilla\" — proof that CC works great out of the box.\n\nBoris runs **5 instances of Claude Code simultaneously** in his terminal using **5 separate git checkouts** of the same repo. He numbers his tabs 1-5 for easy reference and uses system notifications to know when any Claude needs input.\n\n```\nKey detail\n                        Each tab runs in its own git checkout, so Claude can make changes in parallel without conflicts. Configure iTerm2 notifications to know when any Claude needs attention.\n~/repo-1 $ # Tab 1: Working on feature\n~/repo-2 $ # Tab 2: Running tests\n~/repo-3 $ # Tab 3: Code review\n~/repo-4 $ # Tab 4: Debugging\n~/repo-5 $ # Tab 5: Documentation\n```\n\nBeyond the terminal, Boris runs **5-10 additional sessions on claude.ai/code**. He fluidly hands off between local and web using the `&`\n\ncommand or `--teleport`\n\nflag.\n\nHe also kicks off sessions from his phone via the Claude iOS app in the morning, then picks them up on his computer later.\n\n```\nKey commands\n& — Background a session\n--teleport — Switch contexts between local and web\n```\n\nBoris uses **Opus 4.5 with thinking mode** for every task. His reasoning:\n\n```\nWhy Opus over Sonnet\n                        \"It's the best coding model I've ever used, and even though it's bigger & slower than Sonnet, since you have to steer it less and it's better at tool use, it is almost always faster than using a smaller model in the end.\"\n```\n\nThe takeaway: **less steering + better tool use = faster overall results**, even with a larger model.\n\nThe team shares a single **CLAUDE.md** file for the Claude Code repo, checked into git. The whole team contributes multiple times a week.\n\n```\nKey practice\n                        \"Anytime we see Claude do something incorrectly we add it to the CLAUDE.md, so Claude knows not to do it next time.\"\nbash\nclaude-cli $ cat CLAUDE.md\n# Development Workflow\n**Always use `bun`, not `npm`.**\n# 1. Make changes\n# 2. Typecheck (fast)\nbun run typecheck\n\n# 3. Run tests\nbun run test -- -t \"test name\"    # Single suite\nbun run test:file -- \"glob\"       # Specific files\n# 4. Lint before committing\nbun run lint:file -- \"file1.ts\"   # Specific files\nbun run lint                      # All files\n# 5. Before creating PR\nbun run lint:claude && bun run test\n```\n\nDuring code review, Boris tags **@.claude** on PRs to add learnings to the CLAUDE.md as part of the PR itself.\n\nThey use the Claude Code GitHub Action (`/install-github-action`\n\n) for this. Boris calls it their version of **\"Compounding Engineering\"** — inspired by Dan Shipper's concept.\n\n```\n// Example PR comment:\nnit: use a string literal, not ts enum\n@claude add to CLAUDE.md to never use enums,\nalways prefer literal unions\nResult\n                        Claude automatically updates the CLAUDE.md and commits: \"Prefer `type` over `interface`; **never use `enum`** (use string literal unions instead)\"\n```\n\nMost sessions start in **Plan mode** (shift+tab twice). Boris iterates on the plan with Claude until it's solid, then switches to auto-accept mode.\n\n```\nThe workflow\n                        Plan mode → Refine plan → Auto-accept edits → Claude 1-shots it\n> i want to improve progress notification\n  rendering for skills. can you make it look\n  and feel a bit more like subagent progress?\n▮▮ plan mode on (shift+tab to cycle)\n```\n\n**\"A good plan is really important to avoid issues down the line.\"**\n\nBoris uses slash commands for workflows he does **many times a day**. This saves repeated prompting, and Claude can use them too.\n\nCommands are checked into git under `.claude/commands/`\n\nand shared with the team.\n\n```\n> /commit-push-pr \n\n  /commit-push-pr     Commit, push, and open a PR\nPower feature\n                        Slash commands can include inline Bash to pre-compute info (like git status) for quick execution without extra model calls.\n```\n\nBoris thinks of subagents as **automations for the most common PR workflows**:\n\n```\nExamples\ncode-simplifier — Cleans up code after Claude finishes\nverify-app — Detailed instructions for end-to-end testing\n```\n\nThe team uses a **PostToolUse hook** to auto-format Claude's code. While Claude generates well-formatted code 90% of the time, the hook catches edge cases to prevent CI failures.\n\nInstead of `--dangerously-skip-permissions`\n\n, Boris uses **/permissions** to pre-allow common safe commands. Most are shared in `.claude/settings.json`\n\n.\n\n```\n> /permissions\nPermissions: Allow  Ask  Deny  Workspace\n\nClaude Code won't ask before using allowed tools.\n\n↑ 12.  Bash(bq query:*)\n  13.  Bash(bun run build:*)\n  14.  Bash(bun run lint:file:*)\n  15.  Bash(bun run test:*)\n  16.  Bash(bun run test:file:*)\n  17.  Bash(bun run typecheck:*)\n  18.  Bash(bun test:*)\n  19.  Bash(cc:*)\n  20.  Bash(comm:*)\n> 21.  Bash(find:*)\n```\n\nClaude Code uses all of Boris's tools autonomously:\n\n``` bash\nclaude-cli-2 $ cat .mcp.json\n{\n  \"mcpServers\": {\n    \"slack\": {\n      \"type\": \"http\",\n      \"url\": \"https://slack.mcp.anthropic.com/mcp\"\n    }\n  }\n}\n```\n\nFor very long-running tasks, Boris ensures Claude can work uninterrupted:\n\n```\nOptions\n(a) Prompt Claude to verify with a background agent when done\n(b) Use an agent Stop hook for deterministic checks\n(c) Use the \"ralph-wiggum\" plugin (community idea by @GeoffreyHuntley)\n```\n\nFor sandboxed environments, he'll use `--permission-mode=dontAsk`\n\nor `--dangerously-skip-permissions`\n\nto avoid blocks.\n\n```\n* Reticulating... (1d 2h 47m · ↓ 2.4m tokens · thinking)\n\n>\n```\n\n**This is Boris's #1 tip:**\n\n```\nKey insight\n                        \"Probably the most important thing to get great results out of Claude Code — give Claude a way to verify its work. If Claude has that feedback loop, it will 2-3x the quality of the final result.\"\n```\n\nFor his own changes to claude.ai/code, Claude uses the **Claude Chrome extension** to open a browser, test UI changes, and iterate until it works perfectly.\n\nVerification varies by domain: Bash commands, test suites, simulators, browser testing, etc. The key is giving Claude a way to close the feedback loop.\n\n```\nTakeaway\n                        Invest in domain-specific verification for optimal performance. Claude tests every single change Boris lands to claude.ai/code.\n```\n\nBoris shared 10 more tips on January 31, 2026. These are sourced directly from the Claude Code team — remember, everyone's setup is different. Experiment to see what works for you!\n\nSpin up **3-5 git worktrees at once**, each running its own Claude session in parallel. It's the single biggest productivity unlock, and the top tip from the team.\n\n```\nWhy worktrees over checkouts\n                        Most of the Claude Code team prefers worktrees — it's the reason @amorriscode built native support for them into the Claude Desktop app!\n```\n\nSome people also name their worktrees and set up **shell aliases (za, zb, zc)** so they can hop between them in one keystroke. Others have a dedicated \"analysis\" worktree that's only for reading logs and running BigQuery.\n\n``` bash\n$ git worktree add .claude/worktrees/my-worktree origin/main\n\n$ cd .claude/worktrees/my-worktree && claude\n\n# Claude Code v2.1.29\n# Opus 4.5 · Claude Enterprise\n# .claude/worktrees/my-worktree\n```\n\nPour your energy into the plan so Claude can **1-shot the implementation**. Don't keep pushing when things go sideways — switch back to plan mode and re-plan.\n\n```\nTeam patterns\n                        One person has one Claude write the plan, then they spin up a second Claude to review it as a staff engineer. Another says the moment something goes sideways, they switch back to plan mode and re-plan.\n```\n\nThey also explicitly tell Claude to enter plan mode for **verification steps, not just for the build**.\n\n```\n> Try \"refactor cli.tsx\"\n\n▮▮ plan mode on (shift+Tab to cycle)\n```\n\nAfter every correction, end with: **\"Update your CLAUDE.md so you don't make that mistake again.\"** Claude is eerily good at writing rules for itself.\n\n```\nKey practice\n                        Ruthlessly edit your CLAUDE.md over time. Keep iterating until Claude's mistake rate measurably drops.\n```\n\nOne engineer tells Claude to maintain a **notes directory for every task/project**, updated after every PR. They then point CLAUDE.md at it.\n\n```\nMemory files  ·  /memory\n└ ~/.claude/CLAUDE.md: 76 tokens\n└ CLAUDE.md: 4k tokens\n```\n\nCreate your own skills and **commit them to git**. Reuse across every project.\n\n```\nTips from the team\n\nIf you do something more than once a day, turn it into a skill or command\nBuild a /techdebt slash command and run it at the end of every session to find and kill duplicated code\nSet up a slash command that syncs 7 days of Slack, GDrive, Asana, and GitHub into one context dump\nBuild analytics-engineer-style agents that write dbt models, review code, and test changes in dev\n```\n\nEnable the **Slack MCP**, then paste a Slack bug thread into Claude and just say \"fix.\" Zero context switching required.\n\nOr, just say **\"Go fix the failing CI tests.\"** Don't micromanage how.\n\n```\nPro tip\n                        Point Claude at docker logs to troubleshoot distributed systems — it's surprisingly capable at this.\n> fix this https://ant.slack.com/archives/...\n\n● slack - search_public (MCP)(query: \"in:C07VBS...\")\n  Searches for messages in public Slack ch...\n\n'slack_search_public' does NOT generally\nfor user consent to use 'slack_search_p...\n```\n\n**a. Challenge Claude.** Say \"Grill me on these changes and don't make a PR until I pass your test.\" Make Claude be your reviewer. Or, say \"Prove to me this works\" and have Claude diff behavior between main and your feature branch.\n\n**b. After a mediocre fix,** say: \"Knowing everything you know now, scrap this and implement the elegant solution.\"\n\n**c. Write detailed specs** and reduce ambiguity before handing work off. The more specific you are, the better the output.\n\n```\nKey insight\n                        Don't accept the first solution. Push Claude to do better — it usually can.\n```\n\nThe team loves **Ghostty**! Multiple people like its synchronized rendering, 24-bit color, and proper unicode support.\n\nFor easier Claude-juggling, use **/statusline** to customize your status bar to always show context usage and current git branch. Many of us also color-code and name our terminal tabs, sometimes using tmux — one tab per task/worktree.\n\n```\nVoice dictation\n                        Use voice dictation. You speak 3x faster than you type, and your prompts get way more detailed as a result. (Hit fn x2 on macOS)\n┌──────────────────────────────────────────┐\n│ ● ● ●  │  1 ⌘1  │  2 ● ⌘2  │  3 ⌘3  │  4 │\n├──────────────────────────────────────────┤\n│ × * Claude Code (node)                   │\n│                                          │\n│ Claude Code v2.1.29                      │\n│ Opus 4.5 · Claude Enterprise             │\n│ /code/claude                             │\n└──────────────────────────────────────────┘\n```\n\n**a.** Append \"use subagents\" to any request where you want Claude to throw more compute at the problem.\n\n**b.** Offload individual tasks to subagents to keep your main agent's context window clean and focused.\n\n**c.** Route permission requests to Opus 4.5 via a hook — let it scan for attacks and auto-approve the safe ones.\n\n```\n> use 5 subagents to explore the codebase\n\n● I'll launch 5 explore agents in parallel to...\n● Running 5 Explore agents... (ctrl+o to expand)\n  ├─ Explore entry points and startup · 10 t...\n  │  └ Bash: Find CLI or main entry files\n  ├─ Explore React components structure · 14...\n  │  └ Bash: ls -la /Users/boris/code/clau...\n  ├─ Explore tools implementation · 14 tool...\n  │  └ Bash: Find tool implementation files\n  ├─ Explore state management · 13 tool uses\n  │  └ Search: **/screens/REPL.tsx\n  └─ Explore testing infrastructure · 13 to...\n     └ Search: test/mocks/**/*.ts\n```\n\nAsk Claude Code to use the **\"bq\" CLI** to pull and analyze metrics on the fly. We have a BigQuery skill checked into the codebase, and everyone on the team uses it for analytics queries directly in Claude Code.\n\n```\nBoris's take\n                        \"Personally, I haven't written a line of SQL in 6+ months.\"\n```\n\nThis works for **any database that has a CLI, MCP, or API**.\n\nA few tips from the team to use Claude Code for learning:\n\n**a.** Enable the \"Explanatory\" or \"Learning\" output style in /config to have Claude explain the *why* behind its changes.\n\n**b.** Have Claude generate a **visual HTML presentation** explaining unfamiliar code. It makes surprisingly good slides!\n\n**c.** Ask Claude to draw **ASCII diagrams** of new protocols and codebases to help you understand them.\n\n**d.** Build a **spaced-repetition learning skill**: you explain your understanding, Claude asks follow-ups to fill gaps, stores the result.\n\n```\nKey takeaway\n                        Claude Code isn't just for writing code — it's a powerful learning tool when you configure it to explain and teach.\n```\n\nBoris shared 12 more tips on February 11, 2026. This time the theme is customization — hooks, plugins, agents, permissions, and all the ways to make Claude Code your own.\n\nA few quick settings to make Claude Code feel right in your terminal:\n\n```\nKey settings\n\nTheme: Run /config to set light/dark mode\nNotifications: Enable notifications for iTerm2, or use a custom notifs hook\nNewlines: If you use Claude Code in an IDE terminal, Apple Terminal, Warp, or Alacritty, run /terminal-setup to enable shift+enter for newlines (so you don't need to type \\)\nVim mode: Run /vim\n```\n\nRun `/model`\n\nto pick your preferred effort level:\n\n```\nEffort levels\n\nLow — less tokens & faster responses\nMedium — balanced behavior\nHigh — more tokens & more intelligence\n```\n\nPersonally, I use **High for everything**.\n\n```\n||| High effort (default)  ← → to adjust\n\nFast mode is ON and available with Opus 4.6\n```\n\nPlugins let you install **LSPs** (now available for every major language), **MCPs, skills, agents, and custom hooks**.\n\nInstall a plugin from the official Anthropic plugin marketplace, or create your own marketplace for your company. Then, check the `settings.json`\n\ninto your codebase to auto-add the marketplaces for your team.\n\n```\nGetting started\n                        Run /plugin to browse and install plugins.\n```\n\nTo create custom agents, drop `.md`\n\nfiles in `.claude/agents`\n\n. Each agent can have a custom name, color, tool set, pre-allowed and pre-disallowed tools, permission mode, and model.\n\n```\nPro tip\n                        There's a little-known feature that lets you set the default agent used for the main conversation. Just set the \"agent\" field in your settings.json or use the --agent flag.\n> use the sentry errors agent\nsentry-errors(Fetch Sentry error logs)\n\n  Search(pattern: \"sentry\", path: \"src\")\n  +10 more tool uses (ctrl+o to expand)\n```\n\nRun `/agents`\n\nto get started.\n\nClaude Code uses a sophisticated permission system with a combo of **prompt injection detection, static analysis, sandboxing, and human oversight**.\n\nOut of the box, we pre-approve a small set of safe commands. To pre-approve more, run `/permissions`\n\nand add to the allow and block lists. Check these into your team's `settings.json`\n\n.\n\n```\nWildcard syntax\n                        We support full wildcard syntax. Try \"Bash(bun run *)\" or \"Edit(/docs/**)\"\n> /permissions\nPermissions: [Allow]  Ask  Deny\n\n52. Bash(gh issue view:*)\n53. Bash(gh pr checks:*)\n54. Bash(gh pr comment:*)\n55. Bash(gh pr diff:*)\n56. Bash(gh pr list:*)\n```\n\nOpt into Claude Code's **open source sandbox runtime** to improve safety while reducing permission prompts.\n\nRun `/sandbox`\n\nto enable it. Sandboxing runs on your machine, and supports both **file and network isolation**. Windows support coming soon.\n\n```\nSandbox modes\n\nSandbox BashTool, with auto-allow — commands run in sandbox, auto-approved\nSandbox BashTool, with regular permissions — sandbox + normal permission prompts\nNo Sandbox — default behavior\n```\n\nCustom status lines show up right below the composer, and let you show **model, directory, remaining context, cost**, and pretty much anything else you want to see while you work.\n\nEveryone on the Claude Code team has a different statusline. Use `/statusline`\n\nto get started, to have Claude generate a statusline for you based on your `.bashrc`\n\n/`.zshrc`\n\n.\n\n```\n> _\n\n[Opus] 📁 my-app | 🌿 feature/auth\n█████████░░░░░░░░░ 42% | $0.08 | 🕐 7m 3s\n```\n\nDid you know **every key binding in Claude Code is customizable**?\n\nRun `/keybindings`\n\nto re-map any key. Settings live reload so you can see how it feels immediately.\n\n```\nHow it works\n                        Keybindings are stored in ~/.claude/keybindings.json. Claude can generate the config for you — just describe what you want.\n```\n\nHooks are a way to **deterministically hook into Claude's lifecycle**. Use them to:\n\n```\nUse cases\n\nAutomatically route permission requests to Slack or Opus\nNudge Claude to keep going when it reaches the end of a turn (you can even kick off an agent or use a prompt to decide whether Claude should keep going)\nPre-process or post-process tool calls, e.g. to add your own logging\n```\n\nAsk Claude to add a hook to get started.\n\nIt's the little things that make CC feel personal. Ask Claude to customize your spinner verbs to **add or replace the default list** with your own verbs.\n\nCheck the `settings.json`\n\ninto source control to share verbs with your team.\n\n```\n> in my settings, make my spinner verbs star trek themed.\n\n● Update(~/.claude/settings.json)\n\n✱ Beaming up… (esc to interrupt)\n```\n\nRun `/config`\n\nand set an output style to have Claude respond using a **different tone or format**.\n\n```\nRecommended styles\n\nExplanatory — great when getting familiar with a new codebase, to have Claude explain frameworks and code patterns as it works\nLearning — have Claude coach you through making code changes\nCustom — create your own output styles to adjust Claude's voice the way you like\n```\n\nClaude Code is built to work great out of the box. When you do customize, **check your settings.json into git** so your team can benefit, too.\n\nWe support configuring for your codebase, for a sub-folder, for just yourself, or via **enterprise-wide policies**.\n\n```\nBy the numbers\n                        Pick a behavior, and it is likely that you can configure it. We support 37 settings and 84 env vars (use the \"env\" field in your settings.json to avoid wrapper scripts).\n```\n\nBoris announced built-in git worktree support for Claude Code on February 20, 2026. Agents can now run in parallel without interfering with each other — in CLI, Desktop app, IDE extensions, web, and mobile.\n\n`claude --worktree`\n\nfor IsolationTo run Claude Code in its own git worktree, just start it with the `--worktree`\n\noption. You can **name your worktree**, or have Claude name it for you.\n\nUse this to run multiple parallel Claude Code sessions in the same git repo, without the code edits clobbering each other.\n\n``` bash\n$ claude --worktree my_worktree\n# You can also pass --tmux to launch in its own Tmux session\n$ claude --worktree my_worktree --tmux\nWhat changed\n                        The Claude Code Desktop app has had built-in support for worktrees for a while — now it's in the CLI too.\n```\n\nIf you prefer not to use the terminal, head to the **Code tab** in the Claude Desktop app and check the **worktree** checkbox.\n\n```\nHow to enable\n                        Open the Claude Desktop app → Code tab → check the \"worktree\" checkbox. That's it.\n```\n\nSubagents can also use worktree isolation to do more work in parallel. This is especially powerful for **large batched changes and code migrations**.\n\nTo use it, ask Claude to use worktrees for its agents. Available in CLI, Desktop app, IDE extensions, web, and Claude Code mobile app.\n\n```\n> Migrate all sync io to async. Batch up the changes,\nand launch 10 parallel agents with worktree isolation.\nMake sure each agent tests its changes end to end,\nthen have it put up a PR.\n```\n\nYou can also make subagents **always run in their own worktree**. To do that, just add `isolation: worktree`\n\nto your agent frontmatter.\n\n```\n# .claude/agents/worktree-worker.md\n---\nname: worktree-worker\nmodel: haiku\nisolation: worktree\n---\n```\n\nIf you're a **Mercurial, Perforce, or SVN** user, define worktree hooks to benefit from isolation without having to use Git.\n\n``` bash\n$ cat .claude/settings.json\n{\n  ...\n  \"hooks\": {\n    \"WorktreeCreate\": [\n      { \"command\": \"jj workspace add \\\"$(cat /dev/stdin | jq -r '.name')\\\"\" }\n    ],\n    \"WorktreeRemove\": [\n      { \"command\": \"jj workspace forget \\\"$(cat /dev/stdin | jq -r '.worktree_path')\\\"\" }\n    ]\n  },\n  ...\n}\n```\n\nBoris announced two new built-in skills for Claude Code on February 27, 2026: **/simplify** to improve code quality and **/batch** to automate code migrations in parallel. Combined, these automate much of the work it used to take to shepherd a PR to production and perform parallelizable code migrations.\n\nUse **parallel agents** to improve code quality, tune code efficiency, and ensure CLAUDE.md compliance. Just append `/simplify`\n\nto any prompt.\n\n```\n> hey claude make this code change then run /simplify\nWhat it does\n                        Runs parallel agents that review your changed code for reuse opportunities, quality issues, and efficiency improvements — all in one pass.\n```\n\nInteractively plan out code migrations, then **execute in parallel using dozens of agents**. Each agent runs with full isolation using git worktrees, testing its work before putting up a PR.\n\n```\n> /batch migrate src/ from Solid to React\nHow it works\n                        You plan the migration interactively, then /batch fans out the work to parallel agents — each in its own worktree, each testing and creating a PR independently.\n```\n\n**/loop** lets Claude run recurring tasks for up to 3 days unattended. **Code Review** dispatches a team of agents on every PR. **/btw** lets you ask questions mid-task without breaking Claude's flow.\n\nUse **/loop** to schedule recurring tasks for up to 3 days at a time. Claude runs your prompt on an interval, handling long-running workflows autonomously.\n\n```\n> /loop babysit all my PRs. Auto-fix build issues and when comments come in, use a worktree agent to fix them\n> /loop every morning use the Slack MCP to give me a summary of top posts I was tagged in\nWhat it does\n                        Schedules a prompt to run on a recurring interval. Use it for PR babysitting, Slack summaries, deploy monitoring, or any repeating workflow — running for up to 3 days unattended.\n```\n\nWhen a PR opens, Claude dispatches a **team of agents** to hunt for bugs. Anthropic built it for themselves first — code output per engineer is up **200% this year**, and reviews were the bottleneck.\n\nBoris personally used it for weeks before launch. It catches real bugs he wouldn't have noticed otherwise.\n\n```\n# A PR opens on your repo\n# Claude Code automatically:\n#   1. Reads the diff\n#   2. Dispatches specialized review agents\n#   3. Posts inline comments on real bugs\nWhat it does\n                        Automatically reviews every PR with a team of agents. Each agent focuses on a different concern — logic errors, security issues, performance regressions — then posts inline comments directly on the PR.\n```\n\nA slash command for **side-chain conversations** while Claude is actively working. Single-turn, no tool calls, but has full context of the conversation. Built by **@ErikSchluntz** as a side project — 1.5M views on the launch tweet.\n\n```\n# Claude is mid-task, refactoring auth middleware...\n> /btw what does the retry logic do?\n# Claude responds inline without stopping its work:\nThe retry logic in auth.ts uses exponential backoff\nwith a max of 3 attempts. It catches 401/403 errors\nand refreshes the token before retrying.\nWhat it does\n                        Lets you ask a quick question mid-task without interrupting Claude's flow. The response is single-turn with no tool calls, but Claude has full context of what it's working on — so answers are grounded in the current conversation.\n```\n\nThe Claude Code team dropped 8 features in one thread: **/effort max** for deeper reasoning, **voice mode** for everyone, **remote control sessions**, **setup scripts**, **session naming**, **/color**, and a new **PostCompact hook**.\n\nSet effort to **'max'** and Claude reasons for longer, using as many tokens as needed. Burns through your usage limits faster, so you activate it **per session**.\n\n```\n> /effort max\n# Four levels available:\n#   low    - quick answers, minimal reasoning\n#   medium - balanced (default)\n#   high   - deeper reasoning\n#   max    - reasons as long as needed\nWhat it does\n                        Sets the reasoning effort level for the current session. At 'max', Claude thinks longer and uses more tokens per response — useful for hard debugging, architecture decisions, or tricky code where you want Claude to really think it through.\n```\n\nRun `claude remote-control`\n\nand then spawn a **new local session** directly from the mobile app. Available on Max, Team, and Enterprise (v2.1.74+).\n\n``` bash\n$ claude remote-control\n# Then open the Claude mobile app\n# Tap \"Code\" → start a new session\n# Claude connects to your local machine\nWhat it does\n                        Lets you start fresh Claude Code sessions from your phone while connected to your local dev environment. Walk away from your desk, think of something, and kick off a task from mobile — Claude runs on your machine.\n```\n\nVoice mode is now rolled out to **100% of users**, including in Claude Code Desktop and Cowork. Sometimes you need somebody to talk to.\n\n```\n# In Claude Code Desktop or Cowork:\n# Click the microphone icon\n# Talk naturally — Claude hears you and responds\n🎙 \"Hey Claude, fix all the bugs in this repo.\"\nWhat it does\n                        Lets you speak to Claude Code instead of typing. Available in Desktop and Cowork — useful for hands-free coding, dictating complex requirements, or when you think faster than you type.\n```\n\nAdd a **setup script** in Claude Code on the web and desktop. It runs before Claude Code launches on a cloud environment — install dependencies, configure settings, set env vars.\n\n```\n# In \"Update cloud environment\" settings:\n# Name:\napps\n# Setup script (runs on new session start):\n#!/bin/bash\nyarn install\nWhat it does\n                        Runs a bash script automatically when a new Claude Code session starts on a cloud environment. Skipped when resuming an existing session. Use it to install dependencies, set up configs, or prepare the environment before Claude starts working.\n```\n\nName your session at launch with the `--name`\n\nflag. Makes it easy to identify sessions when running multiple in parallel.\n\n``` bash\n$ claude --name \"auth-refactor\"\n# Now your session shows up as \"auth-refactor\"\n# instead of a generic session ID\nWhat it does\n                        Gives your Claude Code session a human-readable name on start. Especially useful when juggling multiple worktrees or sessions — you can tell at a glance which session is doing what.\n```\n\nAfter plan mode, Claude will **automatically name your session** based on what you're working on. No manual naming needed.\n\n```\n# Enter plan mode, describe your task:\n> shift+tab\n[plan]> Refactor the auth middleware to use JWT\n# After exiting plan mode, session is auto-named:\n# Session: \"refactor-auth-jwt\"\nWhat it does\n                        Claude infers a descriptive session name from your plan mode conversation. Pairs well with claude --name — use --name when you know what you're doing upfront, and let auto-naming handle it when you start by planning.\n```\n\nChange the color of the prompt input with `/color`\n\n. Useful for visually distinguishing sessions when running multiple in parallel.\n\n```\n> /color\n# Pick a color for this session's prompt\n# Helps tell sessions apart at a glance\nWhat it does\n                        Sets the color of your prompt input for the current session. When you have 3-5 sessions open in different terminals, color-coding them makes it instantly clear which is which.\n```\n\nA new hook event: **PostCompact**. Fires after Claude compresses its conversation context, letting you inject instructions or run commands when compaction happens.\n\n```\n# In your hooks config:\n\"hooks\": {\n  \"PostCompact\": [{\n    \"matcher\": \"\",\n    \"hooks\": [{\n      \"type\": \"command\",\n      \"command\": \"echo 'Context was compacted'\"\n    }]\n  }]\n}\nWhat it does\n                        Fires after Claude compresses its context window. Use it to re-inject critical instructions that might get lost during compaction, log when compaction happens, or trigger any automation you need when the context resets.\n```\n\nAuto mode kills permission prompts with built-in safety classifiers, **/schedule** creates cloud-based recurring jobs that run beyond your laptop, **iMessage** becomes a channel, and **auto-dream** keeps your memory clean.\n\nInstead of approving every file write and bash command, or skipping permissions entirely with `--dangerously-skip-permissions`\n\n, **auto mode** lets Claude make permission decisions on your behalf.\n\n``` bash\n# Enable auto mode\n$ claude --enable-auto-mode\n\n# Or cycle with shift+tab during a session:\n# plan mode → auto mode → normal mode\nHow it works\n                        Anthropic built and tested classifiers that evaluate each action before it runs. Safe operations (reading files, running tests) get auto-approved. Risky ones (deleting files, force-pushing, running unknown scripts) still get flagged. It's the middle ground between clicking \"approve\" 50 times per session and yolo-ing with no safety net.\n```\n\nBoris's take: *\"no 👏 more 👏 permission prompts 👏\"*\n\nUse `/schedule`\n\nto create **recurring cloud-based jobs** for Claude, directly from the terminal. Unlike `/loop`\n\n(which runs locally for up to 3 days), scheduled jobs run in the cloud — they work even when your laptop is closed.\n\n```\n# Schedule a daily docs update\n$ /schedule a daily job that looks at all PRs shipped\n  since yesterday and update our docs based on the\n  changes. Use the Slack MCP to message #docs-update\n  with the changes\nUse cases\n                        The Anthropic team uses these internally to automatically resolve CI failures, push doc updates, and power automations that need to exist beyond a closed laptop. Think of it as cron jobs, but Claude does the work.\n```\n\niMessage is now available as a **Claude Code channel**. Install the plugin and text Claude like you'd text a friend — from any Apple device.\n\n```\n# Install the iMessage plugin\n$ /plugin install imessage@claude-plugins-official\nWhat it does\n                        Claude Code becomes a contact in your Messages app. Send it tasks, get responses as iMessages. Works from your iPhone, iPad, or Mac — no terminal needed. Pairs well with remote control sessions for kicking off work from anywhere.\n```\n\nClaude Code now has a built-in memory system. Run `/memory`\n\nto configure it.\n\n```\n# View and configure memory settings\n$ /memory\n\n# Memory types:\n#   User memory    → saved in ~/.claude/CLAUDE.md\n#   Project memory → saved in ./CLAUDE.md\n# Trigger a dream (memory consolidation)\n$ /dream\nAuto-memory\n                        When enabled, Claude automatically saves preferences, corrections, and patterns between sessions. No manual CLAUDE.md editing needed — Claude writes the memories for you.\nAuto-dream\n                        As memory accumulates, it can get messy — outdated assumptions, overlapping notes, low-signal entries. Auto-dream runs a subagent that periodically reviews past sessions, keeps what matters, removes what doesn't, and merges insights into cleaner structured memory. The naming maps to how REM sleep consolidates short-term memory into long-term storage.\n```\n\nBoris's favorite hidden and under-utilized features in Claude Code. **Mobile app**, session teleporting, **/loop** and **/schedule**, hooks, Cowork Dispatch, Chrome extension, Desktop app, **/branch**, **/btw**, worktrees, **/batch**, **--bare**, **--add-dir**, **--agent**, and **/voice**.\n\nDid you know Claude Code has a mobile app? Boris writes a lot of his code from the iOS app. It's a convenient way to make changes without opening a laptop.\n\n```\nHow to use it\n                        Download the Claude app for iOS/Android, then tap the Code tab on the left. You get a full Claude Code session right from your phone.\n```\n\nMove sessions back and forth between mobile/web/desktop and terminal.\n\n``` bash\n# Continue a cloud session on your machine\n$ claude --teleport\n# or\n$ /teleport\n\n# Control a local session from phone/web\n$ /remote-control\nBoris's setup\n                        \"I have 'Enable Remote Control for all sessions' set in my /config.\"\n```\n\nTwo of the most powerful features in Claude Code. Use these to schedule Claude to run automatically at a set interval, for up to a week at a time.\n\n```\n# Boris's running loops:\n$ /loop 5m /babysit\n# auto-address code review, auto-rebase, shepherd PRs\n\n$ /loop 30m /slack-feedback\n# auto put up PRs for Slack feedback every 30 mins\n\n$ /loop /post-merge-sweeper\n# put up PRs to address missed code review comments\n\n$ /loop 1h /pr-pruner\n# close out stale and unnecessary PRs\nPro tip\n                        Experiment with turning workflows into skills + loops. It's powerful.\n```\n\nUse hooks to deterministically run logic as part of the agent lifecycle.\n\n```\nExamples\n\nDynamically load in context each time you start Claude (SessionStart)\nLog every bash command the model runs (PreToolUse)\nRoute permission prompts to WhatsApp for you to approve/deny (PermissionRequest)\nPoke Claude to keep going whenever it stops (Stop)\n```\n\nSee [code.claude.com/docs/en/hooks](https://code.claude.com/docs/en/hooks)\n\nBoris uses Dispatch every day to catch up on Slack and emails, manage files, and do things on his laptop when he's not at a computer.\n\n*\"When I'm not coding, I'm dispatching.\"*\n\n```\nWhat it is\n                        Dispatch is a secure remote control for the Claude Desktop app. It can use your MCPs, browser, and computer, with your permission.\n```\n\nThe most important tip for using Claude Code is: **give Claude a way to verify its output**. Once you do that, Claude will iterate until the result is great.\n\nThink of it like any other engineer: if you ask someone to build a website but they aren't allowed to use a browser, will the result look good? Probably not. But if you give them a browser, they will write code and iterate until it looks good.\n\n```\nBoris's workflow\n                        \"I use the Chrome extension every time I work on web code. It tends to work more reliably than other similar MCPs.\"\n```\n\nDownload the extension for [Chrome/Edge](https://code.claude.com/docs/en/browser).\n\n```\nBetter than Playwright or Chromium MCP for E2E\n                        Asked directly whether Claude in Chrome beats Playwright or a Chromium MCP for end-to-end tests, Boris: \"Yes. It's more powerful and more token-efficient.\" The way he wires it into a long autonomous run is to hand verification to a workflow:\n                        \n> use a workflow to test the result e2e in a browser using\n  claude in chrome mcp. Especially look for edge cases and ui issues\n\nFrom Boris's June 2026 \"running Opus autonomously\" thread →\n```\n\nUse the Claude Desktop app to have Claude automatically start and test web servers.\n\n```\nWhat it does\n                        The Desktop app bundles in the ability for Claude to automatically run your web server and even test it in a built-in browser. You can set up something similar in CLI or VSCode using the Chrome extension, or just use the Desktop app.\n```\n\nPeople often ask how to fork an existing session. Two ways:\n\n``` bash\n# Option 1: From inside your session\n$ /branch\n\n# Option 2: From the CLI\n$ claude --resume <session-id> --fork-session\nWhat happens\n                        Claude creates a branched conversation. You're now in the branch. To resume the original, use the session ID it gives you.\n```\n\nBoris uses this all the time to answer quick questions while the agent works.\n\n```\n> /btw how do i spell daushund?\n\n  dachshund — German for \"badger dog\"\n  (dachs = badger, hund = dog).\nHow it works\n                        Single-turn, no tool calls, but has full context of the conversation. Claude responds inline without stopping its work.\n```\n\nClaude Code ships with deep support for git worktrees. Worktrees are essential for doing lots of parallel work in the same repository. Boris has dozens of Claudes running at all times.\n\n``` bash\n# Start a new session in a worktree\n$ claude -w\n\n# Or check the \"worktree\" checkbox in Desktop app\nNon-git VCS\n                        For non-git VCS users, use the WorktreeCreate hook to add your own logic for worktree creation.\n```\n\n`/batch`\n\ninterviews you, then has Claude fan out the work to as many worktree agents as it takes (dozens, hundreds, even thousands) to get it done.\n\n```\nUse cases\n                        Use it for large code migrations and other kinds of parallelizable work. Each agent runs in its own worktree with full isolation.\n```\n\nBy default, when you run `claude -p`\n\n(or the TypeScript or Python SDKs) it searches for local CLAUDE.md's, settings, and MCPs. But for non-interactive usage, most of the time you want to explicitly specify what to load.\n\n``` bash\n$ claude -p \"summarize this codebase\" \\\n    --output-format=stream-json \\\n    --verbose \\\n    --bare\nWhy it matters\n                        This was a design oversight when the SDK was first built. In a future version, the default will flip to --bare. For now, opt in with the flag to get up to 10x faster startup.\n```\n\nWhen working across multiple repositories, Boris usually starts Claude in one repo and uses `--add-dir`\n\n(or `/add-dir`\n\n) to let Claude see the other repo. This tells Claude about the repo *and* gives it permissions to work in it.\n\n``` bash\n# At launch\n$ claude --add-dir /path/to/other-repo\n\n# During a session\n> /add-dir /path/to/other-repo\nTeam setup\n                        Add \"additionalDirectories\" to your team's settings.json to always load in additional folders when starting Claude Code.\n```\n\nCustom agents are a powerful primitive that often gets overlooked.\n\n``` bash\n# Define an agent\n$ cat .claude/agents/ReadOnly.md\n---\nname: ReadOnly\ndescription: Read-only agent restricted to the Read tool only\ncolor: blue\ntools: Read\n---\n\nYou are a read-only agent that cannot edit files or run bash.\n\n# Launch it\n$ claude --agent=ReadOnly\nHow it works\n                        Define a new agent in .claude/agents, then run claude --agent=<your agent's name>. Each agent can have a custom name, color, tool set, and system prompt.\n```\n\nFun fact: Boris does most of his coding by speaking to Claude, rather than typing.\n\n```\nHow to use it\n\nCLI: Run /voice then hold the space bar\nDesktop: Press the voice button\niOS: Enable dictation in your iOS settings\n```\n\nFresh out of Anthropic this week. **Routines** — schedule Claude Code runs or trigger them from GitHub events. Three session management tips from Thariq on the 1M context window: **/rewind** over correcting, **/compact** vs **/clear**, and a one-line env var to dodge context rot. Plus three from Cat on using **Opus 4.7**: delegate, full-context briefs, and the new **xhigh** effort level.\n\nClaude announced **Routines** in Claude Code — research preview, Apr 14 2026. Configure a routine once (prompt, repo, connectors), and it runs on a schedule, from an API call, or in response to a GitHub event. Runs on Anthropic infra — no laptop needed.\n\n```\nTriggers\n\nSchedule — cron expression\nGitHub event — PR opened/merged, release published, issue opened\nAPI — POST to a webhook URL with token\nConnectors\n                        GitHub, Linear — extend with your own. Each routine has its own API endpoint, so you can point alerts, deploy hooks, or internal tools at Claude directly.\n```\n\nExample use case: POST an alert payload to the routine's webhook. Claude finds the owning service and posts a triage summary to #oncall.\n\nFrom Thariq (Apr 15, 2026): the single habit that signals good context management is **rewind**, not correction.\n\nWhen Claude goes down a wrong path, don't type \"that didn't work, try X instead.\" That keeps the failed attempt in your context and pollutes the window. Instead, rewind and re-prompt with what you learned.\n\n```\n# jump back to a previous message, drop everything after it\n$ /rewind\n# or in the terminal: double-tap Esc\nThe math\n                        Correcting: context = file reads + failed attempt + correction + fix.\n                        Rewinding: context = file reads + one informed prompt + fix.\n```\n\nYou can also use `\"summarize from here\"`\n\nto have Claude summarize its learnings into a handoff message before rewinding — a message from the next iteration of Claude to its past self.\n\nTwo ways to shed weight from a long session. They feel similar but behave very differently.\n\n```\n/compact — lossy LLM summary\n                        Claude summarizes the conversation and replaces the history with that summary. Cheap, keeps momentum, details can be fuzzy. You're trusting Claude to decide what mattered.\n# steer the compaction with a hint\n$ /compact focus on the auth refactor, drop the test debugging\n/clear — hand-written brief\n                        You write down what matters (\"we're refactoring the auth middleware, constraint is X, files are A and B, we've ruled out approach Y\") and start clean. More work, but the context is exactly what you decided.\n```\n\n**Rule of thumb:** starting a genuinely new task → new session with `/clear`\n\n. Related task where you still need some context → `/compact`\n\nwith a hint.\n\nContext rot — model performance degrading as context grows — kicks in around **300-400k tokens** on the 1M context model. You can set your autocompact threshold to force earlier compaction and effectively lower your context window.\n\n``` bash\n# 400k is Thariq's recommended compromise\n$ CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude\nWhy this works\n                        Stays below the rot zone while still getting most of the 1M benefit. Context windows are a hard cutoff — when you near the end, you're forced to compact. Forcing it earlier means your compaction happens while the model is still sharp.\n```\n\nPair with proactive `/compact <hint>`\n\nwhen you feel bad-compact risk (autocompact fires mid-task and summarizes the wrong things).\n\nDocs: [Claude Code settings](https://docs.claude.com/en/docs/claude-code/settings)\n\nFrom Cat Wu (Apr 16, 2026) on Opus 4.7 in Claude Code: *\"The model performs best if you treat it like an engineer you're delegating to, not a pair programmer you're guiding line by line.\"*\n\nThis is a mental model shift. The old workflow: describe a step, watch the output, correct, describe the next step. High interrupt frequency, you're always in the loop.\n\n```\nThe new workflow\n                        Write a crisp brief. Launch Claude. Come back when it's done — or when it asks a real question. Fewer interruptions, more autonomous runs, higher quality output.\n```\n\nWhen Claude asks too many clarifying questions or goes off-track, that's usually a signal that your brief was incomplete — not that the model needs more hand-holding. Invest in the upfront brief (see next tip) and let Opus 4.7 do its thing.\n\nThe delegation model from Tip 5 only works if Claude has what it needs. Cat's second tip: *\"Give Claude Code your full task context upfront: goal, constraints, acceptance criteria in the first turn.\"*\n\n```\nThe three things to include\n\nGoal — what success looks like in plain language\nConstraints — non-goals, things not to touch, perf/API contracts\nAcceptance criteria — how you'll verify the work is done right\n# Good: full context upfront\nGoal: add rate limiting to the /api/login endpoint\n\nConstraints:\n- don't modify the DB schema\n- keep the existing auth flow unchanged\n- use Redis (already configured)\n\nAcceptance criteria:\n- 5 req/min per IP, returns 429 on limit\n- existing tests still pass\n- new test case for the rate-limit behavior\n```\n\nIf Claude starts with all three, it plans around the full problem space. If it starts with just \"add rate limiting,\" it'll make assumptions you'll have to correct later — and every correction costs context.\n\nOpus 4.7 in Claude Code defaults to `xhigh`\n\n— a new effort level beyond the low/medium/high/max scale Tip 34 described. The model reasons longer before acting, which pairs with the delegation shift: think harder once, rather than iterate fast and bounce back to you.\n\n```\n# check or change the effort level\n$ /effort\nWhy xhigh is the new default\n                        xhigh effort + a full-context brief = one-shot completion of bigger tasks than previous Opus models could handle. The default change signals that Opus 4.7 is expected to run more autonomously, which benefits from more reasoning tokens upfront.\n```\n\nDrop it down if you want speed over depth, or leave it alone for most work. Available through `/effort`\n\njust like the other levels.\n\nBoris dogfooded Opus 4.7 for weeks before launch. His verdict: *\"It feels more intelligent, agentic, and precise than 4.6. It took a few days for me to learn how to work with it effectively.\"* Here's what he learned — plus key behavioral shifts from the Anthropic blog. **Auto mode**, **/fewer-permission-prompts**, **recaps**, **/focus**, effort mastery, the **/go** composite skill, and what changed under the hood.\n\nOpus 4.7 loves complex, long-running tasks — deep research, refactoring code, building complex features, iterating until it hits a performance benchmark. In the past, you either had to babysit the model or use `--dangerously-skip-permissions`\n\n.\n\n```\nAuto mode changes the game\n                        Permission prompts are routed to a model-based classifier. If it's safe, it's auto-approved. No more babysitting while the model runs. More than that — it means you can run more Claudes in parallel. Once a Claude is cooking, switch focus to the next one.\n```\n\nShift-tab to enter auto mode in the CLI, or choose it in the dropdown in Desktop or VSCode. Available for Max, Teams, and Enterprise.\n\nA new skill that scans through your session history to find common bash and MCP commands that are safe but caused repeated permission prompts.\n\n```\n# scan your history and get recommendations\n$ /fewer-permission-prompts\nWhat it does\n                        Recommends a list of commands to add to your permissions allowlist. Use it to tune up your permissions and avoid unnecessary prompts — especially useful if you don't use auto mode.\n```\n\nShipped alongside Opus 4.7. Recaps are short summaries of what an agent did and what's next. Useful when returning to a long-running session after a few minutes or a few hours.\n\n```\n✻ Cogitated for 6m 27s\n✻ recap: Fixing the post-submit transcript\n  shift bug. The styling-flash part is shipped\n  as PR #29869 (auto-merge on, posted to stamps).\n  Next: I need a screen recording of the remaining\n  horizontal rewrap on `cc -c` to target that\n  separate cause. (disable recaps in /config)\n```\n\nPairs naturally with auto mode — you launch Claude, switch focus, come back, and immediately see what happened and what's next without scrolling through tool output. Disable in `/config`\n\nif you prefer the old behavior.\n\nBoris: *\"I've been loving the new focus mode in the CLI, which hides all the intermediate work to just focus on the final result. The model has reached a point where I generally trust it to run the right commands and make the right edits. I just look at the final result.\"*\n\n```\n# toggle focus mode on/off\n$ /focus\nWhen to use it\n                        When you trust the model enough that watching every file read and bash command is noise. Focus mode shows you what changed, not how it got there. A natural complement to auto mode — one removes permission prompts, the other removes visual clutter.\n```\n\nOpus 4.7 uses **adaptive thinking** instead of fixed thinking budgets. The model decides when thinking is beneficial rather than using a fixed allocation — less overthinking, smarter resource use.\n\n```\nBoris's setup\n                        \"I use xhigh effort for most tasks, and max effort for the hardest tasks.\"\n# set effort level\n$ /effort\n\n# the scale: low → medium → high → xhigh → max\n# Speed ←————————————————————→ Intelligence\nKey detail most people miss\nMax applies to just your current session. All other effort levels (including xhigh) are sticky and persist for your next session too. This means you can safely crank to max for one hard debugging session without permanently changing your default.\n```\n\nTo steer thinking without changing effort: say *\"Think carefully and step-by-step before responding\"* for harder problems, or *\"Prioritize responding quickly rather than thinking deeply\"* to save tokens on simple tasks.\n\n*\"Give Claude a way to verify its work. This has always been a way to 2-3x what you get out of Claude, and with 4.7 it's more important than ever.\"*\n\nBoris's workflow these days: *\"Many of my prompts look like 'Claude do blah blah /go'.\"*\n\n```\n/go is a skill that has Claude:\n\nTest itself end to end using bash, browser, or computer use\nRun the /simplify skill\nPut up a PR\n```\n\nVerification by domain: backend → make sure Claude knows how to start your server/service to test end to end. Frontend → use the Claude Chromium extension. Mobile → use the iOS/Android simulator MCP. Desktop apps → use computer use.\n\n```\nScripted or Claude-driven tests?\n                        Asked whether tests should be scripted (guaranteed but flaky) or Claude-driven, Boris: \"We do both! Depends if it's a one-off or something you want to run on future PRs.\" One-off check → let Claude drive it. Something you want to re-run on every PR → have it write a real test.\n```\n\n*\"For long running work, verification is important because that way when you come back to a task, you know the code works.\"*\n\nIf you're upgrading from 4.6, three behavioral changes matter. Don't assume your old habits carry over — Opus 4.7 thinks differently.\n\n```\n1. Calibrated response length\n                        Shorter answers for simple queries, longer for open-ended analysis. If you want a specific length or style, say so explicitly in your prompt.\n2. Less automatic tool usage\n                        4.7 reasons more instead of immediately calling tools. If Claude isn't reaching for the right tools, provide explicit guidance describing when and why to use them.\n3. More judicious subagent spawning\n                        4.7 is more selective about delegation. For tasks like \"refactor across 40 files,\" explicitly request parallel subagents. Anti-pattern: don't ask it to spawn subagents for refactoring a single visible function.\n```\n\nSource: [Anthropic blog post](https://claude.com/blog/best-practices-for-using-claude-opus-4-7-with-claude-code)\n\nWith auto mode + focus mode, you're spending less time watching Claude work. But you need to know when it finishes. Set up notifications so you don't have to keep checking back.\n\n```\nOptions\n\nSound alert — ask Claude to play a sound when it finishes a task\nStop hook — use a Stop hook to trigger a notification (Slack, system notification, etc.)\niTerm2 notifications — enable native terminal notifications\nRecaps — when you do check back, recaps tell you what happened (tip 3)\n```\n\nThe workflow that pulls this all together: start Claude in auto mode with focus on. It runs autonomously, verifies its own work via `/go`\n\n, and notifies you when done. You review the recap and the PR. The future Boris described in Part 1 is here.\n\nSource: [Anthropic blog post](https://claude.com/blog/best-practices-for-using-claude-opus-4-7-with-claude-code)\n\nTwo Claude Code features surfaced this week. **Agent view** (launched May 11) is a native control plane for managing many concurrent sessions: run `claude agents`\n\nfrom a root code directory and see every session grouped by what needs your input, what's still working, and what's done. **/goal** (highlighted by ClaudeDevs on May 12, described as recently shipped) keeps a single session working until a completion condition is met: `/goal all tests in test/auth pass and the lint step is clean`\n\n, and Claude won't stop until it's true. Two halves of the same story. Run more agents, and make each one finish what it started.\n\nBoris: **\"The best way to level up from 1 agent => many agents. No more cycling between terminal tabs.\"** Thariq's description: **\"kind of like tmux built for CC\"** — a native control plane for concurrent Claude Code sessions.\n\n```\nHow to run it\n                        Cat Wu and Thariq both recommend running it from a single high-level directory containing all your repos (Thariq uses ~/Projects). Every session launched under that root gets tracked.\nbash\n# launch the control plane from your root code dir\n$ claude agents\n\n# from any cli session, hit <- to register it with the control plane\nWhat you see\n                        Sessions are grouped by status — needs input, working, completed. Each row shows the session name and a short description of what it's doing. Switch focus into one, answer its question, come back to the view.\nOperational tips from Dickson Tsai\n                        Two practical details: new sessions inherit the directory your cursor is on (so starting a session in the right repo is one keystroke), and renaming is critical for keeping the view scannable as sessions pile up. Use /rename or set up a UserPromptSubmit hook to auto-rename.\n```\n\nThis is the productized version of **Part 1, Tip 1** — Boris's original \"spin up 3-5 worktrees\" pattern, but with a first-class control plane instead of manual terminal tabs and `za`\n\n/`zb`\n\n/`zc`\n\naliases.\n\nResearch preview. The Claude Code team is actively reading feedback — Thariq: *\"let me know if you have any feedback! we will read all of it and action.\"*\n\nSurfaced in a May 12 ClaudeDevs thread, described as \"shipped recently\" — exact ship date isn't in the post and would need the changelog to confirm. `/goal`\n\nsets a completion condition. Claude keeps working until the condition is true; every time it tries to stop, the model checks the condition against the transcript. Not done, it keeps going. Done, you get a *\"Goal achieved\"* summary.\n\n```\n# set a completion condition\n$ /goal all tests in test/auth pass and the lint step is clean\nHow it works\n                        ClaudeDevs calls this the Ralph loop, built into Claude Code. Each stop attempt is intercepted; the model self-checks against your condition before exiting. The loop only breaks when the condition is satisfied.\nCompanion tools\n\n/loop runs Claude on repeat. Good for iterative refactors, cleanups, or burning down a backlog.\n/schedule kicks off Claude on a cadence. Nightly test runs, morning triage, weekly cleanup.\nA Stop hook gives programmatic control over when Claude can finish. Run your test suite, hit a CI endpoint, gate on anything.\nAuto mode lets Claude work uninterrupted without permission prompts. Enable with shift+tab in the CLI or via the mode selector on desktop.\n```\n\nThe pairing with Part 12 Tip 1 is the launch story: agent view lets you run many sessions at once; `/goal`\n\nmakes each session finish what it started. Boris's worktrees pattern (Part 1, Tip 1) plus auto mode (Tip 68) plus `/goal`\n\napproximates an autonomous fleet that doesn't need babysitting.\n\n```\nA non-test use of /goal: make Claude teach you\n                        Thariq (@trq212) shared a prompt from Suzanne at Anthropic that points /goal at your understanding instead of a test suite. Claude becomes a tutor: it keeps a running checklist of what you should grasp — the problem and why it existed, the solution and its design decisions, the broader impact — has you restate your understanding, fills the gaps (ask for eli5 / eli14 / \"explain like I'm an intern\"), then quizzes you with AskUserQuestion (shuffled answers, no peeking). The last line is the enforcement:\n                        \n$ /goal the session should not end until you've verified\n       that the human has demonstrated they understood\n       everything on your list.\n                        \n                        Same Ralph-loop mechanism — but the exit condition is comprehension, not a green build. A good companion to Part 2's \"Learning with Claude\" (Tip 10).\n```\n\nAnthropic shipped **Claude Opus 4.8** — Boris calls it *\"our strongest coding model yet\"*. SWE-Bench Pro jumps from 64.3 to 69.2, but the bigger shift is honesty: the model tells you when it's unsure and catches its own bugs instead of declaring victory early. Same price as 4.7. Alongside the model: a new **high-effort default** (with `xhigh`\n\nfor hard problems and raised Claude Code rate limits to cover the extra tokens) and **dynamic workflows** — a research preview that runs hundreds of parallel subagents in a single session for tasks too big for one pass. Cat Wu surfaced the activation trigger: *mention \"workflow\" in your prompt* and Claude builds the orchestration plan automatically.\n\nBoris's framing: **\"up on SWE-bench Pro (from 64.3 to 69.2) and noticeably more honest about its own work. It tells you when it's unsure and catches its own bugs instead of declaring victory early.\"** Same price as 4.7. Live on claude.ai, the Claude Platform, and all major cloud platforms.\n\n```\nBenchmark deltas vs 4.7\n\nAgentic coding (SWE-Bench Pro): 64.3% → 69.2%\nAgentic terminal coding (Terminal-Bench 2.1): 66.1% → 74.6%\nMultidisciplinary reasoning (Humanity's Last Exam, with tools): 54.7% → 57.9%\nAgentic computer use (OSWorld-Verified): 82.8% → 83.4%\nKnowledge work (GDPval-AA): 1753 → 1890\nAgentic financial analysis (Finance Agent v2): 51.5% → 53.9%\nThe honesty shift matters more than the benchmarks\n                        The behavioral change Boris calls out — catching its own bugs, flagging uncertainty — is exactly the failure mode that breaks long-running agents. A model that overclaims at step 4 wastes the next 40 steps. Pair this with /goal from Part 12 and dynamic workflows below: honesty is what makes async work actually finish.\nAlso shipped today\nFast mode for Opus 4.8 (research preview): same model at roughly 2.5x the speed, 3x cheaper than before. Toggle with /fast in Claude Code. A new effort control on claude.ai lets you choose how much thinking Claude puts into each response — the consumer surface catching up to what Claude Code users already had.\n```\n\nBoris: **\"4.8 defaults to high effort, which spends about the same tokens as 4.7's default on coding but performs better.\"** The default change isn't a tax — it's the same token budget, used smarter. For hard problems and long-running async work, switch to `xhigh`\n\n. To make that economical, Anthropic **raised Claude Code rate limits** to cover the extra tokens.\n\n```\n# default — same tokens as 4.7's default, better output\n$ /effort high\n\n# hard problems, async runs, dynamic workflows\n$ /effort xhigh\nCarry-over from Part 11\n                        Part 11 introduced xhigh as Opus 4.7's new top tier (Tip 5: Effort Mastery). With 4.8, the default moved up — what used to be a deliberate choice is now baseline. Mental model: assume more reasoning per turn, and reach for xhigh when you'd previously have reached for \"let it think longer.\"\nWhen the extra tokens pay off\n                        Boris ties xhigh directly to dynamic workflows (next tab) and long-running async runs. Short conversational tasks don't need it — the default is already higher than 4.7's. Save xhigh for jobs where you're not watching the screen.\n```\n\nResearch preview, shipped today. Boris: **\"for tasks too big for one pass. Make sure to default to auto mode so Claude isn't stopping for permissions.\"** Per the launch post, Claude runs **hundreds of parallel subagents in a single session and verifies its work before reporting back**.\n\n```\nHow to invoke it\n                        Cat Wu: \"Mention 'workflow' in a prompt and Claude will dynamically create an orchestration plan that it strictly follows, allowing you to confidently trust that every stage happens in the right order even across 100s of agents.\" Claude takes a request for a workflow as a signal to plan and execute as a dynamic workflow rather than a single run. No new command, no flag. Update (June 9, 2026): Boris refined the trigger to the phrase \"use a workflow\" — bare \"workflow\" had too many false positives (see Part 16).\nUnder the hood — the orchestrator pattern\n                        A dynamic workflow is an orchestrator shape, not peer-to-peer \"agent teams.\" A top-level claude kicks off N tasks (N can be in the 100s). Each task fans out: implementer writes, branches into two verifiers, both verifiers feed into a single fixer. Each task's loop runs until its verifiers pass; the orchestrator returns only once every branch completes.\n                        \nDiagram from Cat Wu's May 28 thread.\nA concrete example\n                        Cat: \"Recently, I used dynamic workflows to catalogue all of our 100s of A/B test flags and find the ones rolled out to 0% or 100% so that we can quickly deprecate the stale ones. Instead of waiting for Claude Code to investigate each sequentially, dynamic workflows allowed Claude to process all of them in parallel in <10 minutes.\" The sweet spot: large fan-out across independent items where each needs the same investigation loop.\nSave it for your biggest jobs\n                        Boris's explicit list plus the category Cat's example highlights:\n                        \nMigrations\nRefactors\nPerf optimization\nBatch bug fixes\nCatalogue-and-categorize sweeps (A/B flags, feature toggles, dependencies, dead code, stale endpoints)\n\n                        It's token-intensive. Don't burn it on a 20-line tweak — that's what default mode and the new high-effort baseline are already for.\nAuto mode is not optional\n                        With hundreds of parallel subagents, a single permission prompt freezes the run. Boris: \"default to auto mode so Claude isn't stopping for permissions.\" Shift+tab into auto mode in the CLI, or toggle it on the desktop app. The combo: auto mode + dynamic workflows + xhigh = Claude actually walking off and finishing.\nThe framing that matters\n                        Boris: \"Big migrations and refactors are some of a team's most important work, and the easiest to push off to a 'better time' since they'd tie up engineers for a quarter. With dynamic workflows, Claude can now land that kind of work in days or weeks.\" The pitch isn't speed for routine work — it's making the kind of work teams perpetually defer actually shippable.\n```\n\nThis connects the arc from Part 11 (auto mode, effort mastery) through Part 12 (agent view, `/goal`\n\n) into Part 13: the model is more honest about its progress (Tip 1), spends more reasoning by default (Tip 2), and now has a first-class execution mode for jobs that don't fit in one pass. The autonomous fleet from Part 12's intro — agent view + `/goal`\n\n+ worktrees — gets a fourth pillar.\n\nResearch preview. Expect the surface to change.\n\nPart 13 announced dynamic workflows at launch. A week later, **Thariq Shihipar** and **Sid Bidasaria** — the engineers who built the feature — published the practitioner's guide: how workflows actually work, the patterns Claude composes, and where they pay off (often on non-coding work). *\"Claude can now write its own harness on the fly, custom-built for the task at hand.\"* This is the how-to behind the launch note. Best practices are still developing, and workflows often use more tokens — so think about when to reach for one.\n\nThe default Claude Code harness plans *and* executes in one context window. For most coding tasks that's highly effective. It breaks down on the long-running, massively parallel, or adversarial tasks — and the longer Claude works in a single window, the more three specific failure modes creep in.\n\n```\nAgentic laziness\n                        Claude stops before finishing a complex, multi-part task and declares it done after partial progress — addressing 20 of the 50 items in a security review and calling it complete.\nSelf-preferential bias\n                        Claude tends to prefer its own results, especially when asked to verify or judge its work against a rubric. The grader and the author being the same context is the problem.\nGoal drift\n                        Gradual loss of fidelity to the original objective across many turns — worst after compaction. Each summarization step is lossy, and details like edge-case requirements or \"don't do X\" constraints quietly fall out.\nThe fix\n                        A workflow orchestrates separate Claudes, each with its own context window and a focused, isolated goal. Laziness loses to a deterministic loop that doesn't exit until every item is handled; bias loses to a different agent doing the judging; drift loses because each agent holds one small goal that never gets summarized away. This connects straight to Part 13's honesty story — a model that overclaims at step 4 wastes the next 40 steps.\n```\n\nA dynamic workflow is a **JavaScript file** with a few special functions that spawn and coordinate subagents. Standard `JSON`\n\n, `Math`\n\n, and `Array`\n\nare there too for processing data.\n\n``` js\n# spawn one subagent — schema forces validated JSON back\nconst bugs = await agent(\"audit auth.ts\", {\n  schema: BugList,        // JSON Schema → validated output\n  model: \"haiku\",         // opus · sonnet · haiku · omit = inherit\n  isolation: \"worktree\",  // own checkout, for parallel edits\n  agentType: \"reviewer\",  // custom / built-in subagent\n})\nCompose the block\n\nparallel([ fns ]) — fan out, run at once. A barrier: it waits for all of them, then you have every result together.\npipeline(items, ...stages) — each item streams through every stage independently. No barrier: item A can be in stage 3 while item B is still in stage 1.\n\n                        Claude decides which model each agent uses and whether it runs in its own worktree — picking the intelligence level and isolation the step actually needs.\nResumable by default\n                        Interrupt a workflow — quit the terminal, cancel mid-run — and resuming the session picks up where it left off. The deterministic harness remembers what already completed.\nDynamic vs static\n                        You may have built static workflows before with the Agent SDK or claude -p. Because a static workflow has to handle every edge case, it ends up generic: \"turn this into 5 web searches → fetch → verify → summarize → a generic report.\" With Opus 4.8, Claude is smart enough to write a custom harness tailor-made for your case: \"read our billing code → check each feature against the new provider's docs → devil's advocate the strongest case against migrating → a specific recommendation.\"\n```\n\nBuilding a mental model for these helps you nudge Claude via prompts. They're not exclusive — Claude mixes and nests them.\n\n```\n1 · Classify-and-act\n                        A classifier agent decides the type of task, then routes to different agents or behavior. Or classify at the end to shape the output.\n2 · Fan-out-and-synthesize\n                        Split into many smaller steps, run an agent on each, then synthesize. The synthesize step is a barrier — it waits for all the fan-out agents, then merges their structured outputs into one result. Best when each step benefits from its own clean context so they don't cross-contaminate.\n3 · Adversarial verification\n                        For each spawned agent, run a separate agent to adversarially verify its output against a rubric. The verifier is never the author — that's what kills self-preferential bias.\n4 · Generate-and-filter\n                        Generate many ideas on a topic, then filter by a rubric or by verification, dedupe, and return only the highest-quality, tested few.\n5 · Tournament\n                        Instead of dividing work, have agents compete. Spawn N agents that each attempt the same task a different way, then judge them pairwise until you have a winner. Comparative judgment is more reliable than absolute scoring.\n6 · Loop-until-done\n                        For an unknown amount of work, keep spawning agents until a stop condition is met — no new findings, no more errors in the logs — instead of a fixed number of passes. Simple counters miss the tail.\n```\n\nThariq: **\"I've found that workflows are sometimes even more useful for non-technical work.\"** A sampling from the article:\n\n```\nMigrations & refactors\nBun was rewritten from Zig to Rust using workflows. Break the task into units — callsites, failing tests, modules — spin off a subagent for each fix in its own worktree, have another agent adversarially review, then merge. Tell agents to avoid resource-intensive commands so you can maximally parallelize without melting your machine.\nDeep research & deep verification\n                        The /deep-research skill is itself a workflow: fan out web searches, fetch sources, adversarially verify their claims, synthesize a cited report. The inverse is deep verification — one agent extracts every factual claim from a report, a subagent checks each in detail, and an optional source-auditor agent confirms the source is high quality. \"Verify every technical claim in my blog draft against the codebase — I don't want to ship anything wrong.\"\nSorting 1,000+ items\n                        You can't sort 1,000 rows by a qualitative measure in one prompt — quality degrades and it won't fit in context. Run a tournament, a pipeline of pairwise-comparison agents (comparative judgment beats absolute scoring), or bucket-rank in parallel then merge. Each comparison is its own agent; the deterministic loop holds the bracket so only the running order stays in context.\nMemory & rule adherence\n                        For rules Claude keeps missing even in CLAUDE.md: one verifier agent per rule, plus a skeptic persona that reviews the rules to avoid false positives. The reverse direction works too — mine your recent sessions and code-review comments for corrections you keep making, cluster them, adversarially verify each candidate (\"would this rule have prevented a real mistake?\"), and distill the survivors back into CLAUDE.md.\nRoot-cause investigation\n                        Debugging works best with several independent hypotheses tested in parallel — but one context window invites self-preferential bias. A workflow spins up agents that generate hypotheses from disjoint evidence (logs, files, data), then each hypothesis faces a panel of verifiers and refuters. Works for sales (\"why did sales drop in March?\"), data engineering, any post-mortem.\nTriage, taste, evals, routing\n\nTriage at scale: classify each backlog item, dedupe against what's already tracked, then fix or escalate. Use a quarantine pattern — agents reading untrusted public content can't take high-privilege actions. Pair with /loop to run continuously.\nExploration & taste: for design or naming, give a review agent a rubric; the task is done when the rubric is met. Order options via tournament.\nEvals: spin agents in worktrees, then comparison agents grade outputs against a rubric — handy for refining a skill you're building.\nModel routing: a classifier researches the task, then routes to Sonnet or Opus based on expected complexity.\n```\n\nWorkflows compose with the rest of Claude Code. Three levers worth knowing, plus the honest \"when not to.\"\n\n```\n/goal + /loop\n                        For repeatable workflows — triage, research, verification — pair with /loop to run at regular intervals and /goal to set a hard completion requirement. This is the Part 12 + Part 13 arc closing: /goal sets the exit condition, the workflow does the parallel work, /loop keeps it going.\nToken budgets\n                        Workflows are token-hungry, so cap them. Prompt a budget directly — \"use 10k tokens\" — and the workflow holds the ceiling.\n                        \n$ Use a workflow to rank these 80 resumes for the backend\n  role and double-check the top ten. use 50k tokens\nSee what's burning tokens: /usage\n                        When a long autonomous run eats your limits faster than expected, run /usage for a breakdown of the specific skills, MCPs, and plugins spending your tokens. Boris points people here first when they hit limits mid-run — it's how you find the workflow or MCP that's quietly dominating the bill.\nQuick workflows\n                        They aren't only for big jobs. Prompt a \"quick workflow\" for something small — a fast adversarial review of a single assumption, for instance.\nWhen not to use one\n                        Workflows can use significantly more tokens and aren't needed for every task. Thariq: \"For regular coding tasks, ask yourself: does it really need more compute? Most traditional coding tasks do not need a panel of 5 reviewers.\" Use them to push Claude in ways you couldn't before — not as the default for a 20-line change.\n```\n\nA good workflow is reusable. Once Claude builds one you like, keep it.\n\n```\nSave it\n                        Press \"s\" in the workflow menu to save. Check the files into ~/.claude/workflows, or distribute them via a skill.\n                        \nDynamic workflows\n1 running · 2 completed\n\n⟩ ✓ review-changes · 14 agents · 482k tok · 6m 12s\n  ◴ find-flaky-tests · 6 agents · 121k tok · 1m 48s\n  ✓ deep-research · 22 agents · 1.1M tok · 11m 3s\n\n↑/↓ select · enter view · s save · esc close\nShare via a skill\n                        Put your JavaScript workflow files in the skill folder and reference them in the SKILL.md. For flexibility, prompt Claude to treat the workflows in a skill as a template, not a script to run verbatim — so it adapts the harness to the specific case instead of replaying it blindly.\nThe \"ultracode\" trigger\n                        You can start a workflow just by asking for one — or use the trigger word \"ultracode\" to guarantee Claude Code builds a workflow rather than running a single pass.\n```\n\nThis is the fourth pillar settling into place: Part 11's auto mode, Part 12's agent view + `/goal`\n\n, Part 13's Opus 4.8 + the workflow launch, and now the patterns to drive them. Thariq's closing line is the honest one — *\"there's still much to discover in how to use them best.\"*\n\nResearch preview. Best practices are still developing.\n\nOne year after Claude Code went GA, **Boris Cherny** (Head of Claude Code) and **Cat Wu** (Head of Product) sat down to talk about what changed — *\"from a Slack demo that got two reactions to engineering teams deploying it across entire codebases.\"* Four ideas stood out, and a couple quietly overturned earlier advice on this very site: why Boris dropped plan mode, the shift to context minimalism, the one habit that lets Claude run for hours, and why auto mode is safer than reading every prompt.\n\nFor over a year, plan mode was Boris's go-to for synchronous coding. A year after GA, he's moved on — and the reason is the model, not the feature.\n\n```\nIn his words\n\"What it used to be is plan mode. I don't use that anymore. I use auto mode — instead of plan mode. The newer models don't actually need a planning step. It was really important for Opus 4 through 4.5, but starting with 4.6, and definitely with 4.7, it just doesn't need it.\"\nWhy it changed\n                        Older models needed an explicit plan to stay on track. 4.6+ plan implicitly, so the planning step became overhead — an artifact to review before any work starts.\njs\nWhat he does instead\n                        Start Claude in auto mode, let it work, move to the next Claude. No babysitting. Some people keep plan mode for the written artifact, and that's fine — Boris just runs auto mode for everything.\nUpdates Part 1\n                        This revises the plan-mode tip from Part 1. The rule of thumb shifted with the model: pre-4.6, plan first; 4.6 and later, let it run. Pairs with the auto mode tips in Parts 8 and 11.\n```\n\n\"From context engineering to context minimalism\" is its own chapter in the interview. The era you're in tracks the model you're using.\n\n```\nThe progression\n                        Sonnet 3.5 was the era of prompt engineering. Opus 4 was the era of context engineering. Today's models need neither.\nBoris\n\"You give it the minimal possible system prompt, the minimal possible tools, and then you let the model figure it out. You just have to give the model some way to pull in the context.\"\nCat\n\"I'm a context minimalist. Tell the model only what it needs to know and let it figure out the rest. When you give the model too much context, it's like you're micromanaging it — and sometimes the model knows a better way to get to the same outcome.\"\nThe move\n                        Stop front-loading giant prompts and tool lists. Give a lean brief plus a way to fetch context — files, search, MCP — then get out of the way. Minimal ≠ vague: give the goal, not the micro-steps. Pairs with Part 10's \"delegation over guidance.\"\n```\n\nBoris calls this the single most important idea for long-running work — and it's the whole reason his agents can run for hours.\n\n```\nIn his words\n\"Every single time Claude makes a mistake, I don't tell it to do it differently. I tell it to write it to the CLAUDE.md, or make a skill, or something. If you can do this, then Claude can just run forever.\"\nThe distinction\n                        Correcting Claude in chat fixes this one run. Writing the fix into CLAUDE.md or a skill fixes every future run. A conversational correction is a patch; a written rule is a fix.\nWhy it compounds\n                        The error rate trends down over time instead of resetting each session. The rule set grows; the mistakes don't come back. When something goes wrong, your next instruction isn't \"do it this way\" — it's \"add a rule so this doesn't happen again.\"\n```\n\nPairs with Part 1's CLAUDE.md and Skills tips, and Part 10's `/rewind`\n\nover correcting.\n\nAuto mode routes each action to a classifier instead of asking you to approve every prompt. The interview explains *why you can trust it* — and why it's arguably safer than reading every prompt yourself.\n\n```\nHow it was hardened\n                        The team collected thousands of full agent transcripts plus the permission prompt, had auto mode classify each as safe or unsafe, then brought in red-teamers to prompt-inject and attack the codebase. Those attacks became evals; auto mode was tuned until it caught them all.\nThe counterintuitive part\n\"When you accept 99% of requests, your eyes glaze over. Auto mode is more safe than reading every single permission prompt because it means you're only paying attention to the most important thing.\"\njs\nThe payoff\n                        Because he trusts it, he can let one agent run and start a second. Trust is what makes parallel, autonomous work possible — it protects against today's known vulnerabilities and the most intelligent attacks the team can construct. Pairs with the auto mode tips in Parts 8 and 11.\n```\n\nA June 9 ship: **nested subagent support** — *\"agents kicking off agents as a way to better manage context,\"* capped at depth=5 to start. Plus an experimental `fork: true`\n\nskill frontmatter, and a correction to how you trigger a dynamic workflow (it's *\"use a workflow\"* now, not bare *\"workflow\"*). Three quick ones, straight from Boris's thread.\n\nBoris: *\"Just landed nested subagent support in Claude Code. Starting to experiment more with agents kicking off agents as a way to better manage context. Capped at depth=5 to start.\"*\n\n```\nWhat it is\n                        A subagent can now spawn its own subagents, down to depth=5 (a starting cap). Nesting is a context-management tool — each layer keeps its own context window, so deep work doesn't bloat the parent.\nMonitor them\n                        To watch what each subagent is doing, hit arrow-down in the terminal. (Asked how to see them, Boris: \"In terminal? Hit arrow down.\")\nModel propagates, thinking weights don't (yet)\n                        Dispatched subagents can run on a chosen model; per a user's testing that Boris confirmed, the model carries through but thinking weights do not propagate yet. Nesting also works with forked sessions and subagents can use Chrome.\n```\n\nWhere a dynamic workflow (Parts 13–14) is an orchestrated harness, nested subagents are the lower-level primitive — any agent can delegate to keep its own context clean. Pairs with Part 1's subagents + worktrees and Part 12's agent view.\n\nAn idea Boris shared in the same thread, framed explicitly as *\"one idea I'm experimenting with\"* — so treat it as a preview, not a stable API.\n\n```\nThe mechanic\n                        Add fork: true to a skill's frontmatter so the skill runs in its own context window, then have the skill use agents to keep context isolated per step.\n                        \n--- skill frontmatter ---\nname: my-skill\nfork: true\nIn his words\n\"add 'fork:true' to a skill's frontmatter to have it run in its own context window, then in the skill tell it to use agents to keep context isolated for each step also. Adding this to the built in /code-review skill to improve performance even more.\"\nWhy\n                        A heavy skill (deep research, code review) can pollute or blow out the main context. Forking gives it a clean window; per-step agents (tip 1) isolate further. Same instinct as Part 15's context minimalism — keep each unit of work to the smallest context it needs.\n```\n\nA correction to the activation trigger from Part 13 and Part 14. The launch said the bare word *\"workflow\"* in a prompt was the trigger. Boris has refined it:\n\n```\nIn his words\n\"Say 'use a workflow'. Just 'workflow' had too many false positives.\"\nDo this\n                        To launch a dynamic workflow, say \"use a workflow\" — e.g. \"use a workflow to rank these 80 resumes\" — not just the word \"workflow.\"\nUpdates Parts 13 & 14\n                        The workflow mechanics in Parts 13–14 are unchanged — orchestrator → implementer → verifiers → fixer, hundreds of agents, default to auto mode. Only the trigger phrasing tightened.\n```\n\nAnthropic launched **Claude Fable 5** — a *\"Mythos-class model we've made safe for general use,\"* whose *\"capabilities exceed those of any model we've ever made generally available.\"* Now in Claude Code and Cowork. Boris: *\"the best model I have used for coding, by a wide margin… a big step up.\"* Anthropic published [a full benchmark table](https://x.com/claudeai/status/2064394151441863006) too — Fable 5 is state-of-the-art on nearly all of them. It's priced at $10/M in · $50/M out — double Opus 4.8. Fable-specific effort/usage tactics are still emerging.\n\nThe announcement from Claude: *\"Introducing Claude Fable 5: a Mythos-class model that we've made safe for general use. Its capabilities exceed those of any model we've ever made generally available.\"* Available now in **Claude Code and Cowork**.\n\n```\nBoris's verdict\n\"Fable is the best model I have used for coding, by a wide margin. It is a big step up, enabling less prompts and steers, more efficient token use, better code quality, better tool use, more intelligent self-verification, longer running sessions, and higher trust & autonomy.\"\n\"Big model smell\" — Boris on living with it\n\"With Fable, it's felt like Claude has stepped up from being a coding agent to a thought and design partner… Fable has judgement, taste, and dimensionality in a way that previous models didn't. The first time I had this realization was when I asked Fable to debug something — it's the first model I've used that was so methodical and precise, taking measurements and adding logs then verifying that it truly fixed the issue before declaring victory. There's nothing in Claude Code's prompting telling it to do that; it's just part of its personality. It really has this 'big model smell.'\" That self-verifying debugging is the Verification (Part 1) + Opus 4.8 honesty (Part 13) thread paying off in the base model. Boris on living with Fable 5\n```\n\nThe step-ups, at a glance\n\n```\nThe benchmarks (Fable 5 → Opus 4.8 → GPT 5.5 → Gemini 3.1 Pro)\n                        Claude: \"state-of-the-art on nearly all tested benchmarks… the longer and more complex the task, the larger Fable 5's lead.\"\n\nAgentic coding, SWE-Bench Pro: 80.3% → 69.2 → 58.6 → 54.2\nFrontier coding, FrontierCode/Diamond (xhigh): 29.3% → 13.4 → 5.7 → —\nKnowledge work, GDPval-AA: 1932 → 1890 → 1769 → 1314\nSpatial reasoning, Blueprint-Bench 2: 38.6% → 14.5 → 36.2 → 26.5\nComputer use, OSWorld-Verified: 85.0% → 83.4 → 78.7 → 76.2\n```\n\n**Accuracy note:** \"Fable 5\" is the Mythos-class model made safe for general use; the table reports the higher of Mythos 5 / Fable 5 (within 1–3 pts). On the starred benchmarks (cybersecurity, biology, Terminal-Bench, Humanity's Last Exam, HealthBench), Fable 5 performs closer to Opus 4.8 due to safety fallbacks — so treat those higher figures as Mythos 5. Boris confirms the classifiers are currently \"trigger-happy\" (flagging ordinary debugging as cyber/bio) and the team is \"working on improving it.\"\n\n```\nA second voice — Andrej Karpathy (now at Anthropic)\n\"It's SOTA on everything by a margin… qualitatively, a major-version-bump-deserving step change forward. You can give it a lot more ambitious tasks than what you're used to — the model 'gets it' and it will just go. It's never felt this tempting to stop looking at the code at all (but don't do this in prod!).\" He adds the safeguards are \"a little too trigger-happy for launch\" — the same fallbacks behind the starred benchmarks above. Karpathy's take\n```\n\nFable 5 supersedes Opus 4.8 as the strongest coding model — which shifts a couple of earlier tips and leans harder into others.\n\n```\nIt's the new default for coding\n                        Updates Part 1's \"use Opus\" tip and Part 13's \"Opus 4.8, strongest yet.\" When you pick a model for coding, Fable 5 now leads.\n\"Less prompts and steers\" → lean into minimalism + delegation\n                        That's exactly the world Part 15's context minimalism and Part 10's delegation-over-guidance describe — give it the goal, not the micro-steps.\nLonger sessions + higher autonomy → the autonomy stack pays off more\n                        Auto mode (Parts 8, 11), /goal (Part 12), nested subagents (Part 16), and workflows (Parts 13–14) all benefit from a base model that self-verifies better and needs less babysitting.\nCaveat\n                        Pricing is live — $10/M input · $50/M output, exactly 2× Opus 4.8's $5/$25. Model id claude-fable-5; 1M context, 128K max output, adaptive thinking, knowledge cutoff Jan 2026; no fast mode yet. Fable-specific effort levels and usage best-practices aren't documented yet.\n```\n\nAnthropic runs hundreds of skills internally. Thariq cataloged what works, what doesn't, and how to think about building them. 9 skill types, 9 authoring tips, and distribution strategies from production use. We turned his post into a skill. Obviously.\n\nGet the full guide available directly in Claude Code. Type `/thariq-skills`\n\nanytime to surface it.\n\n``` bash\n$ mkdir -p ~/.claude/skills/thariq-skills && curl -L -o ~/.claude/skills/thariq-skills/SKILL.md https://howborisusesclaudecode.com/api/install-thariq\ncopy\n```\n\nCovers all 9 skill types, authoring best practices, progressive disclosure patterns, distribution strategies, and the gotchas Anthropic discovered running hundreds of skills in production.\n\nAfter cataloging all their skills, Anthropic noticed they cluster into recurring categories. The best skills fit cleanly into one.\n\n```\nLibrary & API Reference\nInternal libs, CLIs, SDKs, gotchas\nbilling-lib · platform-cli\nProduct Verification\nDrive the running product to verify\nsignup-driver · checkout\nData & Analysis\nIDs, field names, query patterns\nfunnel-query · grafana\nBusiness Automation\nMulti-tool workflows → one command\nstandup · weekly-recap\nScaffolding & Templates\nFramework-correct boilerplate\nnew-app · migration\nCode Quality & Review\nAdversarial review, style, testing\nadversarial · hypothesis\nCI/CD & Deployment\nCommit, push, deploy safely\nbabysit-pr · deploy\nIncident Runbooks\nSymptom → investigation → report\noncall · log-correlator\nInfrastructure Ops\nSafety-gated cleanup & maintenance\norphans · cost-investigation\n```\n\nThe best practices from running hundreds of skills in production.\n\nGet all 107 tips available directly in Claude Code. Type `/boris`\n\nanytime to surface these workflow patterns.\n\nA skill is a knowledge file that lives on your machine. Once installed, Claude references it automatically when you ask about workflows — or on demand with `/boris`\n\n.\n\n`npm install -g @anthropic-ai/claude-code`\n\nRun this command in your terminal to install globally:\n\n``` bash\n$ mkdir -p ~/.claude/skills/boris && curl -L -o ~/.claude/skills/boris/SKILL.md https://howborisusesclaudecode.com/api/install\ncopy\n```\n\nThis installs globally to `~/.claude/skills/`\n\n. For project-specific install, use `.claude/skills/`\n\ninstead.\n\nStart a new Claude Code session and type:\n\n```\n> /boris\n# Or just ask about workflows - Claude will use it automatically:\n> How should I set up parallel Claude sessions?\n```\n\nYou'll see the full tips document appear in your conversation. If you get \"skill not found\", verify the file exists: `ls ~/.claude/skills/boris/SKILL.md`\n\n```\n107 Tips Organized by Topic\n\nParallel Execution - Worktrees, multiple sessions, web/mobile\nModel Selection - Why Opus 4.5 with thinking\nPlan Mode - Start complex tasks right\nCLAUDE.md - Best practices, @.claude in PRs\nSkills & Commands - /simplify, /batch, /btw, custom workflows\nSubagents - Common PR automations\nHooks - PostToolUse, SessionStart, PermissionRequest, Stop\nPermissions - Pre-allow safe commands, wildcard syntax\nMCP Integrations - Slack, BigQuery, Sentry\nPrompting - Challenge Claude, write specs\nTerminal Setup - Ghostty, /voice, /color, keybindings\nBug Fixing - Slack MCP, CI tests, docker logs\nLong-Running Tasks - Stop hooks, background agents\nVerification - Chrome extension, browser testing\nLearning - Use Claude to understand code\nCustomization - Themes, spinners, output styles\nPlugins & Agents - LSPs, MCPs, --agent, custom agents\nSafety - Sandboxing, auto mode, permissions\nWorktrees - claude -w, Desktop, subagent isolation, non-git VCS\nScheduled Tasks - /loop, /schedule, automated workflows\nCode Review - Agent-powered PR reviews that catch real bugs\n/effort - Max reasoning mode for deeper thinking\nRemote Control - Teleport, mobile app, /remote-control\nSession Management - --name, /branch, --fork-session\nSetup Scripts - Automate cloud environment setup\nPostCompact Hook - React to context compression\niMessage Plugin - Text Claude from any Apple device\nAuto-Memory & Dream - Persistent, self-cleaning memory\nMobile App - Write code from the Claude iOS/Android app\nCowork Dispatch - Remote control for Claude Desktop\nDesktop App - Auto start and test web servers\n--bare - 10x faster SDK startup\n--add-dir - Give Claude access to more folders\nRoutines - Scheduled and event-driven Claude Code runs\nRewind - Double-Esc to drop failed attempts from context\n/compact vs /clear - Know when to summarize vs start fresh\nAuto-compact window - Env var to dodge context rot at 400k\nDelegation over Guidance - Treat Opus 4.7 like an engineer you hand off to\nFull Task Context Upfront - Goal, constraints, acceptance criteria in first turn\nxhigh effort - New default reasoning level for Opus 4.7\nAuto Mode + Parallel Claudes - Run multiple sessions, zero babysitting\n/fewer-permission-prompts - Scan history, tune your allowlist\nRecaps - Know what happened while you were away\nFocus Mode - /focus to see only the final result\n/go - Verify + simplify + PR in one composite skill\n4.6→4.7 Shifts - Calibrated length, less auto-tool-use, judicious subagents\nNotifications - Hooks and alerts for autonomous runs\nAgent View - claude agents control plane — one list of all your sessions grouped by status\n/goal - Set a completion condition; Claude keeps working until it's met (Ralph loop built into Claude Code)\nOpus 4.8 - Strongest coding model yet: SWE-Bench Pro 64.3 → 69.2, more honest about its own work, catches bugs before declaring victory\nHigh-Effort Default + xhigh - 4.8 defaults to high effort (same tokens as 4.7, better output); switch to xhigh for hard problems; Claude Code rate limits raised to cover\nDynamic Workflows - Research preview for tasks too big for one pass; say use a workflow to activate the orchestrator → implementer → verifiers → fixer pattern; save for migrations, refactors, perf, batch bug fixes, catalogue-and-categorize sweeps\nWorkflow Failure Modes - Why workflows exist: agentic laziness, self-preferential bias, goal drift\nWorkflow Primitives - agent, parallel, pipeline, schema/model/isolation; dynamic vs static harnesses\nSix Workflow Patterns - Classify-and-act, fan-out-and-synthesize, adversarial verification, generate-and-filter, tournament, loop-until-done\nWorkflow Use Cases - Bun's Zig→Rust rewrite, deep research/verification, sorting 1000+ items, rule adherence, root-cause, triage\nWorkflow Budgets - Cap tokens (\"use 10k tokens\"), pair with /goal and /loop, quick workflows, when not to use one\nSaving & Sharing Workflows - Press \"s\" to save, check into ~/.claude/workflows, distribute via a skill as a template\nAuto Mode Retired Plan Mode - Boris dropped plan mode for auto mode on Opus 4.6+ — newer models don't need a planning step\nContext Minimalism - Minimal system prompt + tools; let the model pull the rest (prompt eng → context eng → minimalism)\nWrite It Down, Don't Re-Prompt - Every mistake → CLAUDE.md or a skill, not a chat correction\nWhy Auto Mode Is Trustworthy - Thousands of transcripts classified + red-teamed into evals; safer than glazing over prompts\nNested Subagents - Agents kick off agents (depth=5) to manage context; monitor with arrow-down in the terminal\nfork: true - Experimental skill frontmatter: run a skill in its own context window; being added to /code-review\nWorkflow Trigger - Say \"use a workflow\" (not bare \"workflow\" — too many false positives)\nFable 5 - Anthropic's \"Mythos-class\" model — Boris's best coding model \"by a wide margin\"; in Claude Code + Cowork\nWhat Fable 5 Changes - New default coding model (supersedes Opus 4.8); leans into context minimalism + delegation\n\nTry After Installing\n\n> How do I run parallel Claude sessions with worktrees?\n> What should I put in my CLAUDE.md?\n> Set up a PostToolUse hook to auto-format my code\n> What's the best way to verify Claude's work?\n```\n\nPrefer to download manually? [Download SKILL.md](/boris-SKILL.md) and place it in:\n\n```\n~/.claude/skills/boris/SKILL.md\n```\n\nCreate the `~/.claude/skills/boris/`\n\ndirectory if it doesn't exist.\n\nThe skill automatically checks for updates when you type `/boris`\n\n. If a newer version is available, Claude will download it for you — no manual steps needed.\n\nTo uninstall: `rm -rf ~/.claude/skills/boris/`\n\n```\nHow Skills Work\nSkills are markdown files with YAML frontmatter that Claude Code loads automatically. When you type /boris or ask about related topics, Claude surfaces this knowledge to help you. Skills can be user-invocable (slash commands) or auto-surfaced based on semantic matching.\n```\n\n", "url": "https://wpnews.pro/news/how-boris-cherny-uses-claude-code", "canonical_source": "https://howborisusesclaudecode.com", "published_at": "2026-06-27 17:10:17+00:00", "updated_at": "2026-06-27 17:34:53.010210+00:00", "lang": "en", "topics": ["ai-tools", "large-language-models", "developer-tools"], "entities": ["Boris Cherny", "Anthropic", "Claude Code", "Opus 4.5", "Claude iOS", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/how-boris-cherny-uses-claude-code", "markdown": "https://wpnews.pro/news/how-boris-cherny-uses-claude-code.md", "text": "https://wpnews.pro/news/how-boris-cherny-uses-claude-code.txt", "jsonld": "https://wpnews.pro/news/how-boris-cherny-uses-claude-code.jsonld"}}