Set up Claude Code and use it every day

Verified with Claude Code 2.1.283 · macOS 27.0

1. 01Step 1: Install Claude CodeThe native installer keeps Claude Code up to date on its own.

   Run the official installer:

   curl -fsSL https://claude.ai/install.sh | bash

   Open a new terminal window with Cmd+N, then check the install. The first command prints the version, and the second checks your setup without starting a session.

   claude --version
   claude doctor

   Now start Claude Code inside a project folder. The first time, it opens your browser so you can sign in.

   cd ~/path/to/your/project
   claude

   Prefer Homebrew? This works too, but a Homebrew install does not update itself.

   brew install --cask claude-code

   Update a Homebrew install from time to time with:

   brew upgrade claude-code

2. 02Step 2: Start with a solid CLAUDE.mdStanding instructions that Claude reads at the start of every session, in every project.

   CLAUDE.md is a plain Markdown file of instructions that Claude Code loads at the start of every session. The copy in ~/.claude/CLAUDE.md applies to all your projects, and a CLAUDE.md inside a project applies to that project only.

   A popular starting point is a short file that GitHub user hqman shared as "Boris Cherny's CLAUDE.md". It has three parts:

   • Workflow:
     • Plan before any task with several steps, and stop to re-plan when something goes wrong.
     • Hand research to subagents, so the main conversation stays focused.
     • Record a lesson after every correction, so the same mistake does not happen twice.
     • Prove that the work runs before calling it done.
     • Look for the elegant fix on bigger changes, without over-engineering small ones.
     • Fix bugs from the logs and failing tests, without asking for hand-holding.
   • Task management: write the plan as a checklist in tasks/todo.md, check in before building, tick items off, summarize each change, and keep lessons in tasks/lessons.md.
   • Core principles: keep every change as simple and small as possible, and fix root causes instead of patching symptoms.

   Read the full text on GitHub Gist before you use it. This command backs up any CLAUDE.md you already have, then downloads the gist at a fixed revision, so the file cannot change under you later:

   mkdir -p ~/.claude
   [ -f ~/.claude/CLAUDE.md ] && cp ~/.claude/CLAUDE.md ~/.claude/CLAUDE.md.bak-$(date +%Y%m%d-%H%M%S)
   curl -fsSL https://gist.githubusercontent.com/hqman/e29cb6386c539d795767e8c3fd2c959b/raw/47e5cc85bfd4d051b080b7f12f80e549281e5a50/CLAUDE.md -o ~/.claude/CLAUDE.md

   Optionally, fix three typos that commenters on the gist pointed out. This edits only the copy you just downloaded:

   sed -i '' -e 's/Plan Node Default/Plan Mode Default/' -e 's/One tack per subagent/One task per subagent/' -e 's/Minimat Impact/Minimal Impact/' ~/.claude/CLAUDE.md

   The file is now yours, so edit it to fit how you work. Inside Claude Code, /memory lists your instruction files and opens them for editing, and /context shows which ones loaded into the current session. To create a CLAUDE.md for one project, run /init inside Claude Code in that project.

   If you use rtk, from the tools step below, run this afterwards, because the download replaced the @RTK.md line that rtk had added:

   rtk init -g

3. 03Step 3: Keep Claude grounded, surgical and simpleA standing prompt that makes Claude investigate before it diagnoses, verify before it claims, and keep every change small.

   Left to its defaults, Claude sometimes names a cause before it has looked, or writes more code than the task needs. This prompt sets the opposite habits: verify before claiming anything, investigate before diagnosing, and keep each change as small and readable as possible.

   # Working rules
   
   ## GROUNDING OVER GUESSING (strict)
   - Do not state a cause, file path, function, flag, config key, API, or behavior unless you have verified it in this session.
   - Verify by reading the code, running a command, or checking the official docs, and say which one you used.
   - If you have not verified something, say so plainly, and verify it before you act on it.
   - If the request is ambiguous and the code cannot answer it, ask one clear question instead of assuming.
   
   ## Investigate before you diagnose
   - Do not jump to a diagnosis from the symptoms alone.
   - Reproduce the problem first, as close to how the user experiences it as you can.
   - Read the code paths involved and the real error output, logs, or test failures.
   - Treat every early idea as a hypothesis: name the evidence that would confirm or rule it out, then check it.
   - Name a root cause only when the evidence shows it, and fix that cause, not the symptom.
   
   ## Make surgical, simple changes
   - Change only what the task needs: the smallest diff that fully solves the problem.
   - Do not refactor, rename, reformat, or "improve" code outside the task; mention it instead.
   - Follow the existing style, patterns, and naming of the surrounding code.
   - Add no new abstractions, layers, options, files, or dependencies unless the task needs them now.
   - Prefer plain, readable code over clever code; a few repeated lines beat a premature helper.
   - Comment only the why that the code cannot show.
   
   ## Prove it and report honestly
   - Run the relevant tests, build, or linter, and show the result.
   - Report what you changed and why, and list anything you could not verify.

   To try it in a single session, copy the prompt and paste it as your first message.

   To make it permanent, save it as a user rule. A rule without paths loads at the start of every session, in every project, just like CLAUDE.md. Keeping it in its own file also means it survives if you replace your CLAUDE.md later. This command backs up any rule with the same name first, then writes the file:

   mkdir -p ~/.claude/rules
   [ -f ~/.claude/rules/grounding.md ] && cp ~/.claude/rules/grounding.md ~/.claude/rules/grounding.md.bak-$(date +%Y%m%d-%H%M%S)
   cat > ~/.claude/rules/grounding.md <<'EOF'
   # Working rules
   
   ## GROUNDING OVER GUESSING (strict)
   - Do not state a cause, file path, function, flag, config key, API, or behavior unless you have verified it in this session.
   - Verify by reading the code, running a command, or checking the official docs, and say which one you used.
   - If you have not verified something, say so plainly, and verify it before you act on it.
   - If the request is ambiguous and the code cannot answer it, ask one clear question instead of assuming.
   
   ## Investigate before you diagnose
   - Do not jump to a diagnosis from the symptoms alone.
   - Reproduce the problem first, as close to how the user experiences it as you can.
   - Read the code paths involved and the real error output, logs, or test failures.
   - Treat every early idea as a hypothesis: name the evidence that would confirm or rule it out, then check it.
   - Name a root cause only when the evidence shows it, and fix that cause, not the symptom.
   
   ## Make surgical, simple changes
   - Change only what the task needs: the smallest diff that fully solves the problem.
   - Do not refactor, rename, reformat, or "improve" code outside the task; mention it instead.
   - Follow the existing style, patterns, and naming of the surrounding code.
   - Add no new abstractions, layers, options, files, or dependencies unless the task needs them now.
   - Prefer plain, readable code over clever code; a few repeated lines beat a premature helper.
   - Comment only the why that the code cannot show.
   
   ## Prove it and report honestly
   - Run the relevant tests, build, or linter, and show the result.
   - Report what you changed and why, and list anything you could not verify.
   EOF

   Start a new Claude Code session, run /context, and check that the grounding rule is listed under Memory files. To change the rules later, edit ~/.claude/rules/grounding.md in any text editor.

4. 04Step 4: Pick up where you left offContinue your last conversation, or choose an older one from a list.

   What it is: Claude Code saves every conversation, so you can reopen one later with its full history.

   When to use it: you closed the terminal, came back the next day, or want to return to an earlier task.

   Example: from the terminal, in the same project folder, continue the most recent conversation:

   claude -c

   Or open a list of past conversations to choose from:

   claude -r

   Inside a running session, the same list opens with:

   /resume

   In the list, use the arrow keys and press Enter to open a conversation, or start typing to search. Giving a conversation a name makes it easy to find, and /rename does that:

   /rename auth-refactor

   How to stop or exit: press Esc to close the list without choosing. To leave Claude Code itself, type /exit, or press Ctrl+D twice.

5. 05Step 5: Plan before Claude edits anythingClaude researches and writes a plan, and changes nothing until you approve it.

   What it is: in plan mode, Claude reads your files and explores, then writes a step-by-step plan. It does not edit your code until you approve the plan.

   When to use it: before any change that touches several files, or whenever you want to agree on the approach first.

   Example: type /plan followed by the task, and Claude starts planning right away:

   /plan add a dark mode toggle to the settings page

   You can also press Shift+Tab to cycle through the permission modes until the status bar shows ⏸ plan mode on, then type your request as usual. To start a whole session in plan mode, launch Claude Code like this:

   claude --permission-mode plan

   When the plan is ready, Claude asks whether to go ahead. Approving it leaves plan mode and Claude starts editing. Choose "No, keep planning" to tell Claude what to change first, or press Ctrl+G to edit the plan in your text editor.

   How to stop or exit: press Shift+Tab to leave plan mode without approving anything.

6. 06Step 6: Repeat a prompt on a timer with /loopHave Claude check on something again and again while your session stays open.

   What it is: /loop runs the same prompt over and over, either on a fixed interval or at a pace Claude picks.

   When to use it: to watch something that takes a while, such as a deploy, a long build, or new review comments on a pull request.

   Example: check on a deploy every 5 minutes:

   /loop 5m check if the deployment finished and tell me what happened

   Intervals use s, m, h or d for seconds, minutes, hours or days. Leave the interval out and Claude chooses how long to wait each time, between one minute and one hour, based on what it saw:

   /loop check whether CI passed and address any review comments

   Loops only run while this Claude Code session is open and idle, and a loop that runs on a fixed interval stops by itself after 7 days.

   How to stop or exit: while a self-paced loop waits for its next run, press Esc. For a loop on a fixed interval, ask Claude to cancel it:

   cancel the deploy check loop

   Starting a new conversation with /clear also removes every loop in the session.

7. 07Step 7: Keep Claude working toward a goalSet a finish line, and Claude keeps taking turns until it is reached.

   What it is: /goal sets a condition for when the work is done. After each turn, a small, fast model checks the conversation, and Claude keeps going on its own until that model judges the condition met, or impossible.

   When to use it: for bigger jobs with a clear, checkable end, such as getting a test suite green or finishing a migration.

   Example: write one measurable end state, say how Claude should prove it, and add a limit so it cannot run forever:

   /goal npm test exits 0 and no test files are deleted, or stop after 20 turns

   The goal starts working immediately, so you do not need to send another prompt. The checker only reads the conversation and never runs commands itself, so describe an end state that Claude's own output can show, such as a test result. A goal does not change your permission mode, so Claude still asks before actions that normally need your approval. Only one goal can be active at a time, and setting a new one replaces it.

   To see how it is going, including how many turns it has taken, run /goal on its own:

   /goal

   How to stop or exit: clear the goal before it finishes:

   /goal clear

   Starting a new conversation with /clear also removes the goal.

8. 08Step 8: Everyday commands and shortcutsThe short list of commands and keys worth learning first.

   Type / in Claude Code to see every command, and /help for help. These are the ones worth learning first.

   Manage the conversation. Everything in a conversation takes up room in Claude's context window, its working memory for the session. These commands keep that room under control.

   Command	What it does
   /clear	Start a new conversation with an empty context. The old one stays available in /resume. /reset and /new do the same.
   /compact	Summarize the conversation so far to free up space, and keep going. Add a focus, such as /compact keep the API decisions.
   /context	Show what is filling the context window, as a colored grid.
   /rewind	Go back to an earlier point and restore the code, the conversation, or both. Pressing Esc twice on an empty prompt opens the same menu.
   /btw	Ask a quick side question without adding it to the conversation.

   Choose how Claude works.

   Command	What it does
   /model	Pick the model, and save it as your default.
   /effort	Set how hard Claude thinks, from low up to max.
   /init	Write a starter CLAUDE.md for the current project.
   /memory	Open your CLAUDE.md files for editing.
   /permissions	See and change which tools Claude may use without asking.
   /config	Open the settings, such as theme and model.

   Review your changes.

   Command	What it does
   /diff	Show the changes in your working tree, including Claude's edits.
   /code-review	Review the current changes for bugs.
   /simplify	Look for cleanups in the changed code, and apply them.
   /security-review	Check the changes on your branch for security problems.

   Check on things.

   Command	What it does
   /usage	Show what this session cost and how much of your plan's limits you have used.
   /status	Show the version, model, account and connection.
   /doctor	Run a checkup of your install and settings, which can offer fixes.

   Keyboard shortcuts.

   Keys	What it does
   Esc	Stop Claude mid-answer so you can redirect it. The work done so far is kept.
   Shift+Enter	Start a new line without sending. It works in Ghostty as is, and inside tmux with the settings from the tmux guide. Ctrl+J works everywhere.
   ! at the start	Run a shell command yourself, such as !git status, and share its output with Claude.
   @	Mention a file by its path, with autocomplete.
   Shift+Tab	Cycle permission modes, including plan mode.
   Ctrl+O	Show the detailed transcript of what Claude did.
   Ctrl+R	Search the prompts you typed before.
   Ctrl+G	Write your prompt in your text editor.
   Ctrl+D twice	Exit Claude Code, like /exit.

9. 09Step 9: Teach Claude a reusable skillA skill is a folder with instructions that Claude loads when it needs them, or when you type its name.

   A skill is a SKILL.md file with a short description at the top and instructions below. Claude keeps only the description in mind until a task matches it, then loads the rest, so an unused skill costs just its short description. Where you save the folder decides where the skill works:

   • ~/.claude/skills/<name>/SKILL.md works in all your projects.
   • .claude/skills/<name>/SKILL.md works in one project, and for anyone you share the repository with.
   • A plugin's skills/ folder works wherever the plugin is turned on.

   This example from the Claude Code docs creates a skill that summarizes your uncommitted changes and flags anything risky. The !`git diff HEAD` line runs that command first and pastes its output into the instructions. The second line backs up an existing skill with the same name.

   mkdir -p ~/.claude/skills/summarize-changes
   [ -f ~/.claude/skills/summarize-changes/SKILL.md ] && cp ~/.claude/skills/summarize-changes/SKILL.md ~/.claude/skills/summarize-changes/SKILL.md.bak-$(date +%Y%m%d-%H%M%S)
   cat > ~/.claude/skills/summarize-changes/SKILL.md <<'EOF'
   ---
   description: Summarizes uncommitted changes and flags anything risky. Use when the user asks what changed, wants a commit message, or asks to review their diff.
   ---
   
   ## Current changes
   
   !`git diff HEAD`
   
   ## Instructions
   
   Summarize the changes above in two or three bullet points, then list any risks you notice such as missing error handling, hardcoded values, or tests that need updating. If the diff is empty, say there are no uncommitted changes.
   EOF

   Try it in a Git project that has some uncommitted edits. Either ask a question that matches the description, or type the skill's name:

   /summarize-changes

   /skills lists every skill Claude can see. If Claude Code was already running before you created ~/.claude/skills, run /reload-skills once so it notices the new folder.

10. 10Step 10: Create a subagent for focused jobsA helper with its own instructions, tools and context window, so side work stays out of your main conversation.

    A subagent is a Markdown file that describes a specialist, such as a code reviewer. Claude hands it a task, the subagent works in its own context window, and only its summary comes back to your conversation.

    Subagents live in ~/.claude/agents/ for all your projects, or .claude/agents/ for one project. Only name and description are required. Optional settings include tools to limit what it can use, model to pick a model, permissionMode, skills to preload, isolation: worktree to give it its own copy of the repository, and color.

    This creates a read-only code reviewer that runs on the Sonnet model, after backing up any file with the same name:

    mkdir -p ~/.claude/agents
    [ -f ~/.claude/agents/code-reviewer.md ] && cp ~/.claude/agents/code-reviewer.md ~/.claude/agents/code-reviewer.md.bak-$(date +%Y%m%d-%H%M%S)
    cat > ~/.claude/agents/code-reviewer.md <<'EOF'
    ---
    name: code-reviewer
    description: Reviews code for quality and best practices. Use after writing or changing code.
    tools: Read, Glob, Grep
    model: sonnet
    ---
    You are a senior code reviewer. Review the changed files for correctness, readability, and security. Report findings as a prioritized list with file and line references.
    EOF

    Ask for it by name:

    Use the code-reviewer subagent to review my changes

    To make sure that exact subagent runs, type @, pick code-reviewer (agent) from the list, and add your request.

    Since version 2.1.198, /agents no longer opens an editor. Edit the files yourself, or ask Claude to write one for you. Claude Code notices new and changed files within a few seconds, but if ~/.claude/agents did not exist when the session started, restart Claude Code once.

11. 11Step 11: Add rules for parts of your codeSmall instruction files that can load only when Claude works on matching files.

    Rules split your instructions into small topic files instead of one long CLAUDE.md. They live in .claude/rules/ for one project, or ~/.claude/rules/ for all your projects.

    • A rule without paths loads at the start of every session, like CLAUDE.md.
    • A rule with paths loads only when Claude reads a file that matches one of its patterns, which saves room in the context window.

    Run this in a project's root folder to add a rule for its API code. It backs up any rule file with the same name first.

    mkdir -p .claude/rules
    [ -f .claude/rules/api.md ] && cp .claude/rules/api.md .claude/rules/api.md.bak-$(date +%Y%m%d-%H%M%S)
    cat > .claude/rules/api.md <<'EOF'
    ---
    paths:
      - "src/api/**/*.ts"
    ---
    
    # API Development Rules
    
    - All API endpoints must include input validation
    - Use the standard error response format
    - Include OpenAPI documentation comments
    EOF

    The pattern src/api/**/*.ts matches every TypeScript file under src/api, at any depth. Commit .claude/rules/ so everyone on the project gets the same rules.

12. 12Step 12: Automate actions with hooksShell commands that run at set moments, such as when Claude needs your attention or after it edits a file.

    A hook is a shell command that Claude Code runs at a certain moment, every time, without Claude having to remember. Hooks live in a hooks block in ~/.claude/settings.json, grouped by event name.

    In Ghostty, Claude Code already shows a desktop notification when it needs you. This example adds a sound as well, using the Notification event. It uses jq to merge the hook into your existing settings safely, backs the file up first, and skips everything if the hook is already there.

    brew install jq
    mkdir -p ~/.claude
    f=~/.claude/settings.json
    [ -f "$f" ] || echo '{}' > "$f"
    if ! grep -q 'Glass.aiff' "$f"; then
      cp "$f" "$f.bak-$(date +%Y%m%d-%H%M%S)"
      jq '.hooks.Notification += [{"matcher": "", "hooks": [{"type": "command", "command": "afplay /System/Library/Sounds/Glass.aiff"}]}]' "$f" > "$f.tmp" && mv "$f.tmp" "$f"
    fi

    Type /hooks in Claude Code to see your hooks. That screen is read-only, so to change a hook, edit ~/.claude/settings.json or ask Claude to do it.

    To test the sound, press Shift+Tab until the status bar shows ⏸ manual mode on, ask Claude to do something that needs your permission, then switch to another app.

    Two more hooks from the Claude Code docs, to adapt as you like. The first shows a macOS notification in terminals that do not send one on their own:

    {
      "hooks": {
        "Notification": [
          {
            "matcher": "",
            "hooks": [
              {
                "type": "command",
                "command": "osascript -e 'display notification \"Claude Code needs your attention\" with title \"Claude Code\"'"
              }
            ]
          }
        ]
      }
    }

    The second runs Prettier on every file Claude edits or writes, in a project's .claude/settings.json:

    {
      "hooks": {
        "PostToolUse": [
          {
            "matcher": "Edit|Write",
            "hooks": [
              {
                "type": "command",
                "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
              }
            ]
          }
        ]
      }
    }

    If a settings file already has a hooks block, add the new event next to the existing ones instead of replacing the whole block.

13. 13Step 13: Install pluginsAdd bundles of skills, subagents and hooks that other people publish, in two steps.

    A plugin bundles skills, subagents, hooks or MCP servers so you can install them together. Plugins come from a marketplace, which is usually a GitHub repository, so installing one takes two steps: add the marketplace, then install the plugin from it.

    Inside Claude Code, send these as two separate prompts, replacing owner/repo and name@marketplace:

    /plugin marketplace add owner/repo

    /plugin install name@marketplace

    Or do both from the terminal in one line, again replacing the placeholders:

    claude plugin marketplace add owner/repo && claude plugin install name@marketplace

    A plugin's commands have a full name that starts with the plugin's name, such as /caveman:caveman. The / menu finds them by their short name too, and the short name works on its own as long as no other command uses it.

    To manage plugins from the terminal, first list the ones you have:

    claude plugin list

    See what a plugin contains, replacing name with a name from that list:

    claude plugin details name

    Update a plugin, then restart Claude Code to use the new version:

    claude plugin update name

    Remove a plugin:

    claude plugin uninstall name

    Review before installing. A plugin can run code on your machine: its hooks run shell commands automatically, and its skills can run commands when they are used. Read the plugin's repository before you install it, and after installing, claude plugin details lists the skills, agents, hooks and servers it added.

14. 14Step 14: caveman: shorter answersoptionalMakes Claude answer in terse caveman-speak to use fewer tokens, without shortening code or error messages.

    caveman changes how Claude talks, not what it writes: replies drop the filler, while code, commands and exact error messages stay intact. Its hooks run with Node.js. The first line installs Node with Homebrew only if it is missing, and the second installs the plugin.

    node --version || brew install node
    claude plugin marketplace add JuliusBrussee/caveman && claude plugin install caveman@caveman

    Choose how terse Claude gets, from lite to ultra, where full is the default:

    /caveman lite

    Turn it off again:

    /caveman off

    Saying "stop caveman" or "normal mode" also works. It comes with a few more commands:

    • /caveman-commit writes a short commit message.
    • /caveman-review reviews code with one finding per line.
    • /caveman-compress CLAUDE.md shrinks a memory file and backs up the original first.

    The project also offers an optional caveman command line proxy that compresses what Claude reads. Review before installing it: unlike the plugin, that proxy sends anonymous usage statistics by default. If you install it, turn them off:

    caveman telemetry off

15. 15Step 15: ponytail: simpler codeoptionalPushes Claude toward the smallest solution that works, without cutting validation, error handling or security.

    ponytail puts a "lazy senior developer" in Claude's ear: use what the platform or standard library already has, skip features nobody asked for, and write one line instead of fifty. Its two hooks run with Node.js, so node must be on your PATH. Without it, the commands still work, but the always-on mode stays off. This installs Node with Homebrew only if it is missing:

    node --version || brew install node

    Then, inside Claude Code, send these as two separate prompts:

    /plugin marketplace add DietrichGebert/ponytail

    /plugin install ponytail@ponytail

    Set how strict it is with lite, full or ultra, or turn it off. full is the default, and /ponytail on its own shows the current level.

    /ponytail lite

    It also adds these commands:

    • /ponytail-review reviews your current changes for over-engineering and hands back a list of things to delete.
    • /ponytail-audit does the same for the whole repository.
    • /ponytail-debt collects the shortcuts marked for later into one list.
    • /ponytail-gain shows the project's benchmark results.
    • /ponytail-help is a quick reference.

    To start every session at a different level, set PONYTAIL_DEFAULT_MODE. This adds it to ~/.zshrc only if it is not there yet:

    grep -q 'PONYTAIL_DEFAULT_MODE' ~/.zshrc || echo 'export PONYTAIL_DEFAULT_MODE=lite' >> ~/.zshrc

16. 16Step 16: rtk: smaller command outputoptionalTrims the output of commands like git status and test runs before Claude reads it, which saves tokens.

    rtk, short for Rust Token Killer, is a command line proxy that filters noisy output down to what matters. A hook rewrites Claude's shell commands for you, so git status quietly becomes rtk git status.

    Install it with Homebrew:

    brew install rtk

    Review before setting it up. Setup changes three files in ~/.claude: it adds a hook to settings.json, writes an RTK.md guide, and adds an @RTK.md line to your CLAUDE.md that loads it. Preview those changes without writing anything:

    rtk init -g --dry-run

    Then run the setup for real. When it asks to patch settings.json, type y and press Enter.

    rtk init -g

    Restart Claude Code, then check that everything is in place and see how much it has saved:

    rtk init --show
    rtk gain

    A few things to know:

    • The hook only rewrites shell commands, so Claude's built-in Read, Grep and Glob tools are not filtered.
    • A different program called Rust Type Kit also installs as rtk, but the Homebrew package is the right one, and if rtk gain fails, you have the other one.
    • Its anonymous usage statistics are off unless you opt in.
    • If you replace your CLAUDE.md later, run rtk init -g again to put the @RTK.md line back.

    To remove it again:

    rtk init -g --uninstall

17. 17Step 17: brag: a launch video of your projectoptionalTurns the project you built into a short, shareable video with music, motion and share copy.

    brag reads your project's code and makes a short launch video for it. It needs Node.js 22 or later and FFmpeg. Install them with Homebrew if you do not have them yet, then check that the Node version starts with 22 or higher:

    brew install node ffmpeg
    node --version

    Inside Claude Code, send these as two separate prompts:

    /plugin marketplace add latent-spaces/brag

    /plugin install brag@brag

    In any project folder, ask for a video:

    let's /brag

    The result lands in a brag-output/ folder, with the plan, the share copy and the finished brag.mp4. Voiceover is off unless you ask for it with /brag --voice, and /brag --tone sets the mood, as in this example:

    /brag --tone "fake Series A launch from 2016"

    The plugin includes two versions. /brag-slim builds the video with the tools already on your machine. The classic /brag renders through Hyperframes, and on Claude Opus 5.5 it switches to /brag-slim automatically unless you run /brag --full.

    Review before using the classic version: Hyperframes is a separate tool that npx downloads and runs. Check that it is ready with:

    npx hyperframes doctor

18. 18Step 18: headroom: compressed contextoptionalCompresses large tool output before it reaches Claude, and keeps the originals on hand in case Claude needs them.

    headroom shrinks what coding agents read, such as long logs and file listings, and stores the originals locally so Claude can fetch the full text when it needs it.

    Review before installing. headroom sends an anonymous "beacon" by default, with compression ratios, model names and your OS, but never your prompts, code or file paths. To turn it off, add this setting to ~/.zshrc, only if it is not there yet. It takes effect in new terminal windows.

    grep -q 'HEADROOM_BEACON' ~/.zshrc || echo 'export HEADROOM_BEACON=off' >> ~/.zshrc

    Install the command line tool with uv, a Python tool installer:

    brew install uv
    uv tool install --python 3.13 "headroom-ai[all]"
    headroom --version

    If your shell cannot find headroom, add uv's tool folder to your PATH, then open a new terminal window:

    uv tool update-shell

    Connect it to Claude Code as an MCP server, which gives Claude tools to compress and retrieve content on demand:

    headroom mcp install --agent claude

    If you would rather add the server by hand, this command does the same thing, for all your projects:

    claude mcp add -s user headroom -- headroom mcp serve

    Check that the server is connected, or run /mcp inside Claude Code:

    claude mcp list

    The MCP server only compresses when Claude asks it to. To compress everything automatically, start Claude Code through headroom's local proxy instead. That wrapper also installs a code navigation server called Serena for all your projects, and --code-memory none skips it:

    headroom wrap claude --code-memory none

    Undo the wrapper's changes with:

    headroom unwrap claude