One Claude Code Tip a Day: Ask /help Before You Guess

Series Note

This post is part of the “One Claude Code Tip a Day” series — a daily guide to using Claude Code more effectively.

The Real Problem: Guessing the Interface

Claude Code has enough workflow controls that guessing is expensive. Developers often remember one or two commands, then treat the rest of the session like a normal chat window. That habit leads to avoidable friction: clearing the wrong context, missing a cheaper model switch, forgetting how to attach files, or asking the agent to do something manually that already has a command. Today’s tip is simple but useful: start serious sessions by running `/help` before you rely on memory.

Why /help Is More Than Documentation

The value of `/help` is not that it teaches you every feature at once. Its value is that it gives you the current local truth. Claude Code changes, plugins and environment behavior can differ, and your memory may be stale. A quick help check turns the interface into a menu of available moves. Instead of asking “Can Claude do this somehow?”, you can ask “Which built-in command gets me there with the least ambiguity?”

A Practical Session Pattern

When you open Claude Code in a repo, use a three-step warmup. First, run `/help` and scan the commands that affect context, files, shell access, model choice, and status. Second, choose the smallest command that helps the task. For example, if the goal is to understand a bug, you may combine `@file` references with a read-only prompt. If the goal is to recover from a messy conversation, `/clear` may be better than adding another instruction. Third, tell Claude why you chose that command so the session has an explicit workflow.

Example: Avoiding a Bad Debug Loop

Imagine a deployment failure where the app works locally but fails in production. A rushed session starts with “debug this” and quickly becomes a pile of guesses. A better start is: run `/help`, confirm how to inspect status, reference files, and execute shell commands, then say: “We are going to debug from evidence. Read the deployment config and package scripts first. Do not edit yet. After that, propose which command from this environment should verify the failing path.” The help menu becomes a guardrail against improvising the wrong workflow.

Turn Help Into a Checklist

After reading `/help`, convert it into a task-specific checklist. For a code review session, the checklist might be: attach the changed files, inspect `git diff`, run targeted tests, then summarize risks. For a documentation task, it might be: attach the README, inspect the package scripts, ask for a doc outline, then edit only the relevant section. The point is not to memorize every command. The point is to select the commands that make this particular session safer.

Common Failure Modes

The first failure mode is treating `/help` as beginner material and skipping it. Experienced users are exactly the people who benefit from a fast interface refresh. The second is reading the help output passively without changing the plan. If a command exists for context management or file targeting, use it rather than describing the same thing vaguely. The third is letting the agent infer workflow from a broad request. Help should narrow the next move, not merely decorate the session.

Key Takeaway

Run `/help` when the cost of a wrong workflow is higher than ten seconds. It gives you the current command surface, helps you choose precise controls, and prevents stale memory from driving the session. The rule of thumb: before asking Claude Code to solve a serious task, ask the tool itself what moves are available, then build the session around the smallest useful command.