My Exact Claude Code Setup: Plugins, Skills, and Config

Developer setups are the most-shared posts in programming communities. Every dotfiles repo, every "uses" page, every screenshot of someone's terminal gets engagement because we're all looking for the same thing: what do people who are productive actually use? This post is my version of that, but for Claude Code.

I've been running Claude Code daily for months. Over that time, I've built up a configuration that handles everything from code reviews to grocery planning. This isn't theoretical. This is what's on my machine right now, what I open every morning, and what I've refined through actual use. I'm going to walk through the entire thing.

The .claude/ Directory

Everything lives in ~/.claude/. If you haven't looked inside yours, go do that now. Mine has grown into a small ecosystem.

Here's the top-level structure:

Copy.claude/
  settings.json          # Global configuration
  settings.local.json    # Machine-specific overrides
  commands/              # Custom slash commands
  skills/                # 23 custom skills
  plugins/               # 19 installed plugins
  hooks/                 # Automation scripts
  statusline-command.sh  # Custom status bar script

Each of these deserves its own section. Let's go through them.

settings.json is the global config file. It controls permissions, environment variables, feature flags, and default behavior. This is where the real opinions live, and I'll break it down later in the post.

settings.local.json handles machine-specific overrides. I use different machines for different contexts, and some paths and tokens differ between them. This file stays out of version control.

commands/ holds my custom slash commands. I have 27 GSD (Get Stuff Done) methodology commands plus a handful of standalone ones: /reflect, /audit, /critique, /init, /status, and /extract. These are the verbs I use most often. Each one is a markdown file that defines the prompt, context, and behavior for that command. If you're not using custom commands yet, this is the single highest-leverage customization you can make.

skills/ contains 23 custom skills. Skills are reusable workflows defined in markdown files. No build step. No compilation. Just a markdown file with frontmatter that tells Claude Code when and how to use it. More on these below.

plugins/ has 19 installed plugins. These extend Claude Code's capabilities with new tools, MCP servers, and slash commands. This is where most of the power comes from.

hooks/ holds automation scripts that run at specific lifecycle points. Mine triggers a GSD update check on session start.

statusline-command.sh is a shell script that feeds session information into my terminal status bar. Small thing, but it keeps me aware of what Claude Code is doing without switching windows.

The Plugin Stack

Nineteen plugins. That sounds like a lot. It is a lot. But each one is there for a reason, and I've removed plenty of others that didn't earn their place. Here's the full list with what each one does and why I keep it around.

superpowers-extended-cc

This is the centerpiece. I covered it in depth in the Superpowers and GSD post. It adds structured workflows for brainstorming, plan writing, plan execution, code review, test-driven development, and debugging. When I start a new feature, I don't just ask Claude Code to build it. I use Superpowers to think through the problem first, generate a plan, then execute the plan step by step. The difference in output quality is significant.

I originally used the base superpowers plugin. I disabled it in favor of superpowers-extended-cc, which is a fork with additional workflows and better prompting. The original still works fine. I just found the extended version matches how I think more closely.

claude-mem

Persistent cross-session memory, which I dedicated an entire post to. This is the one I'd keep if I could only keep one plugin. By default, Claude Code forgets everything between sessions. claude-mem fixes that by storing observations, lessons, and context in a searchable database. When I start working on a frontend component, it surfaces the design system lessons I learned three weeks ago. When I hit a bug in a specific library, it reminds me of the workaround I found last time.

It has three core capabilities: save_observation to store something, search to find past observations, and timeline to see recent activity. Simple interface, huge impact. I've written about this in more detail in the series intro.

pr-review-toolkit

This one runs parallel multi-agent PR reviews. When I submit a PR, it doesn't just do a single review pass. It spawns multiple agents in parallel, each focused on a different dimension: code quality, silent failure detection, type safety, test coverage, and comment quality. The results get aggregated into a single review.

It's slower than a single-pass review. It also catches things that a single pass misses, every time. The tradeoff is worth it for anything going to production.

ralph-loop

Autonomous development loops. You give it a task, and it works on it continuously, sometimes for hours, without intervention. It plans, executes, tests, and iterates. I use this for large refactoring tasks or when I need to build something substantial and don't want to babysit the process.

I wrote a full post on how Ralph Loop works, including the safety mechanisms and when to avoid it. The plugin is genuinely useful for anything that takes more than 30 minutes of sustained work.

commit-commands

Three commands: commit, commit-push-pr, and clean_gone. The first two are self-explanatory and save a surprising amount of time by automating the git workflow. clean_gone cleans up local branches that have been merged and deleted on the remote. Small utility, big quality-of-life improvement.

code-review

Post-implementation code review against project standards. After I finish building something, I run this to check the output against the design system rules, coding conventions, and patterns defined in the project's CLAUDE.md. It catches deviations that I miss because I'm too close to the code.

code-simplifier

Automated simplification of recently modified code. After a coding session, especially one with multiple iterations, code tends to accumulate unnecessary complexity. Functions that could be combined. Abstractions that don't earn their weight. This plugin identifies and proposes simplifications.

I don't accept every suggestion. Maybe half of them. But the ones I do accept make the code meaningfully better.

github

GitHub integration for issues and PRs. This connects Claude Code to the GitHub API so I can create issues, manage PRs, and interact with repositories without leaving the terminal. It's not flashy. It's plumbing. Good plumbing matters.

typescript-lsp

TypeScript language server integration. This gives Claude Code real type information, not just what the model infers from reading source files. It can check types, find references, and navigate the type hierarchy the way a TypeScript-aware editor would. The accuracy improvement for TypeScript projects is noticeable.

rust-analyzer-lsp

Same idea, but for Rust. I don't write Rust daily, but when I do, having the language server available means Claude Code understands ownership, lifetimes, and trait implementations correctly instead of guessing.

playwright

Browser automation via MCP. I use this for two things: testing web applications and automating web-based tasks. My grocery planning skill uses Playwright under the hood to interact with the Wegmans website. My calorie tracker uses it when it needs to look something up. Having a browser that Claude Code can control programmatically opens up a category of tasks that would otherwise require manual clicking.

slack

Read and send Slack messages from the terminal. I can check channels, read threads, search messages, and send replies without opening the Slack app. This sounds minor until you realize how much context-switching the Slack app causes. Staying in the terminal keeps me in flow.

context7

Documentation lookup MCP server. When Claude Code needs to reference documentation for a library or framework, context7 provides up-to-date docs. This is particularly useful for libraries that have changed significantly since the model's training cutoff.

frontend-design

High-quality frontend code generation. This plugin adds structured prompts and patterns specifically for building user interfaces. It understands component hierarchies, responsive design, accessibility, and modern CSS. The output quality for frontend work is noticeably better than prompting the base model directly.

feature-dev

Feature development workflows. This structures the process of going from a feature idea to implemented code. It handles requirements gathering, architecture decisions, implementation planning, and execution as a structured flow rather than a single prompt.

ui-ux-pro-max

Fifty design styles, color palettes, font pairings, and layout patterns. When I need to design something and I don't have a specific visual direction in mind, this plugin gives me options. It's a design system reference library that Claude Code can draw from when making visual decisions.

claude-code-setup

Automation recommender for new projects. When I start a new project, this plugin analyzes the codebase and suggests Claude Code configurations, custom commands, and CLAUDE.md content tailored to that specific project. It's the bootstrapping tool for everything else.

claude-notifications-go

Native macOS notifications when agents finish. When I kick off a long-running task with ralph-loop or a multi-agent review, I switch to something else. This plugin sends a system notification when the work is done. Simple. Essential.

superdesign

Design agent for UI/UX thinking. Before I implement a frontend feature, I use superdesign to think through the interaction design, visual hierarchy, and component structure. It's the "think before you build" step, formalized as a plugin.

The Skills

Twenty-three skills, grouped by what they do. Skills are Claude Code's most underappreciated feature. A skill is just a markdown file with frontmatter that defines when it should be used, what context it needs, and how to execute a workflow. No build step, no compilation, no npm install. Write a markdown file, put it in the skills directory, and Claude Code can use it.

Here's what I have.

Coding and Design

superdesign handles the design thinking step before implementation. frontend-design generates high-quality frontend code. premium-web-animations provides animation patterns and implementation guidance. logo-generator creates logo concepts and SVG implementations. presentation-chef builds slide decks from content outlines. theme-factory generates complete design themes. vibe-security does security auditing with a practical focus. interface-design provides UI component design patterns.

These skills work together. I'll use superdesign to plan a feature, frontend-design to implement it, premium-web-animations to add motion, and theme-factory to ensure it matches the project's visual language. They compose.

Life Automation

This is the category that gets the most questions. Yes, I use Claude Code for things that aren't coding.

calorie-tracker is the most complex skill I've built. It uses the FatSecret API, the USDA nutrition database, and Claude's vision capabilities to track what I eat. I take a photo of my meal, Claude identifies the food, looks up nutrition data from multiple sources, stores it in a SQLite database, and syncs the daily summary to my Obsidian notes. It's not perfect. It's better than any calorie tracking app I've tried, because I can just talk to it in natural language instead of searching through a database of foods.

grocery-planning automates my weekly grocery run. It takes my meal plan for the week, generates a shopping list, and uses Playwright to check availability and prices on the Wegmans website. It groups items by store section. It's a Playwright automation skill running through Claude Code, and it saves me about 30 minutes every week.

boston-date-planner is weather-aware restaurant and activity planning. It checks the weather forecast, cross-references with restaurant availability, and suggests date plans. It uses multiple APIs: weather, Google Places, Yelp. Overkill for picking a restaurant. But it works well and I enjoy using it.

youtube-downloader does what the name says. Downloads YouTube videos. Sometimes I need offline access to a conference talk or tutorial. This skill handles the yt-dlp workflow.

Knowledge Management

notebooklm lets me query Google NotebookLM from the terminal. I use NotebookLM for research synthesis, and being able to query it without switching to a browser keeps me in flow.

obsidian-markdown and obsidian-bases are skills for interacting with my Obsidian vault. They can create notes, update existing ones, and manage the metadata that Obsidian uses for its databases feature. My calorie tracker writes to Obsidian through these skills.

Design System

init, audit, critique, extract, and status form a design system management toolkit. init bootstraps a design system for a new project. audit checks existing code against the design system rules. critique provides detailed feedback on design system compliance. extract pulls design tokens from existing code. status gives me a dashboard of the current design system health.

These aren't flashy. They enforce consistency. On a project that's been running for months, consistency is what keeps the codebase from becoming a mess.

settings.json Explained

The global configuration file is where the real opinions live. Here are the key choices and why I made them.

Environment Variables

Copy"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"

This enables multi-agent teams, which allows Claude Code to spawn subagents for parallel work. It's experimental. It's also one of the most powerful features available. The PR review toolkit depends on it. Ralph-loop depends on it. Any workflow where you want multiple agents working simultaneously needs this flag.

Git Attribution

Copy"includeCoAuthoredBy": false,
"gitAttribution": false

I don't add "Co-authored-by: Claude" to my commits. I don't use git attribution for AI-generated code. This is an opinionated choice. My reasoning: I review every line of code that gets committed. I take responsibility for it. The commit is mine. The tool helped me write it, the same way my editor, my linter, and my type checker help me write it. I don't credit those tools in my commit messages either.

Some teams have different policies, and that's fine. But for my personal projects, the commit history is clean and the attribution is mine.

Default Mode

Copy"defaultMode": "default"

I use the standard permission model, not "dangerously skip all permissions" mode. This means Claude Code asks before doing certain things: running destructive commands, modifying files outside the project, making network requests. I want those guardrails for normal work.

The Permissions Allowlist

This is where things get nuanced. I auto-approve certain operations that I trust and that would be annoying to approve manually every time:

• git log, git status, git diff -- Read-only git operations. These happen constantly during normal work. Approving each one would be death by a thousand clicks.
• ls, find -- Directory listing and file search. Same reasoning.
• WebSearch -- Web searches. Claude Code often needs to look things up. I trust it to search the web without asking first.

Everything else requires approval. File writes, command execution, git commits. I see every action before it happens.

Dangerous Mode Override

Copy"skipDangerousModePermissionPrompt": true

When I do switch to dangerous mode for a specific task, this skips the "are you sure?" confirmation. I only use dangerous mode for well-defined tasks where I trust the agent to operate autonomously, like running ralph-loop on a refactoring task. The confirmation prompt adds friction without adding safety in those cases, because I've already made the conscious decision to grant full autonomy.

The Hooks

Hooks let you run scripts at specific points in Claude Code's lifecycle. I use two.

SessionStart runs when I launch a new Claude Code session, as I described in the hooks and automation post. Mine checks for GSD methodology updates. GSD is the development methodology plugin I mentioned earlier, and it gets updated frequently. The hook ensures I'm always running the latest version without having to remember to check manually.

statusline-command.sh isn't technically a hook, but it's automation that runs alongside Claude Code. It's a shell script that reads Claude Code's session state and feeds it into my terminal's status line. I can see the current session ID, the model being used, and the context window usage at a glance. It's a small script that took 20 minutes to write and saves me from constantly wondering "wait, which session is this?"

What's NOT in the Setup

The things I removed are as important as the things I kept.

The original superpowers plugin is disabled. I replaced it with superpowers-extended-cc. Keeping both would create conflicts, with both trying to handle the same workflows. When you upgrade a plugin, disable the old one. Don't let them fight.

I tried and removed several MCP servers for things like calendar integration and email. They worked technically but didn't fit my workflow. Calendar events are something I want to see in a GUI. Email is something I process in batches in the actual email client. Not everything needs to be in the terminal. The fact that you can do something in Claude Code doesn't mean you should.

I removed a few "fun" plugins that added capabilities I used once and never again. A meme generator. A music recommendation engine. They were cool demos. They weren't tools. There's a difference.

The principle is simple: every plugin must earn its place through regular use. If I haven't used it in two weeks, it gets disabled. If it stays disabled for another two weeks, it gets removed. This keeps the setup lean and the startup time fast.

Pruning matters more than people think. Every plugin adds to the tool inventory that Claude Code considers when deciding how to handle a request. Too many tools creates noise. The agent spends time evaluating irrelevant options. A focused toolkit makes the agent faster and more accurate.

How This Evolved

None of this was planned. I didn't sit down on day one and decide I needed 19 plugins and 23 skills. The setup grew organically over months of daily use.

Month one was bare bones. Claude Code out of the box, a basic CLAUDE.md, and maybe two or three plugins. I was still learning what the tool could do.

Month two is when I started building skills. The calorie tracker was the first non-coding skill, and building it taught me how flexible the skill system is. Once I realized I could define any workflow as a markdown file and have Claude Code execute it, the floodgates opened.

Month three is when the plugin count started climbing. Each plugin solved a specific friction point. I'd notice something annoying, search for a plugin that fixed it, and install it. The PR review toolkit came from frustration with shallow single-pass reviews. The notification plugin came from losing track of background tasks. Each addition was a response to a real problem.

Now, in month four-plus, I'm in maintenance mode. The setup is stable. I add new things occasionally. I remove things more often than I add them. The focus has shifted from building the setup to refining it.

Closing Thoughts

If you've read this far, you might be tempted to copy this setup wholesale. Don't.

My configuration reflects my workflow, my projects, and my preferences. I'm an ML engineer who builds web applications, tracks calories, automates grocery shopping, and writes blog posts from the terminal. Your workflow is different. Your setup should be different.

Start minimal. Install Claude Code. Write a CLAUDE.md. Use it for a week. Notice the friction points. Find or build solutions for those friction points. Repeat.

The best setup is the one that matches your actual workflow, not someone else's. The value of posts like this isn't that you should copy the config. It's that you see what's possible and get ideas for your own.

That said, if you take one thing from this post, let it be this: custom skills are the most underused feature in Claude Code. A markdown file with some frontmatter and a prompt can automate nearly anything. Start there.

Tomorrow's post covers CLAUDE.md in depth, how to write the file that makes your agent dramatically better at understanding your project. It's the single most important configuration file in the entire setup, and most people either skip it or write it badly.

See you then.