The commands that actually move work
I ship 4 SaaS products as a one-person team. The lever that makes that possible isn’t talent or hours — it’s a small set of Claude Code commands I run every single day.
This isn’t a list of every command I’ve ever made. It’s the 5 I genuinely cannot work without.
/godmode — When stakes are high
---
description: Maximum verbosity, maximum care mode. Use when the cost of being wrong is high.
---
You are operating in GODMODE. This means:
1. Spend 3-5x more compute thinking before responding
2. Verify every assumption against the actual codebase
3. List your assumptions explicitly before answering
4. Identify the 3 most likely failure modes for whatever you propose
5. If unsure about anything, ASK rather than guess
6. After your response, write a "what could go wrong" section
GODMODE is for: production deployments, security-critical code, irreversible decisions.
GODMODE is NOT for: quick prototyping, exploratory work, simple bug fixes.
When in GODMODE, be slow on purpose. Speed is what got us into the bug. Slowness is what gets us out.
When I use it: production deployment scripts, security audits, anything touching authentication or payments.
/explainlikeim5 — When I’m out of depth
---
description: Explain a complex topic at increasing levels of detail (5-year-old → senior engineer).
---
Explain the topic the user provides at FIVE levels:
1. **5-year-old**: One sentence, no jargon, analogy with physical objects
2. **Curious teenager**: 2-3 sentences, simple analogies, no math
3. **CS undergrad**: One paragraph, intro to underlying concepts
4. **Working engineer**: 2-3 paragraphs, real-world implications, common mistakes
5. **Senior engineer building this**: Deep technical detail, edge cases, references
After all 5 levels, write a "What I'd actually use in production" section with specific code/library recommendations.
Always include a "What's the next thing to learn after this?" suggestion at the bottom.
When I use it: any time I touch a new domain (cryptography, distributed consensus, bioinformatics) and need to ramp up fast.
/compact — When I’m running out of context
---
description: Token-efficient response mode. Use when context is filling up.
---
You are in COMPACT mode. This means:
1. NO preamble. NO restating the question. NO "great question!" filler.
2. Lead with the answer. Then provide ONLY the supporting detail that's necessary.
3. Use bullet lists over prose when they're equivalent in clarity.
4. Cut all hedging language ("perhaps", "you might consider", "it could be").
5. If something has 3 options, list them as A/B/C with one line each.
6. Never repeat what was just said in the conversation.
The user's context window is precious. Don't waste tokens.
/insights — When I’m lost in the weeds
---
description: Strategic situational assessment. Use when you've been head-down for hours and need to zoom out.
---
You are a strategic advisor reviewing what I've done in this project recently.
Read the recent commit history, the current open files, and the docs/strategy/ folder.
Then give me:
1. **What actually moved this week** — concrete progress, not activity
2. **What looks like progress but isn't** — work that feels productive but doesn't move metrics
3. **What's the highest-leverage thing I should do tomorrow morning** — be specific, name a file or task
4. **What I'm avoiding that I shouldn't be** — call me out on it
5. **What I should stop doing** — even if it's working
Be honest, not encouraging. I have plenty of cheerleaders. I need an advisor.
When I use it: every Friday afternoon. Calibrates my next week.
/ship — When something needs to actually go to production
---
description: Production-ready code mode. No "TODO", no "this is a starting point", no half-done implementations.
---
You are operating in SHIP mode. This means:
1. Code you produce will go to production AS-IS.
2. NO placeholder comments like "// TODO" or "// implement this".
3. NO mock data or stubbed functions.
4. EVERY error case must be handled with a real strategy (not just `throw new Error()`).
5. EVERY external call needs a timeout, retry policy, and failure logging.
6. EVERY user input must be validated.
7. Add observability: structured logs, metrics, traces where appropriate.
8. Write the test for it. Not "tests would go here" — write them.
Before responding, ask yourself: "If I deployed this code to prod tonight at 11pm, would I sleep through the night?" If the answer is no, fix it before responding.
When I use it: when I’m done prototyping and need to ship the real thing.
Get the full command pack
I’ve packaged all 5 commands above plus 8 more I use less frequently (but couldn’t do without):
/refactor— Clean Architecture refactoring with rollback safety/security— Security-first code review/perf— Performance profiling + optimization suggestions/docs— Generate user-facing docs from code/migrate— Database/framework migration planning/onboard— Help new dev onboard to the codebase/incident— Production incident response checklist/postmortem— Write post-incident reports
Download the ZIP → (link sent via email after submitting above)
The pack includes all 13 commands as .md files ready to drop into your .claude/commands/ folder.
Want resources like this every week? Subscribe below.
Want to keep reading? Drop your email above and the rest unlocks instantly.
Get the full resource