50+ prompts that actually work. Searchable. Copy-paste ready. Every prompt tested in real production sessions with Claude Code.
Interview me about [feature] using AskUserQuestion. Ask about implementation, edge cases, tradeoffs. Don't ask obvious things. When done, write spec to SPEC.md
When to use: Starting any non-trivial feature. Forces you to think through requirements before writing code.
Review all changed files. For each: 1) security issues (OWASP top 10), 2) N+1 queries, 3) missing input validation. Label severity.
When to use: Before merging any PR. Catches the three most common production issues in one pass.
You are a senior engineer with no patience for bad code. Review src/auth.ts. Start with the riskiest issue. No warm-up.
When to use: When you want unfiltered, prioritized feedback on a critical file.
Spawn 3 agents in parallel: Agent 1 investigates [bug] assuming race condition. Agent 2 assuming memory leak. Agent 3 assuming auth expiry. First to find root cause wins.
When to use: When you have a tricky bug and want to test multiple theories simultaneously.
Find all usages of [old_api] in src/. List them. Then migrate each file one by one, running tests after each change.
When to use: Migrating deprecated APIs safely. The one-by-one approach catches regressions early.
Analyze our codebase for N+1 queries. Search for patterns like loop + database call. Return file:line for each.
When to use: Performance audit. N+1 queries are the most common hidden performance killer.
Create a SPEC.md for [feature] that covers: data model, API contract, edge cases, test scenarios, rollback plan.
When to use: Before building any feature that touches the database or has external dependencies.
Review this PR as if you are a paranoid security engineer who has been burned before. Focus on: auth bypass, input validation, secrets exposure.
When to use: Any PR that touches authentication, authorization, or user input handling.
/batch refactor all components in src/components/ to use the new design system. Each component in its own PR.
When to use: Large-scale refactors. Isolating each change makes review and rollback possible.
Walk me through the auth flow step by step. Read the files as you go. Draw an ASCII diagram of the flow.
When to use: Onboarding to a new codebase or documenting an existing flow for the team.
Scan the entire codebase for patterns matching API keys, tokens, passwords. Flag any that look hardcoded. Report file:line.
When to use: Before any public release, after onboarding new developers, or during periodic audits.
Review src/auth/ for these vulnerabilities: JWT algorithm confusion, token expiry bypass, privilege escalation. Be specific.
When to use: When auth is business-critical. These three are the most exploited auth vulnerabilities.
You are running a penetration test on our API. Describe the 5 most likely attack vectors based on the code you see.
When to use: Before launching a public API. Gets you attacker-mindset analysis without hiring a pen tester.
Check every SQL query in the codebase. Flag any that use string concatenation instead of parameterized queries.
When to use: Any project with raw SQL. Parameterized queries are the only reliable defense against SQLi.
List every place in the codebase where user input touches a shell command, file path, or database query without sanitization.
When to use: Security audit. These three input vectors cover the majority of injection attacks.
Review our .gitignore. List any sensitive file types that are NOT ignored that should be.
When to use: Project setup, before first commit, or after adding new tools that create config files.
Find all environment variables used in the code. Cross-reference with .env.example. Flag any that are used but not documented.
When to use: Onboarding new devs, debugging deployment issues, or documenting setup requirements.
Generate a security checklist for this PR. Cover: OWASP top 10, secrets exposure, rate limiting, auth checks.
When to use: Every PR that touches backend logic. Paste the checklist into the PR description.
Before we start: ask me one question at a time about the context I need you to know for this session. Stop when you have enough.
When to use: Start of any complex session. Prevents Claude from guessing and making wrong assumptions.
Summarize what we've accomplished so far in this session in 5 bullet points. Then clear your context.
When to use: When your session is getting long and Claude starts losing track of earlier decisions.
/compact focus on the auth changes only. Forget everything else.
When to use: When context is bloated and you need Claude to focus on one specific area.
I want to build [X]. Interview me about the requirements, edge cases, and constraints. Write the full spec to SPEC.md. I'll start a fresh session to implement it.
When to use: Large features. Splitting spec and implementation into separate sessions keeps context clean.
What are the 3 most important things you've learned about this codebase that I should add to CLAUDE.md?
When to use: End of productive sessions. Captures institutional knowledge so future sessions start smarter.
You are reading a large codebase. Before touching any code, map the architecture in a single ASCII diagram. Confirm you understand it before proceeding.
When to use: First session on an unfamiliar codebase. Prevents Claude from making changes that break architecture.
Spawn 5 agents in parallel. Each takes one client folder from [list]. Each reads Progress.md and Communication-Log.md. Returns: blockers + next action. Merge into one dashboard.
When to use: Weekly client review. Gets status on all clients simultaneously instead of reading files one by one.
Spawn one agent per file in src/api/routes/. Each runs a security review. Output JSON: {file, issues:[]}. Collect all results and merge into security-report.md.When to use: Full codebase security audit. Parallelizes what would otherwise be a serial, hours-long review.
Create a writer-critic loop: Agent 1 implements [feature]. Agent 2 reviews it as a paranoid senior engineer. Agent 1 addresses the critique. Repeat until Critic has no critical issues.
When to use: High-stakes features where quality matters more than speed. Simulates a real code review cycle.
Use /batch to migrate all Python 2 print statements to Python 3 syntax in src/. Each file in its own worktree. Open PRs for all.
When to use: Mass migrations. Each file gets its own isolated branch, making review and rollback granular.
I need [feature] built end to end. Spawn: Agent A for the database schema, Agent B for the API layer, Agent C for the tests. Coordinate and merge.
When to use: Building a complete feature fast. Each layer gets focused attention from a dedicated agent.
Research 10 competitors in [space] in parallel. One agent per competitor. Each outputs: positioning, pricing, key differentiator. Merge into competitor matrix.
When to use: Market research phase. Gets 10 competitor analyses done in the time one would take.
The bug is [describe]. Slow down. Ask me one question at a time. Don't jump to solutions. First map every possible cause.
When to use: When you are stuck. Prevents Claude from jumping to the first solution and missing the real issue.
Read /debug session log. Tell me what went wrong, why, and what the permanent fix is (not just the workaround).
When to use: After resolving a bug. Distinguishes between band-aids and real fixes.
Walk me through this error like I'm not technical. Then show me the fix. Then explain how to prevent this class of error.
When to use: When you want to understand the error deeply, not just fix it. Great for learning.
I can't reproduce this bug. Generate 5 competing hypotheses. For each: what evidence would confirm it, and where in the code to look.
When to use: Intermittent or hard-to-reproduce bugs. Gives you a structured investigation plan.
This test is failing intermittently. Find every possible source of non-determinism in this test. List them with likelihood.
When to use: Flaky tests. Common sources: time, random, network, shared state, async race conditions.
Explain this function like I've never seen it before. Then tell me what happens if [edge case]. Then show the test that would catch it.
When to use: Understanding unfamiliar code and immediately hardening it with tests.
Every morning: read 00_Inbox/. Process each item: extract actions, route to right PARA folder, update relevant client files. Output: list of actions.
When to use: Daily inbox zero routine. Turns a 30-minute manual task into a 2-minute AI task.
/loop 30m check all open GitHub PRs. Flag any open more than 48 hours with no activity. List with links and assignees.
When to use: Team management. Catches PRs that are silently stalling before they become blockers.
Set up a hook that runs ESLint on every file I edit. If errors found, fix them automatically. If unfixable, show me the errors.
When to use: Project setup. Keeps code style consistent without manual effort.
Build a pre-commit hook that: 1) runs tests, 2) checks for secrets in changed files, 3) blocks commit if either fails.
When to use: Any production project. Prevents the two most common commit mistakes: broken tests and leaked secrets.
Create a GitHub Action that runs when any PR is opened. It should: review for breaking changes, flag missing tests, check for secrets.
When to use: Team projects. Automates the first pass of code review so humans focus on logic, not hygiene.
Watch the deployment logs at [URL]. Message me on Slack if: response time > 2s, error rate > 1%, or any 5xx appears.
When to use: Post-deployment monitoring. Catches issues before users report them.
Write this content in my voice. Read @02_Areas/Marketing/Content_Strategy/walid-writing-style.md first. Then write [content]. No corporate language.
When to use: Any content creation. The @ reference loads your actual writing style so output matches your voice.
Turn these raw notes into a LinkedIn post. Direct, no fluff, specific. Under 1300 chars. Hook on line 1.
When to use: When you have ideas but not time to craft them. Converts rough thoughts into publish-ready posts.
I have [result/win]. Write 5 different angles for LinkedIn posts about it. Each under 200 chars for the hook. Different formats.
When to use: Maximizing content from a single win. One result can fuel a week of different posts.
Read my last 5 posts in 02_Areas/Marketing/Content_Strategy/. Find the patterns. Then write a new post about [topic] following those patterns.
When to use: Maintaining consistency. Claude learns your actual patterns rather than guessing.
Create a content calendar for the next 30 days around [theme]. Each post: hook, angle, format, CTA. Save to content-calendar.md.
When to use: Monthly content planning. Gets you from zero to a full month of planned content in one session.
Read everything in 01_Projects/Clients/[client]/. Give me: current blockers, next 3 actions, anything I might be forgetting.
When to use: Before any client interaction. Surfaces forgotten tasks and keeps nothing from slipping through.
I'm preparing for a call with [client]. Read their folder. Generate: 5 discovery questions, likely objections with responses, recommended next step.
When to use: 15 minutes before any client call. Shows up prepared without spending an hour re-reading files.
Write a proposal for [client] based on the discovery notes in their folder. Use the 1-hour analysis framework. Include ROI calculation.
When to use: After a discovery call. Turns raw notes into a professional proposal in minutes.
Research [company/person] as a prospect. Score them against our ICP. Find 3 specific pain points I can reference in outreach.
When to use: Before cold outreach. Personalized pain points convert 3-5x better than generic messages.
I just finished a project for [client]. Extract the win metrics from their Progress.md. Write a case study in: problem --> solution --> results format.
When to use: After every successful project. Case studies are the highest-converting sales asset.