/btw lets you ask a quick side question while Claude is working without breaking your flow. Type /btw what does this function return? and get an instant response in an overlay — the main task keeps running uninterrupted.
How it works: Claude spawns a temporary ephemeral agent with NO tools available. It cannot read files, run commands, or take actions. It responds once based solely on the current conversation context, then the overlay closes. The exchange never enters your main conversation history.
Key constraints:
Read-only — no file access, no shell commands
Single response — no follow-up in the overlay
Context-only — answers from what’s already in the conversation, not from disk
“Full context aware” means conversation context, not project files
When to use it:
Quick clarification mid-task (“btw what’s the default port for Postgres?”)
Terminology check without stopping work
Sanity check on something Claude just mentioned
Syntax: Start your message with btw (lowercase, no slash required) followed by your question. Claude Code detects the btw prefix and routes it to the ephemeral overlay agent.
Note: This feature (btw-side-question) was introduced around v2.0.73 and matured by v2.1.23. If you encounter issues, verify you’re on a recent version.
Session forking creates a new independent session that starts from an existing point in history. Use it when you hit a decision point and want to explore two directions without restarting from scratch.
Two ways to fork:
Terminal window
# From inside an active session
/branch
# From the CLI when resuming
claude--resume<session-id>--fork-session
/branch was added in v2.1.77, replacing /fork (still works as an alias).
When to fork instead of restart:
You’re at a working state and want to explore a risky refactor without losing it
You want to try two different approaches to the same problem in parallel
You found a good mid-session checkpoint and want to branch off for a hypothesis test
After forking: both branches are independent — changes in one don’t affect the other. Resume either later with claude --resume and the interactive session picker.
Tip: run /rename before forking so you can tell the two branches apart in the picker.
/recap provides a context summary when you come back to a session after a break. Claude automatically detects the absence and generates a brief recap of what was being worked on, the last actions taken, and what comes next. This makes returning to a long session significantly less disorienting, especially after an overnight gap or a context compaction.
Behavior: The recap fires automatically on re-entry to a session. It does not trigger at the end of a session; the trigger is when you return to one that has been inactive.
Configuration options:
Method
Effect
/config then search “recap”
Enable/disable the feature in the UI
CLAUDE_CODE_ENABLE_AWAY_SUMMARY=1
Force-enable (useful if telemetry is disabled)
CLAUDE_CODE_ENABLE_AWAY_SUMMARY=0
Disable completely
The feature works even with telemetry disabled (Bedrock, Vertex, Foundry, DISABLE_TELEMETRY). You can also toggle it from /config without touching environment variables.
Version history: Introduced in v2.1.108. Extended to telemetry-disabled environments in v2.1.110. A regression that caused auto-firing while the user was still composing a message was fixed in v2.1.113.
/insights analyzes your Claude Code usage history to generate a comprehensive report identifying patterns, friction points, and optimization opportunities.
“Early user stoppage” pattern → May indicate requests lack sufficient context
Performance optimization: The caching system ensures subsequent runs only analyze new sessions (not previously classified ones), making regular monthly runs fast even with large session histories.
Added in v2.1.63, /simplify is a bundled slash command that reviews your recently changed code for over-engineering and redundant abstractions, then fixes the problems it finds.
Quality — patterns that reduce readability or maintainability
Efficiency — algorithmic and structural improvements
It operates at the architecture and structure level, not at the formatter or linter level. /simplify complements tools like ESLint or Prettier rather than replacing them.
Added in v2.1.63, /batch orchestrates large-scale codebase changes by distributing work across 5–30 parallel agents in isolated git worktrees, each opening its own pull request.
/batch is the native equivalent of the parallel worktrees multi-agent pattern (see §15). Use it for large, repetitive, file-level changes that can be split into independent units: migrations, refactors, bulk type annotations, dependency replacements.
Note: Both /simplify and /batch are bundled slash commands that ship with Claude Code v2.1.63+. No configuration required.
Claude Code provides three distinct mechanisms for running recurring tasks. They differ on where the execution happens, how the task is triggered, and whether a local machine needs to be on.
Routines run on Anthropic’s infrastructure — your machine can be completely off. Each run clones a fresh copy of your GitHub repository. Three trigger types can be combined on a single routine.
Research preview: behavior, limits, and API surface may change.
Access: Pro, Max, Team, and Enterprise plans.
Daily run limits:
Plan
Runs/day
Pro
5
Max
15
Team / Enterprise
25
Extra runs are available with billing enabled beyond the daily cap.
Create a routine via:
claude.ai/code/routines — web interface
Desktop app — New task → New remote task
/schedule in the CLI (schedule trigger only; API and GitHub triggers require the web UI)
How each run works: Anthropic clones your repo, spins up a Claude session with the configured environment and MCP connectors, executes the task, then pushes any commits to a branch prefixed claude/ by default.
Key constraints:
No local file access (only files tracked in the GitHub repo)
Minimum interval is 1 hour for the schedule trigger
Supports MCP connectors: Slack, Linear, Google Drive, and others configured per routine
Runs appear as full sessions you can inspect, continue, or PR from
Each routine gets a dedicated HTTP endpoint. POST to it from any external system — alerting tools, deploy pipelines, CI scripts — and Claude opens a new autonomous session.
-d'{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'
The optional text field passes run-specific context (alert body, deploy ID, log snippet) to the routine’s prompt. The response returns a session_url to observe the run live.
Setup: add an API trigger from the routine’s edit page in the web UI, click Generate token (shown once — store it immediately), copy the endpoint URL. Tokens are per-routine and can be rotated or revoked from the same panel.
Use cases: Datadog alert fires → Claude correlates trace with recent commits, opens draft fix PR; CD pipeline calls endpoint after deploy → smoke checks + go/no-go to Slack channel.
Fires a new session automatically on matching GitHub repository events. Requires installing the Claude GitHub App on the target repo (separate from /web-setup).
A good Routine candidate has three properties: it runs the same logic every time (or reacts to a well-defined event), the output is concrete (PR opened, message posted, file updated), and no human needs to be in the loop during execution.
Five angles to audit any project:
Angle
Questions to ask
Scheduled maintenance
What do you do manually on a schedule and sometimes forget? Dependency audits, stale PR triage, coverage drift, dead code reports
Event-driven reactions
What should happen on every PR open or merge but doesn’t because nobody gets to it? Review checklists, changelog updates, cross-repo sync
Alert response
When monitoring fires, what’s the first thing a dev does? Could that step run automatically before the human looks?
Cross-system sync
What drifts because the sync is manual? Two SDKs, a doc site and an API, GitHub issues and Linear
Release automation
What do you run by hand before or after a deploy? Smoke tests, release notes, stakeholder notifications
Use the /routines-discover command to run this analysis against any codebase — it reads the repo, identifies concrete candidates across the five angles, and ranks them by value-to-effort ratio.
Desktop tasks run on your local machine via the Claude Code Desktop app. Your machine must be on, but you do not need an active terminal session.
Unlike Cloud tasks, Desktop tasks have full access to local files and your existing MCP configuration. The minimum interval is 1 minute.
Create a task: open the Desktop app, go to the Schedule page, click New task. You can also create a remote (cloud) task from the same page by selecting New remote task.
How each run works: A fresh Claude instance starts, reads your project files, executes the task prompt, and shuts down. Missed runs (machine was off) are queued and executed when the app reopens.
Official docs: https://code.claude.com/docs/en/desktop-scheduled-tasks
For full control without the Desktop app, wire up the system cron directly with Claude’s headless flag:
Terminal window
# crontab -e
08**1-5bash-c'source /home/user/.env && cd /your/repo && claude --print "summarize git changes since yesterday" >> /var/log/claude-daily.log 2>&1'
This approach runs entirely offline without any Anthropic infrastructure and has no minimum interval. Three things to get right: use the full path to claude (check with which claude), load your ANTHROPIC_API_KEY from a file rather than hardcoding it, and redirect both stdout and stderr to a log file so you have a record of each run.
/loop [interval] [prompt] runs a prompt or slash command on a recurring interval within your current session. It stops when you press Ctrl+C or send any new message.
Terminal window
/loop5mcheckthedeploy
/loop30m/slack-feedback
/loop1h/pr-pruner
How it works: Claude executes the prompt, waits for the interval, executes again, repeat. Each execution is timestamped in the transcript. You can reference a slash command (like /loop 30m /review-pr) or write a free-form prompt directly.
Use cases from Boris Cherny (Claude Code creator):
Loop
What it does
/loop 5m /babysit
Auto-handle code review, rebase, push PRs forward
/loop 30m /slack-feedback
Post PRs for team feedback every 30 min
/loop 1h /pr-pruner
Clean up stale PRs on a schedule
Constraints: Session-scoped only. Max 3 days runtime, minimum 1 minute interval, maximum 50 tasks per session.
/loop added in v2.1.71. Timestamp markers in loop transcripts added in v2.1.86. Cloud and Desktop Scheduled Tasks launched March 9, 2026. Source: code.claude.com/docs/en/whats-new
You received the following arguments: $ARGUMENTS[0] $ARGUMENTS[1] $ARGUMENTS[2]
(Or use shorthand: $0 $1 $2)
Process them accordingly.
Usage:
/tech:deploy production
$ARGUMENTS[0] (or $0) becomes production.
⚠️ Breaking Change (v2.1.19): The argument syntax changed from dot notation ($ARGUMENTS.0) to bracket syntax ($ARGUMENTS[0]). If you have existing custom commands using the old syntax, update them:
Terminal window
# Old (< v2.1.19):
$ARGUMENTS.0 $ARGUMENTS.1
# New (v2.1.19+):
$ARGUMENTS[0] $ARGUMENTS[1]
# Or use shorthand:
$0$1
Pair $ARGUMENTS with argument-hint so users see available options in the command picker. The hint appears as placeholder text when typing the command:
---
description: Deploy to a target environment
argument-hint: "<env> [--skip-tests] [--dry-run]"
---
Deploy to $ARGUMENTS[0] environment.
When the user types /deploy, the menu shows: /deploy <env> [--skip-tests] [--dry-run]
The standard template above works well for workflow commands. For commands that are procedurally risky (deploy flows, data migrations, one-way operations), add a “Context Validation Checkpoints” section before the steps:
## Context Validation Checkpoints
Before executing any step, verify all of these are true.
If any checkpoint fails, stop and explain why.
* [ ] Target branch exists and is up to date with main
* [ ] No uncommitted changes in the affected files
* [ ] Required config file exists at path X
* [ ] Credentials or permissions are available
The checklist forces explicit precondition verification rather than letting Claude discover failures mid-execution. A failed checkpoint produces a clear error with a fixable reason; a mid-step failure produces a partial state that is harder to recover from.
Fork-ready template at examples/commands/recipe-template.md in this repo.