What Claude Code Can Do That You Haven't Tried

Claude Code’s command reference has 114 entries for commands and bundled skills (checked 2026-09-26, removed commands included). The features on this page each remove one daily annoyance: CLAUDE.md imports, Read deny rules for secrets, editing the plan with Ctrl+G, /rewind, /btw, /goal, hooks, and the bundled /verify and /simplify skills.

This page is for developers who already use Claude Code every day. You stopped exploring after the first week, and the tool now ships a release almost every day. You re-prompt a plan that is 90% right, you patch forward over an approach you abandoned, and a teammate’s session reads .env while chasing a connection string.

The selection started from Gui Ferreira’s NDC AI 2026 talk, What Claude Code Can Do That You Haven’t Tried. Every command and key binding on this page was re-checked against Claude Code 2.1.283 and the official docs on 2026-09-26.

Tip

Adopt two or three features this week, not thirty. Use the table in the next section to pick the ones that match what annoys you.

What you’ll walk away with from these Claude Code features

• A lookup table from “the thing I keep doing” to the feature that removes it
• A CLAUDE.md split into shared, personal, global, and path-scoped layers
• A .claude/settings.json that keeps .env out of context, and how that rule is bypassed
• A PostToolUse hook, a /goal condition, and /verify, so the agent proves its own work
• Four copy-paste prompts and a failure-and-recovery table

Which underused Claude Code feature fixes your problem?

Start from the symptom. Each row links to its section below.

You keep doing this	Use this instead	Section
Pasting the same rules into CLAUDE.md, the README, and a docs file	@path imports	Imports
Watching Claude open .env while it debugs	permissions.deny with Read(...) rules	Secrets
Re-prompting a plan that has two wrong lines	Ctrl+G on the plan	Plans
Patching forward over an approach you no longer want	Esc Esc or /rewind	Rewind
Waiting for a long turn to finish before asking a quick question	/btw	Side questions
Typing “keep going, the tests still fail” every few minutes	/goal with a test condition	Goals
Writing “always run the tests” in CLAUDE.md and hoping	A PostToolUse hook	Hooks
Reading every line to know whether the change works	/verify, /simplify, /code-review	Verification

Set up Claude Code once

These settings take minutes and apply to every later session.

Import files into CLAUDE.md instead of copying them

The same rules end up in the README, a conventions file, and CLAUDE.md, and drift apart. Replace the copies with @ imports. Claude Code expands each imported file into context at launch, next to the CLAUDE.md that references it:

See @README.md for how to run the pipeline.
Coding rules live in @docs/conventions.md.
API shape: @openapi.yaml

Relative paths resolve from the file that contains the import, imports can nest up to four hops, and non-Markdown files work. Two details the docs mention but readers miss:

• An import removes duplication, not tokens. The imported file still loads at every launch, so importing a 900-line OpenAPI file costs the same as pasting it.
• An @path inside backticks stays literal text. Write `@README` when you only want to mention the file.

Prune CLAUDE.md with three questions

The official guidance is to keep each CLAUDE.md under 200 lines, because longer files consume more context and reduce adherence. Before a line earns its place, ask:

1. Do I need this in almost every conversation? If not, move it out.
2. Does it apply only to certain files or certain tasks? Put file-specific rules in .claude/rules/ with a paths: glob, so they load only when Claude works with matching files. Put task recipes in an Agent Skill.
3. Can the agent find it by itself? A hand-written file tree goes stale and Claude can list directories. Delete it.

A path-scoped rule looks like this:

---
paths:
  - "src/api/**/*.ts"
---

Every handler validates its input with the zod schema in src/api/schemas/.
Return errors as { error: { code, message } }, never as plain strings.

Copy-paste prompt: prune CLAUDE.md

Read CLAUDE.md and every file it imports. For each instruction, classify it as:
(a) needed in almost every session, (b) only relevant to specific paths,
(c) a task recipe, or (d) something you could discover from the repo.
Propose a new CLAUDE.md with only (a), a .claude/rules/ file with a paths:
glob for each group in (b), and a list of (c) items that should become skills.
Delete nothing yet. Show me the proposal as a diff first.

Separate personal, shared, and global instructions

The project CLAUDE.md is committed and shared. Some rules are yours alone:

• Personal, per project: a CLAUDE.local.md at the project root loads after CLAUDE.md. Add it to .gitignore. It exists only in the worktree where you created it, so if you use worktrees, import a file from your home directory instead.
• Global, every project: ~/.claude/CLAUDE.md and ~/.claude/rules/ apply to every session on your machine. Put durable preferences there, such as “answer in short bullet points”.

For the full loading order and auto memory, see the Claude Code memory system.

Keep secrets out of the context window

When Claude debugs a database error, it can read .env and settings files while it looks for the connection string. Everything it reads enters the context window and is sent to the model. Deny those reads in .claude/settings.json and commit the file, so the whole team gets the rule:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(!.env.example)",
      "Read(./**/appsettings*.json)",
      "Bash(dotnet user-secrets *)"
    ]
  }
}

A bare file name such as .env matches at any depth under the working directory, so the rule also covers services/api/.env. Read(.env.*) would also block .env.example, the template Claude needs to learn the variable names, so the ! line carves it back out; a ! rule only reopens paths blocked by rules listed before it in the same file. Put the same rules in ~/.claude/settings.json to cover projects that have none, but do not anchor them with a single leading slash there: in user settings, Read(/secrets/**) resolves to ~/.claude/secrets/**, not to your project.

A Read deny rule is not a sandbox

Read deny rules cover Claude’s file tools, file commands that Claude Code recognizes in Bash (such as cat, head, and sed), and redirections. They do not cover grep -r pattern . or a Python or Node script that opens the file itself. When the rule must hold, turn on sandboxing with /sandbox as well, which enforces file access at the OS level on macOS, Linux, and WSL2.

Sharpen your daily Claude Code loop

These moves happen dozens of times a day.

Edit the plan with Ctrl+G instead of re-prompting it

Enter plan mode with Shift+Tab or /plan. When the proposed plan is right except for two lines, press Ctrl+G to open it in your default editor. Fix the lines, save, and approve. Claude does not re-plan the parts that were already right.

For spec work, the bigger risk is that Claude fills gaps with assumptions you discover only after it builds the wrong thing. Make Claude interview you first:

Copy-paste prompt: interview me before planning

Before you write any plan, read docs/specs/invoice-export.md and interview me
about every assumption it leaves open: data shapes, error cases, permissions,
and what "done" means. Ask one question at a time, offer two or three options
where you can, and stop only when nothing is ambiguous. Then write the
acceptance criteria as a checklist I can verify without reading the code.

The last sentence matters: the acceptance criteria become the evidence you check instead of the diff.

Rewind instead of patching forward

You saw the result of one approach and want a different one. A new prompt keeps the abandoned attempt in context, where it costs tokens and pulls the next attempt toward the old design. Press Esc Esc on an empty prompt, or run /rewind, to restore the conversation, the code, or both to an earlier checkpoint.

Checkpoints track file edits made by Claude’s edit tools. They do not track files changed by Bash commands (rm, mv, a code generator) or by you outside the session. Commit before a risky step, so git covers what checkpoints cannot.

Match effort and model to the task

Claude Code’s default model on the latest release channel is Claude Opus 5.5 at medium effort (see the models hub for other channels and plans). Tune effort before you switch models:

• /effort high or /effort xhigh for a hard stretch; /effort status prints the current level.
• Write ultrathink anywhere in one prompt to request deeper reasoning for that turn only. Claude Code adds an in-context instruction and leaves the API effort level unchanged.
• /model switches model and saves it as your default for new sessions. To switch for this session only, open the picker with /model and press s on the model’s row.

“Plan on a strong model, execute on a cheaper one” is built in as the opusplan alias: Opus in plan mode, Sonnet for execution. Keep the default unless your own results show the split works.

Ask a side question with /btw

A normal prompt queues behind the current turn. /btw why did you pick a queue over a cron job? answers at once in an overlay, from what is already in context, without interrupting the turn or entering the conversation history. Side questions have no tool access, so Claude cannot read a new file to answer one.

Watch context before it degrades the session

• Run /context in a fresh session before you type anything. If the grid already shows a large share used, an MCP server or skill you installed months ago loads on every run. Remove it or scope it to the project that needs it.
• Run /compact with focus instructions before quality drops, not after: /compact keep the failing test names and the migration plan.
• Run /clear for a genuinely new task. Pass a name, such as /clear invoice-spike, to label the old conversation in the /resume picker.
• Run /usage to see session cost, plan limits, and activity.
• Start a line with ! to run a shell command without a reasoning step: ! npm test. The output still enters the context, so do not run a command that prints secrets.

For budgets and team-level controls, see cost control for Claude Code.

Audit memory with /memory

Auto memory keeps notes from your corrections in a memory directory, and the first 200 lines or 25 KB of its MEMORY.md index load into every session. Those notes do not expire. Run /memory every few weeks to open the files, delete notes that no longer hold, and turn auto memory off for a project where it misleads.

Pick up, paste, and leave your desk

• claude --continue (-c) reopens the most recent conversation in this directory. claude --resume (-r) or /resume opens a picker.
• Paste a screenshot with Ctrl+V (Cmd+V in iTerm2, Alt+V on Windows and WSL).
• /remote-control (/rc) makes the session available at claude.ai/code and in the Claude mobile app. It still runs on your machine, so the computer must stay on. See channels and Remote Control.

Run several sessions without losing track

• Worktrees: claude --worktree fix-invoice-rounding (-w) starts a session in its own git worktree, so a feature, a bug fix, and a review do not share one working tree.
• Names and colors: /rename invoice-bug and /color red label the prompt bar, so you recognize a terminal at a glance.
• Background sessions: /background (/bg) detaches the current session and claude agents opens agent view, a dashboard of background sessions that is in research preview. /tasks lists background work inside one session. See agent view.
• Permission modes: from v2.1.283 on the latest channel, auto mode is the starting mode for interactive terminal and VS Code sessions. A classifier reviews each action. claude -p, the Agent SDK, and models that auto mode does not support still start in Manual, as does any session where a settings file sets disableAutoMode. Shift+Tab from auto goes to Manual, then cycles Manual, acceptEdits, and plan.

Give the session a finish line with /goal

/goal sets a completion condition. After each turn, a separate small model checks the condition, and Claude starts another turn until it holds.

Copy-paste prompt: a goal with a checkable condition

/goal npm test -- invoices exits 0, the new test "exports a PDF for a
multi-currency invoice" exists and passes, and git diff --stat touches only
src/invoices/ and tests/invoices/

A goal only works as well as its condition. The evaluator does not run commands or read files; it judges what Claude has shown in the conversation. “The feature works” leaves it to opinion. A condition that names a command’s exit code and a test gives Claude something to run and the evaluator something to check.

Extend Claude Code with hooks, skills, and project MCP

This section covers four extension points.

Make checks deterministic with hooks

A hook runs a command on an event, outside the model. If CLAUDE.md says “always run the linter after editing”, the model follows it most of the time. A hook follows it every time:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "f=$(jq -r '.tool_input.file_path'); case \"$f\" in *.ts|*.tsx|*.js) npx eslint --max-warnings=0 \"$f\" 1>&2 || exit 2;; esac"
          }
        ]
      }
    ]
  }
}

The hook reads the event JSON on stdin, takes the edited file’s path with jq, and lints only that file, so pre-existing warnings elsewhere in the repo do not block every edit. A PostToolUse hook runs after the edit has happened, so it cannot undo it. ESLint exits 1 on a finding, which Claude would never see, so the command sends the report to stderr and exits 2 instead. On exit code 2, Claude reads the stderr and fixes the problem in the next step. A hook that exits 0 stays silent. To stop an action before it runs, use a PreToolUse hook instead.

Package scripts in a skill instead of standing up an MCP server

An Agent Skill is a folder at .claude/skills/<name>/SKILL.md. Claude sees each skill’s description and loads the skill when it is relevant, or you call it with /<name>. A skill can bundle scripts, not only instructions. To call an internal API with three odd endpoints, put your existing Python script in the skill folder, explain in SKILL.md how to run it, and add a “when this fails, try this” note. No MCP server needed.

Use the skills Claude Code already bundles

Claude Code ships bundled skills that need no install:

• /batch <instruction> researches a large change, splits it into 5 to 30 independent units, shows you the plan, and then runs one background subagent per unit.
• /simplify runs four review agents in parallel over your changed code (reuse, simplification, efficiency, and level of abstraction) and applies the fixes.
• /loop 5m check the CI run for this branch and tell me when it is green repeats a prompt while the session stays open.
• /verify builds and runs your app and observes the result, instead of trusting tests alone. /run-skill-generator records how to launch your app, so /run and /verify stop rediscovering it.
• /code-review reviews the current diff for correctness bugs, and /security-review checks the branch for vulnerabilities.

Browse more with /plugin. A plugin bundles skills, hooks, and MCP servers, and installs at user scope unless you pass another scope. See installing and managing skills.

Scope MCP servers to the project that needs them

claude mcp add writes to local scope by default: the current project, for you only. A server your team needs belongs in project scope, which writes .mcp.json at the repository root for you to commit:

claude mcp add --transport http --scope project notion https://mcp.notion.com/mcp

A server that exists only in one project’s .mcp.json does not load its tool definitions into every other project. Each teammate approves project servers the first time they run claude in the trusted repository; a cloned repository cannot approve its own servers. See MCP setup for Claude Code.

Use Claude Code beyond code

Anything on your disk is in scope: a folder of Markdown notes, a junk-drawer directory (plan first, because checkpoints do not cover moves made through Bash), or your brag document. Wrap the prompt below in a personal skill, so the next review season takes one command.

Copy-paste prompt: a brag document from git history

Using git log --author="$(git config user.email)" --since="3 months ago"
across this repository, write a brag document for my performance review.
Group the work by outcome (features shipped, incidents fixed, reviews,
tooling), cite the commit hashes or PR numbers for every claim, and list
anything you are unsure about as a question instead of guessing.

How do you check what these features produce?

Faster sessions help only when the output is correct. Make the agent prove its work, and read evidence instead of every line:

1. Write the check first. Put acceptance criteria in the plan (the interview prompt above) and turn them into tests before implementation.
2. Enforce the gates with hooks. A PostToolUse hook runs the linter or type checker after each edit, and a Stop hook can run the test suite before Claude hands back control.
3. Make “done” objective. Use /goal with an exit code and named tests, not with “it works”.
4. Observe the running app. Run /verify for behavior that tests do not cover, such as a UI flow or a CLI’s output.
5. Review with agents, sign off as a human. Run /simplify and /code-review on the diff. Then read the test results, the /verify observation, and git diff --stat, and sign off on the acceptance criteria. Read individual lines only where those disagree.
6. Keep a way back. Commit before a risky step, and use /rewind for anything that checkpoints track.

For the full testing workflow, see testing with Claude Code and automated review.

What goes wrong with these Claude Code features, and how to recover

Symptom	Cause	Recovery
Every new session starts on a different model than your teammates use	/model saved your choice as the default in user settings	Run /model, select the default, or press s next time to switch for one session only
/rewind restored the conversation, but a deleted file is still gone	Checkpoints do not track Bash file changes	Restore from git; commit before risky steps
Claude still printed a value from .env	The read went through grep -r or a script, which Read deny rules do not cover	Turn on sandboxing, and rotate the exposed secret
A fresh session already shows high context use in /context	User-scoped MCP servers, plugins, or a long CLAUDE.md load everywhere	Move servers to project scope, uninstall unused plugins, prune CLAUDE.md
/goal never finishes, or finishes too early	The condition is vague, cannot be satisfied, or asks for something Claude never prints, so the evaluator cannot see it	Run /goal clear and restate it as a command exit code plus named tests; add or stop after 20 turns to bound it
The hook runs but Claude ignores failures	The script exits 1 or 0 on failure, so Claude never sees stderr	Exit with code 2 on failure
The hook blocks every edit, and Claude starts fixing unrelated files	The hook lints the whole tree, which already has warnings	Scope the hook to the edited file, as in the example above
Claude repeats an outdated preference	A stale auto memory note	Run /memory and delete the note
/btw says it cannot check a file	Side questions have no tool access	Ask a normal prompt, which queues behind the current turn

End the week with /insights

Run /insights on Friday. It builds an HTML report from your recent sessions on this machine: how you use Claude Code, where things go wrong, and features to try. Pick one suggestion for next week. It is not available in cloud sessions.

Where to go next with Claude Code features

• Go deeper on the commands you adopted in slash commands mastery and Claude Code efficiency hacks.
• Turn the hook example into a full gate with hooks automation.
• Compare the equivalent tricks in the other tools on the power-user tips hub, in Codex efficiency hacks, and in Cursor time-savers.
• New to Claude Code? Start with installation.