I’m juggling a lot of vibe projects right now - this blog, an iOS app, a few other sites, and a handful of experiments. There’s no way I could maintain quality across all of them if I was winging it every session. But I also don’t want rigid scripts that kill the creative back-and-forth that makes vibe coding actually fun.

That’s where slash commands come in. They hit this sweet spot between consistent automation and still having room to riff.

WHAT’S A SLASH COMMAND Commands are markdown files that teach Claude Code specific workflows. Type /my-command and Claude follows those instructions exactly, but you can still interact and adjust as it goes.

WHY COMMANDS

Commands are ideal when you have a repetitive workflow that still needs human-in-the-loop interaction. Pure automation doesn’t work because you need to make decisions and steer things creatively. But pure vibing means re-explaining the same process every time. Commands sit in the middle.

For example, I have a /vibe-article command for this blog. When I run it, Claude walks through my whole content workflow - checks the backlog, reads my voice guidelines, drafts the article, asks about scheduling. I don’t have to re-explain my process, but I can still jump in and redirect things whenever I want.

Commands give you:

  • Consistency - The same quality checks run every time, even when you’re tired
  • Flexibility - They’re workflows, not scripts, so Claude still thinks and adapts
  • Scale - You can switch between projects without context-switching your brain

WHERE COMMANDS LIVE

Commands can live in two places - at the project level or globally:

Project commands go in .claude/commands/ inside your project. These are specific to that project:

your-project/
├── .claude/
│   └── commands/
│       ├── session-start.md
│       ├── component-check.md
│       └── article-polish.md

Global commands go in ~/.claude/commands/ and work across all your projects - handy for personal workflows you use everywhere, like a session start ritual or a general code review process.

One thing to know: commands are loaded when Claude Code starts up, so if you create or edit a command, you’ll need to restart your session for the changes to take effect. Just exit and start Claude Code again.

WHAT A COMMAND LOOKS LIKE

Here’s a simplified version of my /vibe-article command (the real one is longer, but this shows the structure):

---
description: Create blog article from backlog or new idea
---

## Workflow

### 1. Topic Selection
ASK USER: "What topic from backlog or new idea?"
- Check docs/CONTENT-BACKLOG.md for existing ideas

### 2. Read Guidelines
- Read docs/CONTENT-GUIDE.md for voice and style

### 3. Draft the Article
Write following natural conversational style.

**Voice Checklist - AVOID:**
- Punchy marketing language
- "Let's dive in" openings
- Too many short sentences in a row

### 4. Review Draft
Show complete draft for user review. Wait for feedback.

Type /vibe-article and Claude runs through the whole workflow - but I can still jump in, adjust, or take things in a different direction. It’s a framework, not a cage.

WHAT MAKES A GOOD COMMAND

After building commands across a bunch of projects, here’s what I’ve found works:

  • Keep them focused - One command should do one workflow. If you’re trying to cram too much in, split it into separate commands that can chain together.
  • Include decision points - The best commands pause and ask you things rather than barreling through. That’s what keeps it collaborative instead of just a script running.
  • Reference your docs - Point Claude to your CLAUDE.md, style guides, whatever. The command stays lean but Claude gets the context.
  • Add a description - That description: line in the frontmatter helps when you’re scanning your commands folder months later.
  • Don’t overthink length - Some of my commands are 10 lines, others are 80+. Depends on the workflow.

MY CLAUDE CODE COMMANDS

Each of my projects has its own set of commands tuned to what that project needs:

  • /article commands that enforce specific content patterns and voice guidelines
  • /seo commands that run analysis, add citations, and check for banned phrases
  • /research commands that kick off parallel research sessions
  • /component-check commands that walk through what to verify before creating something new

By the way - commands can chain to other commands, which is incredibly useful. My article commands end with “Run the SEO command on this” so the quality pass happens automatically without me having to remember. This kind of chaining is what makes commands so powerful for complex workflows.

WHERE SHOULD MY CONTEXT GO: CLAUDE.MD OR A COMMAND?

If you’ve gotten good at customizing your CLAUDE.md, you might be wondering where new instructions belong. I definitely did. My instinct was to keep adding stuff to CLAUDE.md - every workflow, every edge case, every “remember to do this” note. It ballooned to 200+ lines and became this catch-all document that Claude had to parse every single time.

Here’s the best practice for what goes where:

CLAUDE.md = The house rules

  • What exists (components, patterns, structure)
  • Constants (design tokens, tech stack)
  • Rules that never change

Commands = Instruction manuals for specific tasks

  • Step-by-step workflows
  • Session rituals
  • Quality checklists

Once I moved the workflows into commands, my CLAUDE.md dropped to 52 lines. That matters because CLAUDE.md gets loaded with every prompt - a bloated one eats into your token budget and buries the important stuff. Now my project context is tight, I actually maintain it, and the workflows are consistent because they’re explicit instead of buried in a giant doc.

CREATING YOUR FIRST COMMAND

If you want to try commands, start with something simple that you’ll actually use - like a session start ritual. Almost everyone benefits from a consistent way to kick off a work session, and it’s a good way to see how commands feel before building more complex ones. Just describe what you want to Claude:

Create a slash command called /session-start that:
1. Reads CLAUDE.md for project context
2. Checks TODO.md for current tasks
3. Shows me what's in progress
4. Asks what I want to work on today

Put it in .claude/commands/ with a description in the frontmatter.

Claude will create the folder if needed and write the command file in the right format. Now /session-start handles your whole opening ritual, and it’ll run the same way every time.

SCALING WITHOUT LOSING THE MAGIC

Without commands, I could maybe write one or two solid articles a day if I really focused. With commands, I could write ten - all hitting my voice guidelines, all going through the same quality checks, all with the creative back-and-forth that makes each one feel like mine and not just AI slop.

That’s the thing. Commands don’t replace the creative work - they protect it. The boring consistent stuff (check the backlog, follow the style guide, run the SEO pass) happens automatically. The interesting stuff (what angle to take, how to frame this, when to break my own rules) is still me and Claude riffing together. I get scale without sacrificing what makes the work good.