Your toolbox: slash commands and the .claude/ folder from A to Z

Your project has grown: you need a map

In eight chapters, Lea's project has accumulated skills, hooks, subagents, settings files, and a project memory. Everything works — but if someone asked you to sketch where each piece lives, could you? This chapter gives you the complete map. It's not tidying for tidying's sake: knowing precisely where each mechanism lives means knowing where to look when something breaks, and where to add the next brick without breaking the others.

There's a second, more strategic reason. If Lea ever hires an assistant, or hands her site to a freelancer, everything properly organized in .claude/ and versioned in Git gets transferred: the person clones the repo and instantly inherits the conventions, the skills, and the guardrails. The .claude/ folder isn't a technical detail — it's the brand's operational capital, in file form.

The complete anatomy of the .claude/ folder

Here's the overview: two memory files at the project root, and a .claude/ folder that serves as the control center. The cross-cutting logic you already know from chapters 2 and 8: each piece exists in a shared version (committed to Git, for the team) and a local version (gitignored, for you alone).

flowchart TD
  P["Project root"] --> M1["CLAUDE.md: team instructions, committed"]
  P --> M2["CLAUDE.local.md: personal overrides, gitignored"]
  P --> R[".claude/: the control center"]
  R --> S1["settings.json: permissions + config, committed"]
  R --> S2["settings.local.json: personal settings, gitignored"]
  R --> CMD["commands/: custom slash commands"]
  CMD --> C1["10x.md → /project:10x"]
  R --> RU["rules/: modular instructions"]
  RU --> R1["code-style.md, api-conventions.md"]
  R --> SK["skills/: auto-invoked workflows"]
  SK --> K1["post/SKILL.md"]
  R --> AG["agents/: subagent personas"]
  AG --> A1["code-reviewer.md, security-auditor.md"]

• CLAUDE.md (root) — the project's instructions, committed: everyone inherits them (chapter 8).
• CLAUDE.local.md (root) — your personal overrides, gitignored: your shortcuts, your preferences, your local paths.
• .claude/settings.json — permissions and configuration shared with the team (chapter 2).
• .claude/settings.local.json — your local permissions, gitignored.
• .claude/commands/ — your custom slash commands: a name.md file becomes /project:name.
• .claude/rules/ — modular instruction files (code style, API conventions…) referenced from CLAUDE.md.
• .claude/skills/ — the auto-invoked workflows with their SKILL.md (chapter 3).
• .claude/agents/ — the specialized subagent personas (chapter 6).

The CLAUDE.md / CLAUDE.local.md duo deserves clarification, because it solves a real team problem. The first carries the common law: conventions, structure, guardrails. The second carries your particulars: "my screenshots are in ~/Desktop/captures," "answer me in French," "I use this alias." Without that separation, each team member would pollute the shared memory with their personal details — or worse, overwrite everyone else's at every commit.

Rules: splitting the law into modules

In chapter 8, we told you to keep CLAUDE.md short. But what do you do when conventions pile up — writing style, file naming conventions, API rules? The answer: the .claude/rules/ folder. Each theme becomes a dedicated file (code-style.md, api-conventions.md, testing.md), and CLAUDE.md merely references them. Claude loads the relevant rule when the topic calls for it.

For Lea, that means for instance a rules/writing.md (the detailed writing rules that were overflowing from brand-voice.md) and a rules/publishing.md (time slots, image formats per platform, hashtag policy). The benefit is the same as for any code: short, focused modules are easier to maintain than one monolithic file — and you can add more without bloating every session's context.

SKILL.md: reference content or task content?

Now that you've written several skills, let's zoom out. A SKILL.md file can hold any instructions, but in practice there are two broad types — and telling them apart will help you write sharper skills. Reference content adds knowledge that Claude applies to your ongoing work: business context, company history, the nuances of your database, style guides. Task content gives step-by-step instructions for a specific action: generating code, building slides, drafting a document.

A reference skill reads like a cheat sheet Claude keeps in view while it works:

---
name: brand-context
description: Knowledge about Lea's brand (positioning, product lines, clientele). Use for any writing or product decision.
---

# The brand
- Organic cosmetics, made in France, Ecocert certified.
- Positioning: accessible and educational, never guilt-tripping.

# The product lines
- Hydration (best-seller: shea cream), Sun care (new), Essentials.

# The clientele
- Women 25-45, ingredient-conscious, buy online first.

# Important nuances
- Never promise dermatological results (legal constraint).
- "Natural" is banned: too vague, prefer "certified organic".

A task skill, on the other hand, is a procedure: ordered steps, exit criteria, mandated formats. Your /post from chapter 3 is one. Here's another, shorter, to make the contrast clear:

---
name: newsletter
description: Writes the weekly newsletter in the house format. Use when the user asks for the newsletter.
---

# Steps
1. Read the week's post log (logs/posts.md).
2. Select the 3 most engaging posts.
3. Write: a 2-sentence intro, the 3 posts summarized, a CTA to the shop.
4. Apply brand-voice.md.
5. Write the result to newsletters/YYYY-MM-DD.md and ask for approval.

# Exit criteria
- Under 300 words. A single CTA. No banned words.

Many good skills mix the two — a procedure resting on knowledge — but always know which one dominates. If you can't write the "Steps," it's probably a reference skill in disguise: separate the knowledge (reference) from the action (task), and have one reference the other. That's exactly what we did in chapter 4 with brand-voice.md.

The "secret commands": the truth behind the myth

You may have come across those viral graphics: "Claude's secret codes — /godmode, /10x, /devil…". Let's set the record straight: these are not native commands. Type /devil on a fresh install and nothing happens. But the idea behind the myth is excellent, and you now have all the background to understand it: they are custom slash commands anyone can create in .claude/commands/ — reusable prompts you give a name to.

The mechanism is disarmingly simple: a Markdown file .claude/commands/10x.md becomes the command /project:10x. The file's content is the prompt sent to Claude, and the keyword $ARGUMENTS is replaced with whatever you type after the command. No mandatory YAML, no imposed structure: it's the lightest of the extension mechanisms.

# Create the project's commands folder
mkdir -p .claude/commands

# Each file becomes a command:
#   .claude/commands/10x.md      -->  /project:10x
#   .claude/commands/devil.md    -->  /project:devil

# Personal commands live in your user folder:
#   ~/.claude/commands/brief.md  -->  /user:brief

Build your library: Lea's 9 commands

Here's the library Lea built for herself, file by file. Don't copy them blindly: read each prompt, understand what it constrains, and adapt it to your practice. /10x — her favorite for punching up Twitter hooks before publishing:

---
description: Rewrites a text to make it 10x more punchy
---

Rewrite this text to make it 10x more punchy:
- cut every word that carries no meaning
- start with the strongest idea, not the context
- one idea per sentence, active voice
- keep my tone (brand-voice.md), invent no facts
- offer 3 variants, from the most sober to the most daring

Text: $ARGUMENTS

/brief — the shortest possible answer, zero filler. Lea uses it when she wants a fact, not a lecture:

Answer the following question as briefly as possible.
No introduction, no caveats, no final summary.
If the answer fits in one word or one number, give one word or one number.

Question: $ARGUMENTS

/explainlikeim5 — the ultra-simple explanation. Precious when a contractor sends her technical jargon:

Explain the following concept as if to a 5-year-old:
- one everyday-life analogy
- short sentences, no jargon
- end with "in one sentence: ..."
- then add the level above: the same explanation for a curious adult, in 3 sentences

Concept: $ARGUMENTS

/devil — the serious version of devil's advocate: a "steelman," meaning the best possible defense of the opposing position, not a caricature. Lea runs it systematically before publishing an opinionated post about ecology — better to discover the objection in her terminal than in the comments:

---
description: Steelman of the opposing position, to stress-test an argument before publishing
---

Play devil's advocate on the following position.
Build the STEELMAN of the opposing position: its strongest,
most honest version, defended by someone intelligent and in good faith.
- 3 solid counter-arguments, ranked from strongest to weakest
- for each: how I could honestly respond to it
- end with: what I should nuance in my initial position

My position: $ARGUMENTS

/critique — finds the flaws and proposes concrete improvements, no sugarcoating:

Critique the following work without any sugarcoating:
- 5 precise flaws, ranked by severity (blocking / important / detail)
- for each flaw: a concrete fix, not vague advice
- what's good and should be kept (2 points maximum)
- final verdict: publishable as is, yes or no, and why

Work to critique: $ARGUMENTS

/pitch — the 30-second pitch, customer or investor. Lea uses it to prepare her retail meetings and funding requests:

Turn the following into a 30-second pitch (75 words maximum):
- structure: lived problem, solution, proof, call to action
- no empty superlatives (leader, unique, revolutionary)
- an opening line that sparks curiosity from the first second
- give 2 versions: one for a customer, one for an investor

Topic: $ARGUMENTS

/compare — the side-by-side analysis in a table, to decide quickly between two options (two post-scheduling tools, two packaging suppliers…):

Compare the following options side by side:
- table: criteria as rows, options as columns
- mandatory criteria: cost, setup time, risks, reversibility
- add the criteria specific to the topic
- below the table: your recommendation in 2 sentences, with the condition
  that would tip it toward the other option

Options: $ARGUMENTS

/scout — the scout: risks and blind spots of a plan, before committing:

---
description: Detects the risks and blind spots of a plan before committing
---

Analyze this plan like a cautious scout:
- 5 concrete risks, each with: probability (low/medium/high),
  impact, and an early warning signal to watch
- 3 blind spots: the questions I'm not asking myself and should
- the most likely failure scenario, told in 3 sentences
- the 2 cheapest protections to put in place right now

Plan: $ARGUMENTS

/teacher — mentor mode: Claude doesn't execute, it teaches, questions, and debates. Lea uses it to level up instead of just delegating:

Switch to mentor mode on the following topic.
Do NOT do the work for me:
- explain the key concept starting from what I probably already know
- ask me one question at a time to check my understanding
- when I'm wrong, don't give the answer: guide me toward it
- end the session with 3 takeaways and an exercise to do on my own

Topic: $ARGUMENTS

Slash command or skill: how to choose?

The question to ask: "is this a rubber stamp or a process?" A rubber stamp — a transformation applied to text you provide — makes a perfect slash command. A process — multiple steps, files to read and write, validations — deserves a skill. And the two combine: Lea runs /project:devil on a draft produced by /post, then /project:10x on the chosen hook. The toolbox doesn't replace the factory; it equips it.

Lea's routine, fully equipped

Concretely, here's what an opinionated publication now looks like at Lea's: /post generates the draft in her voice; /project:devil stress-tests the argument and reveals the strongest objection; she nuances one sentence; /project:10x proposes three punchier hooks; she picks one; the quality gate checks everything; published. Four commands, five minutes, and a post more solid than what she used to write in an hour — because every link encodes expertise she no longer has to summon from memory.