Open Claude. Type /debug. Hit enter. Nothing happens. There is no built-in slash command. There never was. And yet a small set of slash-shaped prompts has quietly become the de facto engineering interface to the model, adopted across IDE extensions, internal AI wrappers, and the workflows of the people who get the most out of Claude every day.
This post is the working manual. Ten patterns, three categories, and a small pyramid of the five that matter most. None of them are official. All of them work, because they map cleanly onto cognitive paths the model already has and signal — unambiguously — which one you want right now.
The illusion of the slash command
Claude does not officially expose a fixed slash-command system or built-in API endpoints for these features. There is no router on Anthropic's side parsing /refactor and dispatching to a refactor subsystem. The token is just text.
What is real is the convention. These “commands” are de facto engineering standards — adopted across AI wrappers, IDE integrations, and power-user workflows because they force predictable outputs from the model. The illusion is that there is a CLI. The reality is that there is a shared vocabulary, and the model has seen enough of it to behave consistently when it sees one.
Prompting as structured intent signals
Think of these patterns as commands not because they invoke anything, but because they consistently trigger specific, highly structured cognitive paths within the model. You are bypassing conversational pleasantries and sending a rigid signal about exactly how the information must be processed and formatted.
Compare the two prompts:
> Help me fix this codeYou will get a perfectly reasonable answer — and a perfectly random one. Sometimes a one-liner, sometimes a tutorial, sometimes a question back. The model has to guess what shape of response you want.
> /debug Help me fix this codeNow the response collapses into a predictable structure: issue identification, root cause, proposed fix, validation. Same input. Different cognitive path. The slash token did all the work.
The ten core patterns
Power users converge on roughly the same set of ten. They cluster cleanly into three functional domains: how you control context, how you make the model think, and how you make it execute.
- Context & control:
/context,/compact,/expand,/rewrite - Thinking & strategy:
/analyze,/compare,/plan - Execution & fixes:
/code,/refactor,/debug
Context & control
The patterns that keep long sessions coherent and within token budget. Most teams underuse these. Most coherence problems are context problems.
/context — grounding the model to prevent drift
Summarizes prior messages, extracts key constraints, clarifies assumptions. Use it whenever the conversation has drifted, before starting a new sub-task, or when you are debugging an inconsistency and you suspect the model is reasoning from stale assumptions.
> /context Summarize everything relevant so far for this embedded system design./compact — maximizing token efficiency and density
Removes redundancy, keeps only essential technical points, produces dense summaries. Use after a long explanation, when preparing notes or documentation, or when you are strictly managing API token limits and need the next prompt to carry the substance without the prose.
> /compact Summarize the FreeRTOS scheduling explanation in 5 bullet points./expand — the deep dive for complex architecture
The mirror of /compact. Adds deep explanations, includes concrete examples, breaks down concepts step-by-step. Use when you are learning a new framework, generating teaching material, or turning a tight summary into a comprehensive article.
> /expand Explain how TCB timers work in ESP-IDF FreeRTOS with examples./rewrite — the translation layer for stakeholders
Improves overall clarity, adjusts technical depth, changes writing style and tone. Use for converting raw engineering notes into docs, adapting content for different platforms, or cleaning up rough drafts before they go to a non-engineering audience.
> /rewrite Make this explanation suitable for beginner embedded engineers.Thinking & strategy
The patterns that force the model to slow down and reason instead of pattern-match. If you have ever caught Claude confidently asserting a plausible-sounding wrong answer, these are the patterns you reach for next time.
/analyze — forcing deep technical reasoning
Identifies underlying issues, evaluates architectural trade-offs, explains internal system behavior. Use for debugging complex embedded systems, reviewing architecture decisions, or conducting performance evaluations where a shallow answer is worse than no answer.
> /analyze Evaluate this ISR design for race conditions and latency issues./compare — the decision support matrix
Highlights technical differences, shows objective pros and cons, recommends specific use cases. Use for architectural decision-making, evaluating software libraries, or writing technical articles where readers need to leave with a clear “use X when…, use Y when…” takeaway.
> /compare vTaskDelay vs vTaskDelayUntil in ESP-IDF/plan — defining architecture and execution
Generates step-by-step breakdowns, defines key milestones, sequences tasks chronologically. Use for project design, course or curriculum creation, or complete firmware architecture planning where the order of operations matters as much as the operations themselves.
> /plan Design a BLE tracking system using ESP32-S3 and ESP-IDF.Execution & fixes
The patterns that produce code instead of conversation. Use these once you have done the planning work — they are deliberately bad at explaining themselves.
/code — implementation-first output execution
Provides minimal to no explanation, focuses purely on implementation, delivers clean runnable snippets. Use for rapid prototyping, embedded firmware development, or generating immediate API usage examples when you do not want a four-paragraph preamble.
> /code Show how to configure ADC continuous mode in ESP-IDF./refactor — the optimization and clean code pass
Cleans overall code structure, drastically improves readability, applies modern design best practices. Use for modernizing legacy embedded code, running optimization passes, or teaching clean code patterns by example.
> /refactor Improve this ISR and remove unsafe shared variable access./debug — root cause diagnostic analysis
Identifies the root cause of the error, suggests concrete implementation fixes, explains underlying failure modes. Use for compilation errors, runtime bugs, or tricky hardware-software interaction issues where the surface symptom is misleading.
> /debug Why is my ESP32 not waking from deep sleep using GPIO interrupt?The essential engineering stack
If you are working in serious engineering workflows, five of these ten patterns alone form a complete methodology covering roughly 90% of real-world use cases, from initial architecture down to execution.
/plan— architecture and execution. Decide what to build, in what order, before any code exists./compare— decision support. Pick between libraries, APIs, and approaches with the trade-offs on the table./analyze— deep technical reasoning. Force the model out of pattern-match mode and into actual evaluation./compact— control verbosity and tokens. Keep the working context dense as the session grows./context— maintain correctness over long sessions. Re-ground the model before it starts confabulating from drifted state.
The pyramid is intentional. Plan once. Compare options. Analyze the chosen path. Compact as you go. Re-ground when needed. The other five patterns (/expand, /rewrite, /code, /refactor, /debug) slot in as needed once the structure is right.
Where these patterns live
These conventions did not spring up in a single place. They diffused across the layer of tools sitting between the user and the model:
- IDE integrations — extensions inside modern editors like VS Code and Cursor, where slash prompts double as editor-aware shortcuts.
- Custom AI wrappers — internal enterprise tools and tailored chat interfaces that bake these patterns into UI affordances and system prompts.
- Developer workflows — CLI prompts and automated scripting pipelines where consistency of output shape matters more than conversational nuance.
- Internal tools — complex prompt-chaining and continuous integration setups where each step needs a predictable input/output contract.
Mastering these conventions guarantees predictable outputs across any interface that leverages Claude. The vocabulary travels with you across tools, even when the tools themselves do not share a codebase.
How to actually adopt these
A few rules of thumb from running these patterns in production workflows:
- Start with the five-layer pyramid. Plan, compare, analyze, compact, context. If you only memorize five, memorize these.
- Treat slash tokens as cheap. If a response is the wrong shape, prepend the right pattern and re-run. It is faster than arguing with the model in prose.
- Combine them in sequence, not in a single prompt.
/plan→/compare→/analyze→/codeworks./plan /code /debugin one line does not. - Encode them in your team's system prompts. If you ship an internal AI wrapper, define what each token means once and your whole team gets the same behavior. This is the cheapest standardization win in the building.
- Re-ground with
/contextbefore any high-stakes step. The model's confidence is uncorrelated with its memory of what you told it three turns ago.
None of this is official. None of it is documented as a feature. All of it works because the engineering community has voted, with their prompts, on the shapes of output they want — and the model has learned which token requests which shape. That is the architect's manual. The rest is practice.
Aditya
Related reading
- Trust, but sandbox — what to do once the agent has slash-commanded itself into shell access.
- When agents fail in production — patterns are upstream, evals are downstream.