7.1 - Operating Claude Code Day to Day

Build exercise: Write a CLAUDE.md, lock down permissions, and add a hook and a slash command

Beginner · 35 minutes

You'll practice:

• Write an accurate, current CLAUDE.md at the correct scope
• Configure allow/ask/deny permission rules in settings.json
• Create a custom slash command with $ARGUMENTS
• Add a PreToolUse hook that deterministically blocks a dangerous command

1. In a real project, write a project-level CLAUDE.md covering the test command, one important convention, and one thing to avoid - keeping any personal preferences out of it.

   A short, accurate file scoped correctly is more useful than a long, stale, or over-broad one - practicing both concision and correct scope matters here.

   You should see: Claude Code correctly following that guidance in a new session without being told again.

   Hints

   1. What belongs in a file every teammate will read versus a file only you will read?

   2. Put repo-wide facts (build/test commands, shared conventions) in the project CLAUDE.md at the repo root. Anything personal to you belongs in ~/.claude/CLAUDE.md instead, not this file.

   3. # Project conventions
      
      ## Commands
      - Run tests: `npm test`
      - Lint: `npm run lint`
      
      ## Conventions
      - All API routes live under `src/routes/` and export a default handler.
      
      ## Avoid
      - Do not edit files under `generated/` - they are build output.

2. In .claude/settings.json, add an allow rule for a safe read-only command, an ask rule for a moderately risky command, and a deny rule for a destructive one.

   This is the mechanism that actually gives you deterministic control over what Claude Code can do unattended - CLAUDE.md prose can't block a command, only permission rules and hooks can.

   You should see: Claude Code runs the allowed command silently, prompts you before the ask-listed one, and refuses the denied one outright even if you approve it interactively.

   Hints

   1. What's the Tool(pattern) syntax Claude Code uses for a permission rule, and which three buckets can a rule go in?

   2. Rules look like "Bash(git commit:*)" and are placed under an "allow", "ask", or "deny" array inside the "permissions" key of settings.json.

   3. {
        "permissions": {
          "allow": ["Bash(git status)", "Bash(git diff:*)"],
          "ask": ["Bash(git commit:*)"],
          "deny": ["Bash(rm -rf:*)"]
        }
      }

3. Create a custom slash command at .claude/commands/review.md that takes a file path via $ARGUMENTS and asks Claude to review it against your project's conventions.

   This turns a prompt you'd otherwise retype into a one-word, shareable invocation, and demonstrates how $ARGUMENTS threads user input into the template.

   You should see: Typing /review src/routes/users.js triggers the full review prompt with that path substituted in, without you typing the rest by hand.

   Hints

   1. What placeholder does Claude Code substitute with whatever text follows the slash command name?

   2. Write a Markdown file whose body is the prompt template; anywhere you write $ARGUMENTS, the text typed after the command name gets inserted.

   3. ---
      description: Review a file against project conventions
      ---
      Review $ARGUMENTS against the conventions in CLAUDE.md. Flag any violations and suggest fixes.

4. Add a PreToolUse hook in settings.json that blocks any Bash call matching a force-push pattern, returning exit code 2 with an explanatory message.

   This is the deterministic-enforcement mechanism from this lesson in action - unlike CLAUDE.md guidance, a PreToolUse hook that exits 2 physically prevents the command from running, every time.

   You should see: Attempting a force push is blocked before it executes, and Claude sees your hook's stderr message as the reason and adjusts its next action instead of retrying blindly.

   Hints

   1. Which hook event fires before a tool runs, and what exit code tells Claude Code to block the action rather than allow it?

   2. Configure a PreToolUse hook matched to the Bash tool that runs a small script; the script inspects the command being run and, if it matches a force-push pattern, writes an explanation to stderr and exits with code 2.

   3. {
        "hooks": {
          "PreToolUse": [
            {
              "matcher": "Bash",
              "hooks": [{ "type": "command", "command": "scripts/block-force-push.sh" }]
            }
          ]
        }
      }
      
      # scripts/block-force-push.sh
      #!/bin/sh
      read -r input
      echo "$input" | grep -q -- '--force' && { echo 'Force push is blocked by policy' >&2; exit 2; }
      exit 0