Claude Code Slash Commands That Save Real Hours

Most Claude Code content focuses on the obvious: ask it to write a function, fix a bug, explain a dependency. That’s table stakes. The workflow that actually changed how I work is custom slash commands — specifically, a /security-review command I built that replaced a 90-minute manual checklist with a consistent, repeatable, sub-5-minute pass I can run before every PR.

This is a Wednesday post, which means practical and implementation-focused. Here’s exactly what I built, why, and the numbers behind it.

What Claude Code Slash Commands Actually Are

If you haven’t dug into this: Claude Code supports custom slash commands defined as Markdown files in .claude/commands/. You create a file, give it a name, write the prompt inside it, and it becomes a repeatable command you can invoke from the Claude Code interface with /your-command-name.

That’s it. There’s no SDK to configure, no plugin system to register with. It’s a Markdown file. The simplicity is the point.

Where most people stop is at generic commands — /explain-this, /write-tests. Those are fine. What I wanted was something with domain-specific logic baked in: a security review that reflects 25 years of patterns I’ve actually seen blow up in production.

The Problem I Was Solving

My manual pre-PR security review looked like this:

• Check for hardcoded credentials or tokens (grepping for common patterns)
• Review IAM scope of any new service accounts or roles being created
• Trace data flow for any new endpoints handling PII or sensitive input
• Confirm logging is in place for authentication events
• Verify no new third-party dependencies added without a quick provenance check
• Check for SQL or prompt injection vectors in any new input handling
• Review error messages for information disclosure risk

Seven categories. If I was being disciplined about it, 60–90 minutes. If I was in a hurry — which is most of the time when a PR is ready to merge — it became a skim that missed things.

I’ve seen what a skim misses. I didn’t want to keep relying on discipline when I could encode the checklist into a command.

Building the /security-review Command

The command lives at .claude/commands/security-review.md. The full content:

You are performing a security review of the current git diff or the files I specify.
Apply the following checklist and report findings by category. Flag anything that
needs attention with [RISK] and explain why in one sentence. If a category is clean,
say so explicitly — don't skip it.

**Checklist:**

1. **Credential exposure** — Hardcoded secrets, tokens, API keys, passwords, or
   connection strings in any file including config and test files.

2. **IAM scope** — Any new roles, policies, or service accounts. Flag if scope
   appears broader than the function requires. Apply least-privilege assessment.

3. **Input handling** — New endpoints, functions, or agent tools accepting external
   input. Check for injection risk (SQL, prompt injection, path traversal, command
   injection).

4. **PII and data flow** — Any new handling of user data, authentication data,
   or fields that could be sensitive. Confirm logging is appropriate (not logging
   sensitive fields).

5. **Third-party dependencies** — New packages or imports not previously in the
   project. Flag anything without clear provenance or with known vulnerability history.

6. **Error handling and information disclosure** — Stack traces, internal paths,
   or sensitive context surfaced in error responses.

7. **Authentication and authorization** — New routes, tools, or functions that
   bypass or lack auth checks.

Output a report with one section per category. End with a PASS / NEEDS ATTENTION /
BLOCK recommendation and a one-line rationale.

That’s the entire command. No magic. The structure matters more than the length.

What It Changed in Practice

I’ve been running this for about six weeks across the ABT codebase. The numbers:

Before: Manual checklist, 60–90 minutes per significant PR, often skipped or rushed under time pressure.

After: /security-review runs in 3–5 minutes. I review the output, push back on anything I disagree with, and move on.

Three findings from the past six weeks that I would likely have missed in a rushed manual pass:

1. A new Lambda function that logged the full event object on exceptions — which included API gateway headers that could contain auth tokens. Caught under category 4 (PII and data flow). Low severity, easy fix, exactly the kind of thing a skim misses.

2. A test fixture that had a hardcoded fake AWS access key — the right format, obviously not real. Flagged under category 1. Worth knowing because tools like git-secrets or truffleHog would have triggered on it too.

3. A new tool definition for the agent that accepted an arbitrary file path parameter with no validation. Flagged under category 3 as a path traversal risk. I hadn’t thought about it that way when I wrote the tool — I was thinking about functionality, not attack surface.

None of these were critical production vulnerabilities. All of them were exactly the kind of low-grade risk accumulation that eventually becomes a problem.

Why This Works (and Where It Doesn’t)

The command works because it’s specific. Generic prompts get generic output. A checklist with defined categories, explicit flagging instructions, and a forced output structure gives Claude Code something to actually execute against — not interpret.

The PASS / NEEDS ATTENTION / BLOCK output format was intentional. I wanted a signal I could act on in ten seconds, not a narrative I had to parse. That’s how I write checklists for human reviewers too.

Where it doesn’t fully replace human review:

• Architecture decisions. The command looks at diffs, not the system as a whole. It won’t catch a design choice that’s fine in isolation but creates risk at scale.
• Business logic vulnerabilities. Authorization logic that’s technically correct but semantically wrong (e.g., a permission check that’s too broad for the use case) requires understanding the domain.
• Novel attack patterns. The checklist reflects what I know. It won’t catch what nobody’s seen yet.

I’m explicit about this with myself: /security-review is a forcing function for consistency, not a replacement for architecture review or threat modeling.

The Security Posture Argument for Custom Commands

Here’s the framing I’d give a CISO or engineering lead considering this approach:

Every security team has checklists. Most of them live in Confluence, get updated twice a year, and get skipped under deadline pressure. Custom slash commands don’t eliminate human judgment — they make the baseline repeatable and frictionless enough that developers actually run it.

The risk of a tool like this isn’t that it fails occasionally. The risk is over-trust: a developer sees PASS and stops thinking. The command output is a starting point, not a finding. Engineering culture has to understand that distinction.

Mitigation: I include a note in the team documentation (such as it is, working solo) that the command augments review, doesn’t replace it. When I eventually work with other engineers, that framing goes into onboarding.

Two Other Commands Worth Building

While I’m here, two other slash commands I’ve added that pay off regularly:

/dependency-audit — Takes a new package name as input. Prompts Claude Code to summarize what the package does, check for known CVEs in recent releases, identify if it’s widely maintained or abandoned, and flag any suspicious permissions it requests. Not a replacement for npm audit or pip-audit, but a first-pass context layer before I add anything to the project.

/commit-message — Generates a structured commit message from the current diff following conventional commit format. This sounds minor. It saves about three minutes per commit and produces consistent, searchable history. Over 200 commits, that’s 10 hours.

Key Takeaways

• Claude Code slash commands are Markdown files in .claude/commands/ — no configuration, no plugin system, just a structured prompt
• The /security-review command I built runs a 7-category checklist in 3–5 minutes, replacing a 60–90 minute manual process
• Specific output structure (PASS / NEEDS ATTENTION / BLOCK) makes the result actionable in seconds
• Custom commands work best for repeatable, checklist-driven tasks — they don’t replace architecture review or threat modeling
• The security risk to watch: over-trust in PASS output. Make the scope of the tool explicit to anyone who uses it
• Start with one command for the highest-friction checklist you currently skip. The ROI is immediate.

The /security-review command is the one I’d recommend starting with. If your team has a security checklist that exists in a doc but doesn’t get run consistently, that’s your command. Encode it, make it frictionless, run it every time.