Claude Code CLI: commands and flags for every day

What does this solve?

Claude Code CLI runs in the project directory and works with the code where the code is: reads files, edits them, runs commands, parses the output and edits further. This eliminates the copy-paste between the editor and the browser chat - there is no need to manually collect context from a dozen files, paste it into the window and transfer the response back by hand. There is no need to explain the structure of the repository with each request: the agent does the tree search itself, and the permanent rules of the project are in CLAUDE.md is next to the code and is picked up at startup. What remains is what they open the terminal for: run tests, disassemble the failed assembly, repeat the migration following the example of the neighboring one, bring the file to the style accepted in the repository.

How it works

One session - one process in a specific directory. The launch directory defines the workspace: files outside of it are not read or edited until they are added explicitly - with the flag --add-dir at start or command /add-dir inside the session.

Context. Read files, command output and correspondence are located in one context window. It is finite. When the space runs out, the old part of the story collapses into a condensed retelling, and details from it are lost - the agent begins to “forget” the agreements ten minutes ago. Hence two daily tools: /clear before a new task and /compact with an explicit indication of what to save if the task is long and it’s too early to quit. How much space is occupied and by what - shows /context.

Tools. Reading a file, spot editing, searching by content and by name, running shell commands, loading pages. Each call goes through a permissions layer, so “the agent suddenly took down the branch” is only possible where it was allowed in advance.

Permissions. Ask/allow/deny rules are described by tool and by command pattern. They live in three places: .claude/settings.json in the repository (common for the team, committed), .claude/settings.local.json (personal, in .gitignore), settings file in the home directory (global). The mode of the current session is switched on the fly - Shift+Tab in a circle: normal mode with questions, automatic acceptance of edits, planning mode, in which the agent reads and proposes a plan, but does not change anything.

Project memory. CLAUDE.md at the root - rules that always apply: how to run tests, what package manager to use, what directories cannot be touched, what to name branches. The same file in the home directory sets personal habits on top of any project. You can add a line to memory directly from the dialog by starting input with #.

History. Sessions are saved to disk, so yesterday's work is brought up in its entirety, along with files read and decisions made. Rolling back the state of files to the point before an unsuccessful series of edits - /rewind or double Esc.

Extensions. Your slash command is a markdown file in .claude/commands/: put smoke.md with instruction text, received /smoke in this project. External sources (tracker, database, repository) are connected as MCP servers: list and status - /mcp, adding from shell - claude mcp add.

Subcommands that are needed every day:

Slash commands that are typed most often:

Input in line: @путь/к/файлу substitutes a specific file instead of searching, !команда executes a shell command and puts its output into context, # writes a line to memory, Esc interrupts the current action without killing the session.

One line rule: new task - new session; /clear is cheaper than parsing an answer poisoned by someone else's context.

How to connect

Step 1. Place the package. You need installed Node.js of the current LTS version (the required minimum is indicated on the installation page and in package.json package). Next:

npm install -g @anthropic-ai/claude-code
claude --version

An alternative to npm is a native assembly, which is installed with an installation script from the Anthropic website and updated by the command claude update. You can check which option is worth it and whether everything is ok with it via claude doctor.

Step 2. First launch in the project.

cd ~/projects/my-app
claude

Inside — /login to login (subscription or API key), then /statusto see account, model and working directory. Running from the home directory or from the root of the disk is a typical mistake: the agent receives a workspace the size of the entire computer.

Step 3. Create project memory. Team /init will go through the repository and collect a draft CLAUDE.md. The draft needs to be reduced by hand to the rules that actually repeat: test command, linter command, prohibitions, branch naming convention. The file is committed - it works for the whole team.

Step 4. Configure permissions. Minimum .claude/settings.json, which removes half the questions and at the same time closes the secrets:

{
  "permissions": {
    "allow": [
      "Bash(npm run test:*)",
      "Bash(npm run lint)",
      "Bash(git status)",
      "Bash(git diff:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

Step 5. Learn flags for scripts. In interactive almost everything is done with slash commands; flags are needed when the CLI is called from a script, hook or pipeline.

Step 6. Check non-interactive mode. Aka headless: input via pipe, output to stdout.

git diff --staged | claude -p "Проверь диф на утечку секретов и обратную несовместимость. Ответь списком находок или словом OK." --output-format json

Step 7. Make your first command. File .claude/commands/smoke.md with the text “Raise the application, pull the health endpoint, show the first errors from the log” turns into /smoke for everyone who cloned the repository.

Useful scripts

• Fallen test: !npm test puts the output into context, then please localize the cause and fix only that.
• Unfamiliar repository: /init, then a question about the entry point and the request path from the router to the database.
• Running check of changes: claude -p with input dif in hook pre-push or in the CI job.
• The same type of editing in dozens of files: a sample “as it should” in one file, the rest - according to the template, the result looks like git diff.
• Analysis of the incident: logs via the pipe, question about the coincidence in time with the last deployment.
• Draft of a migration or config based on the model of the neighboring module, with an explicit ban on touching the product settings.
• Repetitive team ritual (release notes, checklist before merging) - formalize in .claude/commands/.

Limitations

• Context window of course. On a large monorepository, the agent reads a lot of unnecessary things, the story collapses faster, the quality drops - working from a subdirectory and targeted links helps @файл.
• Expense is calculated by the tokens of the entire session, and not by the number of messages: long files in context are more expensive than a dozen short questions. Current consumption looks at /context i /usage.
• The result is non-deterministic. Two runs of the same problem give different diffs; It is necessary to compare not the texts of the answers, but the passed tests.
• Shell permits are the main area of ​​risk. Wide allow on Bash gives the agent everything that the user can do: deleting branches, publishing, sending letters.
• Secrets in context remain in context. .env and private keys are closed by the rule deny before the first session, not after.
• There is no offline: without a network the CLI does not work, it does not launch the local model underneath it.
• The review is not cancelled. The agent confidently writes plausible code with incorrect assumptions about the data; the diff is read by a person.

How to check the result

1. claude doctor — installation, version, directory rights, shell availability.
2. /status within the session - the same account, the same model, or the same working directory.
3. /context —the window is not clogged with debris, the service part has not eaten up the entire space.
4. git status i git diff after each series of edits - whether only those files in question were touched; unnecessary changes to line feeds and formatting are immediately visible.
5. Do-it-yourself tests and linter, not from the agent’s words: npm test, npm run lint.
6. /permissions —there is nothing on the list of allowed items that you don’t want to give away without question.
7. For script mode - claude -p ... --output-format json and parsing the response via jq: if the result field is empty or the response is not parsed, the pipeline is configured incorrectly.
8. If strange behavior occurs, restart with --verbose: you can see which tools were called and with which arguments.