Custom Claude Code Commands: My Personal Setup for Maximum Productivity

I pay 600 dollars a month for Claude. Three Max20 accounts, each regularly hitting 100% of the weekly limit. Once I started 12 Claude Code sessions simultaneously on my M4 Air. That was too much. Five in parallel works fine though.

That sounds like overkill. Honestly, it probably is. But here is the thing: I barely write code myself anymore. Claude does that. Not because I am lazy, but because after 10 years of Rails development I understood that my job is not typing. My job is orchestration. Thinking. Architecture.

In this article I show you my complete setup. The commands that save me hours daily. The skills that make Claude smarter. The MCP servers that tap into external APIs. The agents that handle specialized tasks. And probably most importantly: /generate-prompt, the command that changed how I work with context.

Who I am and why you should care

Quick background: I am Daniel Samer, Senior Rails Backend Developer at Linkster GmbH. About my career you can learn more about my 10+ years in Rails development. Programming since 2001, building automations since I was 18. Over 50 bot projects, from WoW Auction House bots to Twitter armies. The story of my bot projects shows how I built over 50 automations. RLTracker.pro, Golem Overlord, Splex.gg. Most of my previous projects were built with Claude Code. All self-hosted, all by myself.

The last two years I worked intensively with Claude. First the API, then claude.ai, now almost exclusively Claude Code. My workflow changed completely. Before: understand problem, write code, test, debug. Now: understand problem, instruct Claude, review, merge.

I still do code reviews at work myself. Everything else? Claude handles it.

The Workflow: 5 Sessions Parallel, One Codebase

Here is where it gets interesting. I regularly run 5 Claude Code sessions simultaneously on the same codebase. Without Git worktrees. That sounds like chaos, but it works surprisingly well.

I sit and plan in all sessions one after another. The sessions do not know about each other. They do not even know they are running in parallel. I am the orchestrator, not Claude.

Typical distribution:

• One session works on Feature A

• Another on Feature B

• One updates the CLAUDE.md, builds Commands, Skills or Agents... you get the idea

• One writes a blog post

• One does code review

Why does this work without worktrees? Git conflicts never happen. I mean it. Since we do not use worktrees, all sessions work in the same directory. When two sessions try to edit the same file, something else happens: One session does not immediately have the latest version of the file. It works with the state from before the change. That is a different problem than Git conflicts. It is about synchronization, not merge issues.

The trick: I make sure sessions work on different areas. Feature A touches different files than Feature B. The blog post writer does not touch code. The code reviewer only reads.

/generate-prompt: The Command That Changed Everything

Let me explain the command that saves me the most time. It solves the biggest problem with Claude Code: context loss.

You know the situation? You work on something for two hours. Claude understands the context perfectly. Then the session gets too big. You have two options: use /compact and get a significantly "dumber" Claude back, or start fresh and rebuild the context.

/generate-prompt solves this. The command analyzes the current context and generates a structured prompt. You copy it into a new session. The new Claude immediately has the relevant context. Not the entire history, but everything that matters.

The command analyzes: current task, steps already completed, open items, relevant file paths and decisions made. The result is a Markdown document, directly copyable.

I use this multiple times daily. Especially when switching between accounts or when sessions die.

It took three iterations until the command worked well. The first version generated too much context. 2000 lines nobody wanted to read. The second was too brief. The current one hits the sweet spot, at least in my experience.

The Most Important Built-In Features

Before we get to custom commands, here are the built-in features I use constantly:

--dangerously-skip-permissions: Starts Claude Code without permission prompts. Yes, the name is intentionally scary. But if you know what you are doing and only use Claude Code in local projects, this saves enormous time. No more "May I read this file? May I run this command?"

/clear: Clears the context. Important when sessions get too big. In my experience, Claude gets slower and less precise the larger the context. A strategic /clear helps.

/compact: Compresses the context. Keeps important information, throws out unimportant stuff. Good compromise when you do not want to lose everything.

Custom Commands I Use Daily

/commit

My custom command for commits. Claude analyzes the changes and generates a meaningful commit message. Saves me from thinking about commit messages.

/deploy

My deploy workflow in one command. Significantly smarter than "check tests, deploy". The command follows a strict workflow: First it automatically runs /commit (commit-first workflow), then it analyzes recent commits for asset changes. Did JavaScript, CSS or the Tailwind config change? Then a --full deploy with asset recompilation. Only backend code? Then --with-workers for a faster deploy.

The most important part: Git safety rules for production. The command never uses git reset --hard on the server because auto-generated content (like blog posts) might exist there that has not been pushed yet. On conflicts, it commits first, then merges. This rule exists because I once lost blog posts. Never again.

/enhance-claude-md

This is a plugin, not just a simple command. It has three modes: analyze (evaluate existing CLAUDE.md), create (generate new one), and enhance (improve existing one).

What makes it special: It can generate modular architectures. Instead of a monolithic CLAUDE.md it creates backend/CLAUDE.md, frontend/CLAUDE.md and a root file as navigation hub. This matters for larger projects. 500+ lines in one file become unwieldy.

The workflow is interactive: The plugin first explores the repository, detects tech stack and project type, shows the findings, and asks for confirmation before creating files.

CLAUDE.md is the context Claude loads with every session. The better it is, the less I need to explain. Investment in CLAUDE.md pays off. At least that has been my experience.

/claude-factory:build

This is my meta-command. It is itself an orchestrator. It never writes files itself, but delegates to specialized agents:

• skills-guide for building custom skills through Q&A

• agents-guide for custom agents

• hooks-guide for custom hooks

• command-guide for custom commands

• ... and probably more by the time you read this

The command supports CREATE and UPDATE modes. Want to improve an existing skill? /build update skill path/to/skill delegates to the skills-guide with the context of the existing files.

Meta-automation at meta-level: A command that builds commands, that itself consists of commands, that use agents. That is the level I operate at now.

The Skills System Explained

Skills are technically minimally different from Commands, but conceptually important. The main difference: Skills have YAML frontmatter with more options like context: fork for isolated execution.

Commands live in .claude/commands/. Skills can live anywhere. But functionally: both create slash commands.

What Makes Skills Really Powerful

Skills are project-specific knowledge dumps. An example from my setup: project-styling contains my complete color system with auto-adapting CSS variables for dark/light mode, the terminal-inspired aesthetics, and all component patterns. When Claude loads this skill, it instantly knows surface-primary, content-secondary, border-default. No explanation needed.

For frontend work I always load four skills simultaneously: project-styling (color system), design-principles (Jony Ive-inspired minimal aesthetics), stimulus-patterns (JavaScript interactivity), tailwindcss (TailwindCSS v4 patterns). This makes Claude instantly productive for UI work. At least in my experience.

When Skills vs Commands?

I initially built everything as Skills. Overkill. Now: Commands for anything under 20 lines. Deploy scripts, quick fixes, Git commands. Skills only when I need sub-tasks, isolated context, or a large knowledge dump that needs to be loaded.

Why? Commands are faster. No file organization, no YAML complexity. Skills have features like context: fork for isolated execution, but honestly, you only need that for more complex workflows.

My structure:

.claude/
├── commands/           # Simple commands
│   ├── commit.md
│   ├── deploy.md
│   └── generate-prompt.md
├── skills/            # Complex skills
│   ├── content-writer/
│   │   ├── SKILL.md
│   │   └── templates/
│   └── code-reviewer/
│       └── SKILL.md
└── agents/            # Custom agents
    ├── rails-backend-engineer.md
    └── frontend-rails-engineer.md

MCP Servers: Connecting Claude with External APIs

MCP (Model Context Protocol) makes Claude Code significantly more practical. It connects Claude with external data sources.

There are over 1,200 available MCP servers out there. I use maybe 8 of them regularly.

My Active MCP Servers

context7: Loads current documentation for libraries. When I work with a library Claude does not know (or knows incorrectly), context7 pulls the current docs.

nanobanana: AI image generation directly in Claude Code. For blog post banners, screenshots, visualizations.

playwright: Browser automation. Claude can take screenshots, navigate websites, fill forms. I use this for testing and verification.

dataforseo: SEO data. Keyword research, SERP analysis, backlink checks. Directly in Claude Code without external tools.

trello: Project management integration. Claude can read, create, move cards. My content workflow runs entirely through Trello MCP.

filesystem: Extended file access. The standard is limited, filesystem MCP gives Claude more capabilities.

I am probably forgetting one or two. The list changes depending on the project.

Setting Up MCP Servers

The configuration lives in .mcp.json:

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@context7/mcp-server"]
    },
    "trello": {
      "command": "node",
      "args": ["./mcp-servers/trello/index.js"],
      "env": {
        "TRELLO_API_KEY": "xxx",
        "TRELLO_TOKEN": "xxx"
      }
    }
  }
}

Important: MCP servers load at session start. More servers mean longer startup. I learned to only activate what I actually need.

Custom Agents: Specialized AI Instances

Agents are delegated sub-tasks with isolated context. The main agent says: "Go research X." The subagent does that, comes back with the result.

My /Users/danielsamer/agents/ directory has 15+ agents. Here are the ones I use most:

@rails-backend-engineer

Specialized for Rails backend code. Knows my service object patterns, knows how I structure database queries, understands my testing conventions.

@frontend-rails-engineer

For frontend work. Knows Hotwire, Stimulus, TailwindCSS. Knows I use surface-* and content-* CSS variables. Always loads with four skills: project-styling, design-principles, stimulus-patterns, tailwindcss.

@code-quality-guardian

Review agent. Checks code for quality issues, missing tests, security problems. Runs after every implementation. I think this one catches more bugs than I would manually.

@dead-code-detector

Finds unused code. Orphaned references, unused methods, deprecated imports. Runs after refactorings.

The agent delegation works something like this:

Main agent: "Analyze this PR and check for security issues."
↓
Delegation to @code-quality-guardian
↓
Guardian works in isolated context
↓
Result comes back to main agent
↓
Main agent summarizes or delegates next task

This is the workflow that allows me to run 5 sessions in parallel. I orchestrate, the agents work.

Hooks: Automatic Actions at Lifecycle Events

Claude Code supports 12 different hook events. I use two of them intensively, both on the same event: UserPromptSubmit.

skill-forced-eval-hook

The problem: Claude sometimes "forgets" to load skills, even though they are available. My hook enforces the evaluation on every single message, not just at session start.

The hook lives in ~/.claude/scripts/skill-forced-eval-hook.sh and triggers on UserPromptSubmit. This means: Before Claude responds to any of my prompts, a SKILL-EVALUATION block is injected that forces Claude to evaluate all available skills and load the relevant ones.

The difference to SessionStart: UserPromptSubmit fires on every message. This matters because context can change during a session. What was not relevant at the start might become important later.

The Orchestrator Mode Hook (-s Flag)

My second hook on UserPromptSubmit is even more interesting: append-subagent.py. It only activates when my prompt ends with -s.

When I end a message with -s, Claude is put into orchestrator mode. It never writes files itself. It delegates everything to specialized subagents. It first uses a prompter agent to generate optimal prompts, then the actual worker agents.

Why does this matter? It enables me to run multiple Claude sessions in parallel on the same codebase without conflicts. The orchestrator in one session does not know about other sessions, but since it does not touch files itself, there are no race conditions. Or at least, that is the theory. In practice it works surprisingly well.

Other Useful Hooks

PreToolUse: Validation before tool execution. I use this to block or warn about certain commands.

PostToolUse: Logging, notifications. Could send Slack notifications when certain actions happen. I have not set this up yet, but it is on my list.

Stop: Autonomous workflows. The "Ralph Wiggum Loop" uses Stop hooks for iterative development.

The Content Machine (brief insight)

I built a system I call "Content Machine". It generates blog posts, manages research, optimizes for SEO. The system is complex enough for its own article.

Just this much: It combines everything I described. MCP servers for keyword research (dataforseo), agents for different writing phases (topic-researcher, seo-writer), skills for humanization (humanize-content), Trello integration for workflow management.

A blog post like this one: Topic idea, then Trello card, then keyword research, topic research, draft, optimization, publish. All orchestrated through Claude Code. With such systems, I also offer AI Workflow Automation services, as well as a content generation system for automated blogging.

I am keeping the details private. But the principle: Combine the tools into workflows that are greater than their parts.

Practical Setup Recommendations

If you want to improve your Claude Code setup, here are my recommendations based on what worked for me:

Start with CLAUDE.md

This has the highest ROI in my experience. Document:

• Project structure

• Coding conventions

• Common patterns

• What Claude should NOT do

I cannot stress this enough. Document everything.

Build Your First Commands

I started with simple automations. A commit command with my preferences. A test command that knows my test framework. A deploy command for my workflow. Nothing fancy at first.

Then MCP Servers

Start with one. context7 is good for library docs. Or filesystem for extended file access. Build out slowly. Do not try to set up everything at once.

Agents Later

Agents are powerful but complex. I would recommend understanding commands and skills first before building agents. Delegation is a different paradigm.

The Most Important Tip

The most important tip I learned: Use plan mode. Shift-Tab switches to it. Claude explains what it plans to do before doing it. That saves tokens and frustration.

Why All This Works

I said at the beginning: My job is not typing. My job is orchestration.

The setup I described enables exactly that. Claude writes the code. I define the architecture. It implements. I review. It corrects. I merge.

600 dollars a month sounds like a lot. But do the math: If I save 4 hours a day, and my hourly rate for freelance work is 100 euros, I save 8,000 euros per month. The 600 dollars are a rounding error.

That is the actual point. It is not about cool tools. It is about multiplying output. The tools multiply what I can do. I produce in a week what used to take a month. Or at least that is how it feels.

And yes, sometimes Claude hits a wall. Sometimes it does not understand what I want. Sometimes it makes mistakes I need to correct. But overall? The productivity increase is real. Very real.

The best moment is waking up in the morning and seeing that the overnight session finished implementing a feature. While I was sleeping. That is the future. Or maybe I am just lazy. Probably both.