Slash commands and keybindings: the parts of Claude Code most people don't customize
Published 2026-05-11 by Owner
Most Claude Code users learn the keyboard shortcut to submit a message and stop there. The tool has an entire input layer on top of that — slash commands that trigger specific behaviors, user-defined commands that invoke skills, and a keybindings file that controls every key action in the interface. None of this is hidden, but none of it is prominently documented either. The result is that people work around friction that’s already solved.
This guide covers the pieces most worth knowing, roughly in order of how quickly they pay off.
Built-in slash commands
Claude Code ships with a set of slash commands that control session state. They’re available on any prompt line by typing /.
/help— lists all available slash commands, including user-defined ones, with a short description of each/clear— clears the current conversation context; useful when a session has accumulated too much noise and the model is starting to lose the thread/compact— compresses the conversation history into a shorter summary without losing the essential facts; cheaper than/clearwhen you want continuity but need to trim context/init— initializes aCLAUDE.mdfile in the current working directory by inspecting the repo and generating a starter configuration; run this once per new project/resume— restores a previous session by its ID; paired with session IDs shown after/helpor in the session log
These are not aliases for prose commands. /compact does something the model can’t do by being asked to “summarize the conversation” — it calls a dedicated compaction path that Claude Code owns, not the model’s next response.
Two others worth knowing even though they come up less often: /bug opens a pre-filled GitHub issue for Claude Code itself with session context attached, and /cost prints a running token-spend summary for the current session. Neither is in the default documentation overview, but both show up in /help output.
User-defined slash commands as skill triggers
Beyond the built-ins, Claude Code supports user-defined slash commands. Each command maps to a skill — a prompt-plus-instructions file in the skills directory. Typing /<skill-name> invokes that skill directly.
The skills directory is ~/.claude/skills/ for personal skills, or .claude/skills/ inside a project repo for project-scoped skills. Each skill is a .md file whose filename becomes the slash command name. A skill named review.md becomes /review.
This is meaningfully different from how skills can auto-trigger. A skill has a trigger: field in its frontmatter; if that trigger description matches the user’s intent, Claude Code can invoke the skill automatically without an explicit slash command. The slash command path bypasses that matching entirely — typing /review always invokes the review skill, regardless of whether the current message looks like a review request.
The practical difference: auto-triggering is convenient but fuzzy. If your review skill has a broad trigger, it might fire when you didn’t intend. The slash command path is unambiguous. For skills you want to run deliberately — code review, deployment checks, a release checklist — a direct slash command invocation is safer than relying on trigger matching.
---
name: review
description: Pre-landing code review. Checks for correctness, test coverage, and obvious issues.
trigger: when the user asks for a review, check the code, or review my changes
---
Review the diff since the last commit. Check for:
- Correctness issues or edge cases missed
- Missing or broken tests
- Code that doesn't match the project's style conventions
Return findings as a bulleted list, most important first.Save that to ~/.claude/skills/review.md and /review is available in every Claude Code session. For team skills, put the file in .claude/skills/review.md and check it into source control.
The skill file above is intentionally short. Longer skill files don’t necessarily produce better results; they add context budget cost and sometimes dilute the instruction. A skill that does one thing well is more reliable than a multi-purpose skill that tries to cover every case. If a skill ends up covering two distinct workflows, split it into two files.
keybindings.json
Claude Code’s keyboard behavior is controlled by ~/.claude/keybindings.json. The file doesn’t exist by default; create it to override any default binding.
The format is an array of objects, each with an action and a key:
[
{ "action": "submit", "key": "ctrl+enter" },
{ "action": "interrupt", "key": "ctrl+c" },
{ "action": "focus_chat", "key": "escape" }
]The three most commonly bound actions:
submit — the default is Enter. Most people who’ve used terminal-style tools prefer ctrl+enter for submit because it lets them use Enter for newlines inside a prompt. This is the single most common rebind.
interrupt — stops the current model run. The default varies by terminal. Rebinding it to something reachable with one hand (ctrl+c, or escape if that’s not taken) means not fumbling when an agent run goes wrong.
focus_chat — moves keyboard focus to the chat input. Useful if Claude Code is running as a panel alongside other tools and the cursor has drifted elsewhere.
Changes take effect on the next Claude Code startup. There’s no reload command; quit and restart.
One thing to confirm before writing the file: Claude Code normalizes key names to lowercase and treats ctrl, cmd, alt, and shift as modifiers. On macOS, cmd+enter and ctrl+enter are both valid; on Linux, only ctrl+* bindings work as expected since there’s no cmd key. If a binding silently does nothing after a restart, a mismatched modifier is the first thing to check.
Chord bindings
keybindings.json supports chord bindings — two-key sequences where the first key primes the input and the second key fires the action. The syntax uses a space between the two keys:
[
{ "action": "submit", "key": "ctrl+k ctrl+s" },
{ "action": "clear_context", "key": "ctrl+k ctrl+x" }
]Typing ctrl+k primes the chord; the next key completes it. Any other key cancels it.
Chords are worth using for actions that should be deliberate. /clear and clear_context are destructive — submitting context by accident is annoying. Putting them behind a chord means muscle memory can’t fire them accidentally. Submit doesn’t need a chord (you want it fast) but rare actions like session management do.
The tradeoff: chords require two keypresses and a brief pause, so they add friction. That friction is the point for anything you want out of the “fast reflex” zone.
A pattern that works well: use single-key bindings for anything you do dozens of times per session (submit, interrupt, focus), and put session-altering actions (clear, compact, close) behind chords. The chord scheme doesn’t need to be elaborate — one prefix key (ctrl+k) handling all the risky actions is enough, and it mirrors the convention from editors like Emacs and VS Code that many developers already know.
Things most people don’t realize they can change
A short list of customizations that solve real friction once found:
The submit key. Already covered above, but worth emphasizing: the default Enter to submit is the thing beginners hit by accident most often when writing a multi-line prompt. The fix is one line in keybindings.json. Most people who know this already changed it on day two.
Skill scoping. Personal skills in ~/.claude/skills/ are global; project skills in .claude/skills/ are repo-scoped and can be committed. Most users put everything in the global directory and then can’t figure out why a skill that only makes sense for one repo keeps showing up elsewhere.
The /compact budget. /compact accepts an optional token target: /compact 4000 compresses to roughly 4000 tokens of history. Without an argument it uses a default target. For long sessions with a lot of code context, specifying a tighter target keeps the next window cheaper.
/init on existing projects. Many users run /init only on fresh repos. It’s also useful on existing repos you’ve just checked out — it reads the codebase structure and generates a CLAUDE.md that reflects what’s actually there, rather than starting from scratch.
The CLAUDE.md as a session anchor. /init creates the file but doesn’t keep it updated. CLAUDE.md is read at the start of every session as persistent context. If a project’s conventions drift from what’s in the file, the model gets stale instructions. Treating CLAUDE.md as a living document — updated when patterns change, not just created once — is the difference between a useful configuration and an ignored one.
Skill naming and the /help inventory. The name of a skill file is its slash command name. If two skills have the same name — one global, one project-scoped — the project-scoped skill wins. That precedence rule is useful: project skills can shadow global ones for specific repos without affecting everything else. The full inventory of what’s active in the current session always appears in /help.
Putting it together
None of these features require deep configuration. The most impactful change for most users is the submit key rebind — it takes two minutes and eliminates one of the most common accidental inputs. From there, the slash commands worth learning are /compact and /resume because they extend how long a session stays useful before needing a full /clear.
User-defined skills are where the leverage compounds. One well-written skill file turns a slash command into a repeatable workflow that runs the same way every time. The team-skill path — checked into the project repo under .claude/skills/ — means those workflows are shared without any setup step for the next person.
The ordering of steps that returns value fastest: change the submit key first (five minutes, immediate impact), learn /compact and /resume next (extends session usefulness), then write one skill for the workflow you repeat most often. That sequence covers the majority of the benefit without requiring a full audit of every configurable surface.
The configuration surface here is small. The upside-to-effort ratio on learning it is unusually good.
As Claude Code adds more built-in slash commands in future releases — the list has grown with each version — the pattern will stay the same: /help is the canonical inventory, and anything not in /help is either not real or not available in the current version. Start there before searching elsewhere.
