画板 1

    Claude Code in Practice: Setup, Configuration, and Automation Workflows

    5 hr ago0 views

    This guide explains how to use Claude Code in practice, from choosing an authentication and billing model to managing context costs, using slash commands, defining project-level permissions, enforcing checks with Hooks, maintaining CLAUDE.md memory, and understanding where checkpoints end and Git begins. It is intended for developers and teams that want a controlled, reviewable workflow rather than ad hoc assistant usage.

    Scope and Verification

    This article uses Claude Code as an example. The command names, configuration fields, and file paths are based on public documentation available at the time of writing; different versions may differ. After upgrading, run /help and /doctor first to confirm available commands, then check fields against the official documentation. Where information cannot be confirmed, the article notes that the official documentation should be treated as the source of truth.

    1. Before Access: Choose an Authentication Method and Control Costs

    Claude Code commonly has three access models.

    • Individual subscriptions (such as Pro and Max plans): Suitable for individual developers who use the tool frequently. The fee is fixed, and the usage included in a plan is defined on the official pricing page.
    • Team or enterprise plans: Suitable for multi-person collaboration and usually provide centralized billing and management. Whether audit capabilities are included depends on the specific plan.
    • API usage-based billing: Create a key in the Anthropic Console, set the ANTHROPIC_API_KEY environment variable, and use it. This is suitable for script integration or for evaluating results early in a project. With usage-based billing, usage maps directly to the bill.

    Use the following order when choosing. If only one person uses it and uses it every day, a subscription is more convenient. If you need to call it from CI or automation scripts, or if the team wants to allocate costs by project, choose API usage-based billing.

    Whichever option you choose, pay attention to context usage. Every conversation round occupies the context window, and long sessions, large file reads, and frequent code generation can increase consumption quickly. Recommended practices:

    1. Use /cost during a session to view current usage. Subscription users may see different information.
    2. For API accounts, set usage limits and alert emails in the Console.
    3. Do not read large logs or artifact directories into context as a whole. Specify only the files or fragments you need.

    2. Session Control: Common Slash Commands

    Slash commands start with /. Entering one triggers a preset operation. The following commands are commonly used in Claude Code.

    • /init: Scans the project structure and generates a draft CLAUDE.md. The generated content requires human review; an incorrect architecture description will continue to affect subsequent sessions.
    • /clear: Clears the current session context. Use it when switching to an unrelated task to avoid old context interfering with the new task.
    • /compact: Compresses historical conversation. You can add instructions to specify content that must be retained, for example, “Keep the database migration decisions and unfinished items.”
    • /cost: Views usage for the current session.
    • /doctor: Checks installation and configuration status. Run it first when you encounter abnormal behavior.
    • /memory: Opens and edits the memory file.
    • /hooks: Interactively views and configures Hooks.

    Teams can also define custom commands. Create a Markdown file under the project’s .claude/commands/ directory; the filename becomes the command name. For example, create .claude/commands/review.md:

    1. Review the uncommitted changes in the current workspace, focusing on:
    2. 1. Whether the parameters or return structures of public interfaces have changed;
    3. 2. Whether error handling is missing;
    4. 3. Whether there are obvious test gaps.
    5. Review target: $ARGUMENTS

    After saving, enter /review user module in the session to invoke it. $ARGUMENTS is replaced with the text entered afterward. The value of custom commands is that they fix repeated questions in place, so team members review code with the same standard.

    3. Project-Level Configuration: Permissions and Team Consistency

    Claude Code configuration is divided into user-level and project-level settings.

    • User-level: ~/.claude/settings.json, which applies to all projects on the local machine.
    • Project-level: .claude/settings.json, stored in the repository and committed to version control for team sharing.
    • Personal project-level: .claude/settings.local.json. Remember to add it to .gitignore; use it for personal preferences.

    The following is a minimal usable project configuration that limits what the assistant can read and execute:

    1. {
    2.   "permissions": {
    3.     "allow": [
    4.       "Bash(npm run test:*)",
    5.       "Bash(git status)",
    6.       "Bash(git diff:*)"
    7.     ],
    8.     "ask": [
    9.       "Bash(git push:*)"
    10.     ],
    11.     "deny": [
    12.       "Read(./.env)",
    13.       "Read(./.env.*)",
    14.       "Bash(rm -rf:*)"
    15.     ]
    16.   }
    17. }

    The idea behind this configuration is to deny by default and allow only explicitly needed operations. deny rules have the highest priority, so even if other rules allow it, .env cannot be read. ask rules prompt for confirmation before execution and are suitable for operations that are hard to undo, such as git push. The syntax of permission rules may change between versions. After writing the configuration, validate it with /doctor or by actually running a test command.

    For team rollout, divide responsibilities as follows.

    • Put shared rules in .claude/settings.json and merge them through code review.
    • Put personal preferences in .claude/settings.local.json and do not commit them.
    • Treat permission configuration changes as security policy changes. Someone must review them; authors should not confirm them on their own.

    4. Hooks: Insert Checks Before and After Key Actions

    Hooks are commands that run automatically before or after the assistant performs specific actions. They turn safety checks from “reminding the assistant to pay attention” into “enforcement by a program.”

    Hooks are written in the hooks field of settings.json. The PreToolUse event fires before a tool call is executed, and matcher specifies which tools trigger it. The following configuration runs a check script before the assistant writes a file:

    1. {
    2.   "hooks": {
    3.     "PreToolUse": [
    4.       {
    5.         "matcher": "Edit|Write",
    6.         "hooks": [
    7.           {
    8.             "type": "command",
    9.             "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/guard-paths.sh\""
    10.           }
    11.         ]
    12.       }
    13.     ]
    14.   }
    15. }

    The corresponding script .claude/hooks/guard-paths.sh is shown below. It reads the event JSON from standard input and allows writes only to the src/ and tests/ directories; all other paths are rejected:

    1. #!/usr/bin/env bash
    2. # Allow writes only to src/ and tests/; deny all other paths by default
    3. set -euo pipefail
    5. file=$(jq -r '.tool_input.file_path // empty')
    7. case "$file" in
    8.   "$CLAUDE_PROJECT_DIR"/src/*|"$CLAUDE_PROJECT_DIR"/tests/*)
    9.     exit 0
    10.     ;;
    11.   *)
    12.     echo "Refusing to write: $file is outside the allowed directories" >&2
    13.     exit 2
    14.     ;;
    15. esac

    The script requires jq. Confirm that it is installed and give the script execute permission with chmod +x. Before rollout, test it manually; do not assume the configuration takes effect:

    1. echo '{"tool_input":{"file_path":"/your/project/.env"}}' \
    2.   | bash .claude/hooks/guard-paths.sh; echo "exit=$?"

    You should see exit=2 and a refusal message. Then test with a path under src/; you should see exit=0. Exit code 2 means blocking; this point is subject to the official Hooks documentation.

    There are several boundaries to keep in mind with Hooks.

    • Hooks intercept only the events they match. Coverage for Bash commands must be designed separately; do not assume everything is covered.
    • Production-related operations, such as deployment, database migration, and release scripts, should be performed by humans or completed through a CI approval process, not protected only by a Hook.
    • Hook scripts are code themselves and also require review and testing.

    5. Persistent Memory: Maintain CLAUDE.md

    Claude Code reads CLAUDE.md in the project root at the start of a session and uses its content as background knowledge. Its purpose is to reduce repeated explanations and help the assistant understand the project’s architecture, commands, and constraints.

    A sufficient CLAUDE.md usually contains the following.

    1. # Project Memory
    3. ## Architecture
    4. - Frontend: React 18 + Vite, directory web/
    5. - Backend: Node.js Express, directory api/
    6. - Database: PostgreSQL 15
    8. ## Coding Standards
    9. - All interfaces use TypeScript type definitions
    10. - Error responses use a unified { code, message } structure
    11. - Component names use PascalCase
    13. ## Common Commands
    14. - Development: npm run dev
    15. - Test: npm test -- --coverage
    16. - Build: npm run build
    18. ## Notes
    19. - Do not modify the database schema directly; submit a migration script first
    20. - Public library updates must go through the review process

    Follow these principles when writing and maintaining CLAUDE.md.

    1. Do not write secrets, tokens, personal information, or production environment addresses. Once this content enters the memory file, it spreads with the repository and may be sent to the model service. Credentials should be stored in environment variables or a secret management service.
    2. Write only stable facts. Do not include temporary task progress; it will quickly become outdated.
    3. Update it after every important change. An outdated file is more dangerous than no file, because the assistant will follow incorrect information.
    4. Keep it short. The longer the file, the more context each session consumes. Large repositories can place additional CLAUDE.md files in subdirectories; the specific behavior is subject to the current version of the official documentation.

    6. Rollback: How Checkpoints and Git Divide Responsibilities

    Claude Code checkpoints can restore session state to a previous step. When the input box is empty, press Esc twice to open the rollback menu; the exact entry point may vary by version.

    Checkpoints have clear boundaries that you need to understand before use.

    • Checkpoints mainly record file modifications made by the assistant through editing tools.
    • Changes produced by executing commands through Bash are usually outside the scope of checkpoints. For example, files generated by npm install or scripts may not be undone during rollback.
    • Checkpoints do not replace version control. They do not roll back committed Git history, and they do not affect remote repositories or CI systems.

    For this reason, Git is the reliable final safeguard. A suggested way to use them together is:

    1. Before starting a large refactor, first commit a clean state.
    09040904

    Top articles