Claude Code Power User Guide: The Terminal-First Vibecoder Setup

Why this matters

Running claude in your terminal is easy. Getting it to enforce your team's lint rules, auto-format on every write, delegate to a read-only research agent while you keep coding, and remember your project conventions across sessions — that's a different story. This guide is for builders who want Claude Code to feel like an extension of their hands, not a chatbot they have to babysit.

We'll cover the full power-user stack: settings.json, skills and custom slash commands, hooks for guardrails, sub-agents for parallelism, .mcp.json for tool servers, CLAUDE.md for persistent memory, and the /clear, /compact, and planning mode controls that keep long sessions from going sideways.

The setup

Before anything else, confirm you're on a recent Claude Code version:

claude --version
claude update

Your config lives in two places:

• Global — ~/.claude/settings.json (applies to every project)
• Project — .claude/settings.json (committed to the repo, shared with the team)

Project settings override global settings. Use global for personal preferences and project settings for team-wide rules.

Step 1: Configure settings.json and lock down permissions

settings.json is where you define what Claude can and cannot do without asking. A well-tuned file eliminates most approval prompts on commands you trust while keeping destructive operations gated.

{
  "model": "claude-sonnet-4-5",
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Read",
      "Edit",
      "Write"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(curl * | bash)",
      "Bash(sudo *)"
    ]
  },
  "env": {
    "NODE_ENV": "development",
    "NEXT_TELEMETRY_DISABLED": "1"
  },
  "hooks": {}
}

Permission syntax: Bash(git commit *) allows any git commit invocation. Bash(npm run *) allows all npm scripts. Be specific — Bash(npm run build) is safer than Bash(npm *) if you want to prevent arbitrary package installs.

The env block injects environment variables into every session — useful for disabling telemetry, setting DEBUG flags, or pointing at local service URLs without polluting your shell profile.

Step 2: Build skills and wire custom slash commands

Skills are the /slash-command system. They're markdown files with YAML frontmatter that give Claude a reusable playbook. The directory name becomes the command name.

Create a project-level commit skill:

mkdir -p .claude/skills/commit

Then write .claude/skills/commit/SKILL.md:

---
name: commit
description: Stage and commit current changes with a conventional commit message
disable-model-invocation: true
allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status) Bash(git diff *)
---

Create a conventional commit for the current staged and unstaged changes:

1. Run `git status` and `git diff` to understand what changed
2. Stage relevant files with `git add`
3. Write a commit message: `type(scope): short description`
   - Types: feat, fix, chore, refactor, docs, test
   - Keep the subject under 72 characters
4. Commit with `git commit -m "..."`

Do not push. Do not amend existing commits.

Now /commit is available in every session for this project. Because disable-model-invocation: true is set, Claude won't trigger it automatically — you control when commits happen.

For personal skills you want across all projects, put them in ~/.claude/skills/ instead. Skills at the personal level load into every project without committing anything to the repo.

The classic .claude/commands/ path still works for simpler cases — a single markdown file without a directory. Skills are preferred because they support supporting files, frontmatter-based invocation control, and sub-agent execution.

For the prompting patterns that make your skills actually work, the key is front-loading the use-case in description so Claude's auto-discovery knows when to reach for it.

Step 3: Wire hooks for guardrails and automation

Hooks are shell commands that fire at specific points in Claude's lifecycle. They're deterministic — they always run, regardless of what Claude decides. This makes them the right tool for enforcement, not suggestions.

The four main hook events:

• PreToolUse — fires before Claude uses a tool (Read, Write, Bash, etc.)
• PostToolUse — fires after a tool executes
• Stop — fires when Claude finishes responding
• SessionStart — fires when a session begins

Add hooks to your settings.json under the hooks key:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write \"$CLAUDE_TOOL_INPUT_FILE_PATH\" 2>/dev/null || true",
            "timeout": 15
          }
        ]
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"$CLAUDE_TOOL_INPUT_COMMAND\" | grep -qE '(rm -rf|sudo|curl.*bash)' && exit 2 || exit 0",
            "timeout": 5
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Claude finished\" with title \"Claude Code\"'",
            "timeout": 5
          }
        ]
      }
    ]
  }
}

The PostToolUse hook above runs Prettier on every file Claude writes or edits — no more manual format passes. The PreToolUse hook blocks dangerous bash patterns before they execute. The Stop hook sends a macOS notification so you can walk away without watching the terminal.

Exit codes matter for PreToolUse: exit 2 blocks the tool call and shows an error to Claude. Exit 0 (or any non-2 code) lets it proceed. This is how you build hard stops into the workflow.

Run /hooks inside Claude Code to inspect all configured hooks and their current state.

Step 4: Spawn sub-agents for parallel work

The Agent tool lets Claude delegate to isolated sub-agents that run concurrently. This is the unlock for large tasks that have independent subtrees — auditing multiple modules, running parallel research, or executing long-running tasks without blocking your main session.

You can configure sub-agents explicitly in .claude/agents/. A sub-agent definition is a markdown file with frontmatter:

# .claude/agents/explore-agent.md
---
name: explore
description: Read-only codebase research agent. Use for audits, dependency checks, and understanding unfamiliar code without making changes.
allowed-tools: Read Grep Glob
---

You are a read-only research agent. Explore the codebase, gather information, and return findings. Do not write, edit, or execute any code.

In practice, you don't need to define agents to use parallelism — Claude uses the Agent tool automatically when it recognizes independent subtasks. You can explicitly request it: "Do these three things in parallel" or "Research X and Y simultaneously." The sub-agents respect your hooks — PreToolUse and PostToolUse fire for every tool a sub-agent uses, so your guardrails stay active.

For context management in long parallel sessions, see the context management guide — sub-agents each have their own context window, which is both the power and the gotcha.

Step 5: Configure MCP servers in .mcp.json

MCP (Model Context Protocol) servers extend Claude's tool set beyond the built-ins. Configure them in .mcp.json at the project root:

{
  "mcpServers": {
    "supabase": {
      "command": "npx",
      "args": ["-y", "@supabase/mcp-server-supabase@latest"],
      "env": {
        "SUPABASE_ACCESS_TOKEN": "${SUPABASE_ACCESS_TOKEN}"
      }
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PAT}"
      }
    }
  }
}

Environment variable references (${VAR_NAME}) pull from your shell environment — never hardcode tokens in .mcp.json if the file is committed. Run /mcp inside Claude Code to see which servers are connected and their status.

Keeping sessions clean: /clear, /compact, and planning mode

Long sessions accumulate context that slows Claude down and introduces drift. Three tools keep this under control:

• /clear — wipes the conversation history and starts fresh. Use it when you finish a feature and start something unrelated.
• /compact — compresses the conversation into a summary, freeing context while preserving key decisions. Claude Code carries invoked skills forward through compaction.
• Planning mode (press Shift+Tab twice, or start a message with think:) — Claude reasons through the approach before acting. Critical for multi-file refactors and anything touching data models.

The CLAUDE.md file in your repo root acts as persistent session memory — it loads every time Claude Code starts in that directory. Keep it factual: conventions, data model notes, commands to avoid. Avoid letting it balloon into a long procedure file; that's what skills are for.

Common mistakes

Allowing too broadly in permissions. Bash(*) with no restrictions means Claude can run anything without prompting. Use specific allow rules.

Blocking at write-time instead of submit-time. A PreToolUse hook on Edit that runs slowly will make every edit feel laggy. Use PostToolUse for side-effects like formatting, and PreToolUse only for fast validation or hard blocks.

Putting procedures in CLAUDE.md. CLAUDE.md loads every session whether you need it or not. Long procedures waste context. Move them to skills — they only load when invoked.

Forgetting hooks fire in sub-agents. If your PreToolUse hook has a side effect (writing a log file, sending a notification), it fires for every tool call in every sub-agent too. Keep hooks idempotent.

Skipping /compact on long sessions. When context fills, Claude Code auto-compacts. You lose some nuance. Regular manual /compact calls give you control over when summarization happens.

What's next

Once your base config is dialed in, the next level is combining these primitives: a skill that spins up a sub-agent using the Explore agent to research before writing, hooks that validate output quality with a small model, and MCP servers that give Claude direct access to your database or issue tracker.

For the debugging side of AI-generated code, see how to debug AI-generated code. For a side-by-side on how Claude Code stacks up as a terminal tool versus IDE-first alternatives, the aider comparison covers where each shines.

The builders getting the most out of Claude Code are the ones who treat the config as part of the codebase — versioned, reviewed, and iterated on just like the application itself.