Prompts, commands & guides: how they work and why they pay off

Claude Code gives you six overlapping ways to shape a session: a raw prompt, a system prompt you don't control, CLAUDE.md, slash commands, skills, and subagents. Almost all of the value I've extracted from my saved-screenshot archive came from turning repeated prompts into named, reusable things — not from writing cleverer one-off messages.

TL;DR

• A prompt you retype more than once a week is a command or skill you haven't built yet.
• CLAUDE.md rules written right after a real correction measurably cut Claude's mistake rate over time.
• The two prompts worth stealing outright: the 5-area security audit, and "grill me / no PR until I pass your test."
• Custom slash commands are just markdown files with $ARGUMENTS. There's no special syntax to learn.
• Persona prompts ("act as a senior X") work, but only when you fill in real specifics. Otherwise you get polished, generic output.
• Skills and commands you install unread are the actual risk — not the tech. Read the markdown first.
• Value shows up as fewer correction cycles per PR, not as "smarter answers."

How the pieces fit together

The mental model: prompts are disposable, CLAUDE.md is ambient, commands are deliberate, skills are conditional, subagents are isolation.

Slash commands

Built-in commands ship with Claude Code itself — /init, /compact, /config, /statusline, and friends.

Custom ones are just prompt text in a file. Drop a markdown file in .claude/commands/name.md (project-level, git-shared) or ~/.claude/commands/ (personal) and it becomes /name. So review.md → /project:review, deploy.md → /project:deploy. Use $ARGUMENTS inside the file so one command handles many inputs: /fix-issue 123.

That's the whole mechanism. The hard part is noticing what to extract.

One archive post catalogs 89 commands across 11 categories. I don't use most of them, but it's a useful naming vocabulary when you're building your own:

• Start & Create — /new, /project, /template, /scan
• Focus & Context — /focus, /clarify, /constraints, /assumptions
• Think & Solve — /analyze, /compare, /brainstorm, /challenge
• Write & Edit — /write, /rewrite, /shorten, /improve
• Organize & Structure — /outline, /table, /summary, /mindmap
• Code & Tech — /code, /debug, /refactor, /test, /review
• Data & Analysis — /visualize, /insights, /forecast, /stats
• Automate & Integrate — /workflow, /automate, /schedule, /checklist
• Personalize & Control — /preferences, /memory, /tone, /format
• Learn & Research — /search, /research, /tldr, /fact-check
• Collaborate & Share — /share, /export, /publish, /feedback

Prompt patterns that actually work

Security audit (senior security engineer)

You are a senior security engineer conducting a full audit of this codebase.
Analyse every file systematically and produce a prioritised vulnerability report.
Check, in order: 1. SECRETS & CREDENTIALS  2. DEPENDENCIES & SUPPLY CHAIN
3. AUTHENTICATION & AUTHORISATION  4. OWASP TOP 10  5. INFRASTRUCTURE
For each finding, output: Severity (Critical/High/Medium/Low), file and line
number, exact vulnerable code, why it's exploitable, fix with a code example.

Use it before shipping anything vibe-coded, or before a real security review.

Harsh reviewer

Grill me on these changes — no PR until I pass your test.

Use it right before opening a PR — and run it as a second session or subagent, so it isn't grading its own work.

Elegant-solution reset

Knowing everything you know now, scrap this and implement the elegant solution.

Use it after the first working pass, when the implementation feels bolted-together rather than designed.

Second opinion / adversarial review

Have a second session review this plan as a staff engineer before I proceed.

There's a lighter variant you can drop straight into CLAUDE.md: "Codex will review your output once you are done." An external "someone's checking" line visibly changes how carefully Claude finishes.

Role-play expert report

You are a [senior role] at [respected org] with [N] years of experience in
[domain]. I need [deliverable] for [goal]. Analyze and provide: [bulleted
list of required outputs]. Format as a [named professional report].

Use it for any analysis task where naming a real discipline — not just "expert" — sharpens the structure of the answer. It only works if you fill in real specifics. The brand name alone does nothing.

Design/UX audit

Act as a world-class creative director. Audit [WEBSITE/SCREENSHOTS] for
anything making it feel generic, cheap, cluttered, or unfinished. Improve
typography, spacing, hierarchy, composition, motion, and micro-interactions.
Give exact fixes that make the experience feel refined and intentionally
art-directed.

Use it after a first UI pass, before calling a design "done."

Agent persona (SOUL.md)

Stance: [how direct/opinionated the agent should be]
Accountability: [what it should proactively surface]
Autonomy: [what it can do without asking]
Mission: [priorities, active work, debt, what to sunset]
Pushback: [when/how it should disagree with you]
Operating Mode: [orchestrator vs. solo executor]

This is for defining a long-lived, semi-autonomous agent rather than a one-off task. Stance, Autonomy and Mission are the three sections that decide whether it behaves like an operator or a chatbot. The rest is polish.

Guides and cheat sheets worth keeping

What actually pays off

Pays off:

• Anything you'd type more than once a week. A saved command beats retyping the same prompt, every time.
• CLAUDE.md rules added right after a real correction. Mistake rate drops measurably across sessions.
• Adversarial prompts — grill-me, staff-engineer review. They catch problems before a PR, not after.

Wastes time:

• A skill or command installed unread. The risk is bad instructions as often as it's security.
• Turning genuinely one-off questions into a "command." Plain prompting is faster to write once.

Measure it by: correction cycles per PR, whether the same prompt keeps getting retyped weekly, and time from "bug reported" to "fix merged." Not by whether the answers feel smarter.

Building your own library

1. Notice repetition. Anything typed more than once a week is a command or skill candidate.
2. Name it as a verb. /grill-me, /triage-issue, /techdebt read as actions, not nouns.
3. Store it properly. Commands as .md files in .claude/commands/ (project, git-shared) or ~/.claude/commands/ (personal). Skills as a SKILL.md folder.
4. Use $ARGUMENTS so one file covers many inputs — /fix-issue 123.
5. Commit it to git. The team inherits your commands and skills, not just you.
6. Vet before reuse. Read the markdown — or have someone you trust review it — before installing anyone else's skill.
7. Prune like code. Edits go through review, and commands that stop earning their keep get deleted, not accumulated.

Pitfalls

• Installing skills or commands unread. The real risk is usually bad instructions, not malice.
• Blaming the wording when the harness is broken. A well-written prompt still fails with the wrong context or missing tool access. Check those first.
• Switching review postures at random. Mixing "watch every edit" with "review the final PR" makes codebases messy. Pick one.
• Copy-pasted personas. "You are a senior X at Y" produces polished but generic output unless you fill in real specifics.
• Project-locked commands. Commands that hardcode one repo's paths or tools don't travel. Write them to be reusable across projects.