Claude Code — The Terminal Craft.

Why Claude in the terminal.

A chat window is a place to think. The terminal is where engineering happens. Claude Code is what you reach for when you want the model to operate at the level your code does.

Three differences from the chat app worth naming:

• It lives where your work lives. The CLI runs in the directory of your project. It reads the repo. It runs your tests. It commits.
• It is automatable. Slash commands, hooks, plugins, and MCP servers turn one-time prompts into reusable patterns.
• It is a teammate, not a tool. Plan mode, subagents, and TaskCreate let Claude do multi-step work the way a senior engineer does — investigate, plan, dispatch parallel work, verify.

Validated against official Claude Code docs: it reads codebases, edits files, runs commands, integrates with development tools, and supports terminal, IDE, desktop, and browser surfaces. Source: Claude Code overview.

Install & first run.

Install once. Authenticate once. Then claude from any project directory drops you in.

Prereq: Claude Code requires a Pro, Max, Team, Enterprise, or Console account. The free Claude.ai plan is enough for Monday Setup, but not for this practice.

macOS / Linux / WSL

Copy# Native installer, recommended
curl -fsSL https://claude.ai/install.sh | bash
claude    # opens a browser to authenticate

macOS alternative

Copybrew install --cask claude-code
brew upgrade claude-code    # Homebrew installs do not auto-update

Windows

Copy# PowerShell
irm https://claude.ai/install.ps1 | iex
claude

Then, from any project

Copycd ~/Code/my-project
claude

You’ll get a prompt. Type a question, press enter, watch Claude work. Press Esc at any time to stop. Press Shift+Tab to switch between modes.

The CLAUDE.md file.

A markdown file at the root of your project. The most important file in Claude Code. Everything in it goes into Claude’s context at the start of every session.

Use it for: the project’s domain, how to run tests, the conventions you actually want enforced, the layout of important folders, things the model would otherwise have to guess at.

Copy# CLAUDE.md

## What this repo is
A practice site teaching working professionals to use Claude. Static HTML, no build step.

## How to run it
Open index.html in a browser. Or `python3 -m http.server` from the root.

## Conventions
- HTML/CSS uses the Pradhya design system in assets/css/main.css.
- All JS uses createElement / textContent — never innerHTML (XSS).
- Brand voice: claim-first, no hype words (leverage / robust / transformative).

## Layout
- /index.html          — multi-practice hub
- /workshops/*.html    — individual practice pages
- /days/day{1..4}.html — Capable Series day pages
- /agents/*.py         — runnable Python scripts
- /assets/             — shared CSS and JS

## Do not
- Add a build step.
- Pull in JavaScript frameworks.
- Write 'leverage' or 'unlock'.

Onboarding with /init.

Don’t write CLAUDE.md from scratch. Run /init and let Claude read your repo and propose one.

Copy$ claude
> /init

Claude explores the repo, infers the language and frameworks, finds your test command, and proposes a CLAUDE.md. You edit it before accepting. The first time it’s right about ~70% of conventions; you fill in the rest.

The other useful first-week commands

• /help — list every command available.
• /config — model, theme, status line.
• /memory — durable preferences across sessions.
• /review — review uncommitted changes.
• /clear — start a fresh conversation.

Plan mode.

For any change bigger than a one-line fix, enter Plan mode first. Claude investigates, thinks, and proposes a plan — without touching the code. You approve. Then it executes.

Enter plan mode with Shift+Tab twice (cycles through Auto → Plan → AcceptEdits). Or any prompt that starts with “plan” or “design” will trigger it.

Copy> [plan mode]
Plan how to add a dark-mode toggle to this practice site.
- Read the CSS to see how color tokens are defined.
- Identify which surfaces need dark variants.
- Propose the toggle's location and behavior.
- Suggest where the preference should be stored.
Do not touch any files yet.

Plan mode is read-only. Claude can look at anything, but cannot edit until you exit plan mode and approve the plan. This is the difference between a senior engineer and an over-eager intern.

Slash commands.

A slash command is your own prompt, named, versioned, in your repo. Write the prompt once, call it from any session.

Put them in .claude/commands/ in your repo (project-scoped) or ~/.claude/commands/ (user-scoped).

A working example: /audit-typescript

Copy---
description: Audit TypeScript files for `any` usage and missing null checks.
allowed-tools: [Bash, Read, Grep]
---

# Audit TypeScript hygiene

You are a senior TypeScript engineer reviewing this codebase for type-safety hygiene.

Steps:
1. Find every `: any` and `as any` in `src/**/*.ts`.
2. For each one, decide if it is justified (escape hatch for a known limitation) or accidental.
3. Find every `!.` (non-null assertion) and verify the line above it actually guarantees non-null.
4. Produce a markdown table: file | line | severity (low/med/high) | suggested fix.

No preamble. Just the table.

Then in any session: /audit-typescript. Claude reads the prompt, follows the steps, and outputs the table. The exact file above ships with this practice — download audit-typescript.md (right-click → Save As) and drop it in .claude/commands/ to use it verbatim. You’ll bundle this same command into a plugin in Unit 11.

Slash commands accept arguments ($1, $ARGUMENTS), can include bash with !`...`, and can reference files with @path/to/file. The full spec is in the official docs.

Hooks.

A hook is a shell command (or prompt) the harness runs in response to an event — before a tool call, after one, on session start, etc. This is where you enforce your conventions.

Events worth hooking

Example: block npm install of unknown packages

Copy# .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/check-package.sh"
          }
        ]
      }
    ]
  }
}

# The script reads the tool call as JSON from stdin:
#   command=$(jq -r ".tool_input.command")
#   if [[ "$command" == "npm install"* ]]; then ... ; fi
# Exit 0 to allow, exit 2 to block (with stderr message).

The script reads the tool-call payload as JSON on stdin (use jq to parse). Exit 0 to allow the action, exit 2 with stderr to block. Hooks are how you turn “rules I keep typing into every conversation” into actual guardrails.

The complete, working script above ships with this practice: download check-package.sh (right-click → Save As). It blocks npm install <pkg> whenever the package is not already in package.json or on a .claude/allowlist.txt — forcing the change into a reviewable diff. You’ll reuse this exact hook inside the plugin in Unit 11.

Output styles.

An output style changes how Claude communicates — tone, length, format — without changing what it does. A persistent persona for the session.

Built-in styles include explanatory (educational, with insights), learning (interactive, asks you to write some code), and the default. You can write your own under .claude/output-styles/.

Copy$ claude
> /output-style explanatory

# from now on, Claude will explain its choices as it works

Output styles are good for: pair-programming sessions where you want to learn, demos where the audience is watching, and reviews where the reasoning matters more than the diff.

Subagents in parallel.

A subagent is a separate Claude instance, dispatched from the main one, with its own conversation and its own tools. Use them for independent work that can run in parallel.

Two scenarios where subagents earn their cost:

• Independent investigation. “Find every place we use feature X” can dispatch 5 subagents over 5 directories, each searching in parallel. The main agent gets the summaries back, not the raw output.
• Isolation. A subagent with its own context window can do exploratory work without polluting the main agent’s context. The main agent only sees the conclusion.

Copy# In the main session
> Use 3 subagents in parallel:
>   1. one searching src/ for any TODO comments older than 6 months
>   2. one auditing package.json for outdated dependencies
>   3. one looking for tests that haven't run in CI in the last month
> Each returns a 5-bullet summary. Combine into one report.

Memory and preferences.

Memory is the system that lets Claude remember things across sessions. Use it for the preferences and corrections that should not have to be repeated.

Memory entries are typed:

• user — who you are, your role, your knowledge.
• feedback — corrections and validations of approach.
• project — in-progress work, goals, decisions.
• reference — pointers to external systems (where Linear tickets live, etc.).

Copy> Remember: I prefer terse responses with no trailing summaries.
> Remember: for this repo, tests live in /tests not /__tests__.

The next session, Claude reads the relevant memories before it starts. Use memory to stop repeating yourself; use CLAUDE.md for things that belong with the repo.

Plugins.

A plugin bundles slash commands, hooks, agents, and skills into one package. The shape of every Claude Code customization that ships beyond your laptop.

The plugin layout

The manifest lives in a .claude-plugin/ folder; the component directories sit at the plugin root, where Claude Code auto-discovers them. You only create the folders you actually use.

Copypradhya-review/
├── .claude-plugin/
│   └── plugin.json       # manifest — MUST be inside .claude-plugin/
├── commands/             # slash commands (auto-discovered)
│   └── audit-typescript.md
├── hooks/
│   └── hooks.json        # event handlers
├── check-package.sh      # the hook script hooks.json points at
└── agents/               # (optional) subagents this plugin defines

The manifest

Just metadata — no components block. Claude Code finds commands/ and hooks/ by convention. This is the exact plugin.json that ships with this practice:

Copy{
  "name": "pradhya-review",
  "version": "0.1.0",
  "description": "Pradhya-flavored hooks + slash commands for AI workshop content. Use to enforce house style in repos that follow the Pradhya voice guide.",
  "author": {
    "name": "Pradhya",
    "url": "https://pradhya.studio"
  },
  "license": "MIT",
  "keywords": ["claude-code", "code-review", "typescript", "linting", "style-guide"]
}

The hook wiring

The plugin’s hooks/hooks.json registers the PreToolUse hook from Unit 07 against every Bash call. The shipped hooks.json uses a bare ./check-package.sh — right for the standalone .claude/ setup in Unit 07. Inside a plugin, point at the script with ${CLAUDE_PLUGIN_ROOT} so it resolves no matter which project the plugin is installed into:

Copy{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "${CLAUDE_PLUGIN_ROOT}/check-package.sh" }
        ]
      }
    ]
  }
}

Install it the way W10 teaches: a local marketplace

Claude Code installs plugins from marketplaces — a folder (or repo) with a .claude-plugin/marketplace.json listing one or more plugins. Point one at your local plugin, then install by name@marketplace, exactly the syntax from Power Patterns → Plugins as installable packages.

Copy# In Claude Code, register the folder that holds your plugin as a marketplace:
/plugin marketplace add ./pradhya-review

# Then install your plugin from it (name@marketplace):
/plugin install pradhya-review@pradhya-review

# Quicker for a throwaway test — load the folder directly, no marketplace:
#   claude --plugin-dir ./pradhya-review

MCP servers.

The Model Context Protocol lets Claude talk to external systems through a standard interface. Write one MCP server, and every Claude app — chat, Cowork, Code — can use it.

An MCP server exposes:

• Tools — functions Claude can call (read a Slack message, query a database).
• Resources — data Claude can read (a Notion page, a row in Postgres).
• Prompts — reusable templates the user can pick from.

MCP servers are usually small Python or TypeScript programs. The official SDK does most of the work. Here’s the smallest possible MCP server in Python:

Copy# weather_mcp.py
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather")

@mcp.tool()
def get_weather(city: str) -> str:
    """Get the current weather for a city."""
    # imagine a real API call here
    return f"{city}: 102F, sunny"

if __name__ == "__main__":
    mcp.run()

Wire it up in Claude Code via .mcp.json at the project root. Now every session in this repo can call get_weather. The same server can be wired into Claude Desktop (Cowork) with no changes — one protocol, many surfaces.

Fast mode and effort.

Two knobs that change how Claude trades off speed against quality. Reach for them when the default isn’t the right shape.

Fast mode

Trades a bit of reasoning depth for noticeably faster responses. Available on Opus 4.6+. Good for: short interactive turns, chat-like back-and-forth, anything where wall-clock latency matters more than the last 5% of quality.

Copy> /fast

Effort levels

Effort controls how much computation Claude spends on each turn. Higher effort = more careful work, more cost, slower turns. Lower effort = quicker, cheaper, looser. Set per-session.

Copy> /effort max     # for the hard ones
> /effort medium  # the default
> /effort low     # quick edits

Use max when the cost of being wrong is high. Use low when you’re iterating fast on small changes.

Going deeper: Power Patterns → Effort & fast mode compares diffs across effort levels and covers the “strong model + high effort to plan, fast model to execute” combo.

Real workflow: feature development.

A realistic feature-dev session, end to end. The pattern that turns Claude Code from a typing aid into a collaborator.

1. Worktree. /worktree or git worktree add ../feature-X feature-X. Isolate from main.
2. Plan. Shift+Tab Shift+Tab. Describe the feature. Read the plan carefully. Push back where it’s wrong.
3. Dispatch. Exit plan mode. Let Claude implement. For multi-file changes, ask it to use TaskCreate to track its own steps.
4. Verify. npm test or pytest. Read the diff with /diff or git diff. Don’t merge what you didn’t read.
5. Critique. /review dispatches a fresh subagent to review the diff with no context bias.
6. Commit. Claude can write the commit message — but you write the PR description. The model knows the diff; you know why it matters.

Real workflow: PR review.

A multi-agent PR review pipeline that catches the things humans miss. Six specialized agents, one orchestrator, one report.

Each agent focuses on a single failure mode. They run in parallel against the diff. The orchestrator merges their reports, drops duplicates, and ranks by severity.

Wire it up as a slash command plus six agent files (the /ultrareview pattern). Each agent is one markdown file in agents/. The orchestrator is a single slash command that dispatches them in parallel and aggregates results. The complete pack ships with this practice — the orchestrator ultrareview.md, the six agents (security, performance, tests, types, comments, simplify), and the README with copy-paste install steps.

Copy$ claude
> /ultrareview
# dispatches 6 agents in parallel against the current diff
# returns a ranked report of issues, with confidence scores

The shape generalizes: every quality gate worth automating is one specialized agent. The orchestrator is what makes the team feel like a team.