I get this question constantly. Which AI prompts do you actually use?
The honest answer is fewer than you’d think. I have a library of about 40 prompts that I’ve built and refined over the past two years — onboarding, audits, content, support, sales. But I don’t reach for 40 in any given week. I reach for about 8. They’re the ones that fit the shape of an operator’s week so cleanly that I’ve stopped writing the work without them.
This article walks through those 8. Five of them I’ll show in full — paste them into Claude, plug in your context, ship the output. The other three I’ll describe with enough detail to be useful, but the full prompts live in The AI Prompt Library for WordPress Operators along with 30+ others. The shape of those three is more involved than fits in a section of a blog post.
These are sequenced the way they show up in my actual week. Monday triage, midweek diagnostic work, Thursday client-facing writing, Friday content and outreach. Your week may run differently. The point isn’t the order — it’s the shape of what these tools actually do once they’re in your operator rhythm.
A note before the prompts: these are written for Claude (Sonnet 4.6 or Opus 4.7, current models as of mid-2026). They work in ChatGPT too, sometimes with adjustments. Where it matters, I’ll flag the difference.
1. The support request triage classifier
The first thing I do on Monday morning is read the support queue. What came in over the weekend? What’s on fire, what’s annoying, what’s not actually urgent despite the client thinking it is?
Most operators triage in their head. That works at low volume and breaks down quickly. This prompt produces consistent classification — useful when you’re the only one doing support, indispensable when there’s a team handling tickets together.
Triage the following WordPress support request. The goal is consistent classification so similar requests get handled similarly across the team and over time.
Produce a classification with these fields:
1. Urgency level (Critical / High / Medium / Low)
- Critical: production website is down or losing money right now
- High: significant functionality broken, but the website is functional; needs response within hours
- Medium: real issue but not blocking operations; standard response window
- Low: minor issue, polish, or non-urgent question
2. Category (pick the closest match):
- Site down / unreachable
- Performance issue
- Functionality broken (plugin/theme/feature)
- Security concern
- Email delivery issue
- Update or maintenance request
- Configuration change
- Content management help
- Strategic advice / non-technical
- Other (specify)
3. Estimated effort to resolve (best guess from the description):
- Quick (under 30 minutes)
- Standard (30 minutes to 2 hours)
- Substantial (2-8 hours)
- Major (over 8 hours, likely a project)
4. Suggested first action (the single most useful thing to do as the first response — clarifying question, immediate fix attempt, escalation, etc.)
5. Information gaps (what's missing from the request that would change the triage if known)
6. Communication tone needed (anxious client wanting reassurance? Frustrated client needing acknowledgment? Calm client wanting technical detail? Match the response register to the request register)
Be honest about uncertainty. If the description is ambiguous, say what's unclear and what would resolve the ambiguity. Don't classify with false confidence.
Client context:
[ENGAGEMENT TYPE, EXPECTED RESPONSE WINDOW, ANYTHING RELEVANT TO HOW THIS CLIENT SHOULD BE TREATED]
The support request (as written by the client):
[PASTE EXACT REQUEST]The output is structured across the six fields, usually 300-500 words. Drop it straight into your ticketing system, or read it as a 30-second “how should I approach this?” reference.
What I’ve learned using it: The “communication tone needed” field is the most underrated output. Operators consistently misread the tone of incoming requests — treating anxious clients as if they want technical detail, treating calm technical clients as if they need hand-holding. Forcing the classification surfaces calibration errors before you reply.
2. The intake summarizer
If a new client signed an engagement last week, Monday is when I run their intake responses through this prompt. The output becomes my reference document for the entire engagement.
The job here is translation. Raw intake form responses are useful — but only after you’ve read them carefully, found the contradictions, and noticed the things they didn’t quite say. This prompt does that reading for you and produces a structured profile you can scan in 90 seconds.
You're helping me prepare for a new WordPress engagement. Below is the intake form a new client just completed. Your job is to read it carefully and produce a structured client profile I can use as a reference document throughout the engagement.
The profile should have these sections:
1. Client Summary (2-3 sentences capturing who this client is, what their business does, and why they're hiring me)
2. Engagement Scope (a clean restatement of what they're asking for, framed in operator terms — distinguish between what's clearly in scope, what's ambiguous, and what they may want but didn't explicitly ask for)
3. Key Context (the specific details that will matter during the work — their industry, traffic levels, current stack, team composition, prior bad experiences, anything that will influence how I approach this)
4. Identified Risks (anything in the responses that suggests likely friction — unclear decision-making authority, unrealistic timeline expectations, scope creep signals, technical complexity they may not have surfaced, budget concerns)
5. Open Questions (specific things I should ask in the kickoff call to resolve ambiguity in the responses)
6. Recommended First Move (what's the highest-leverage thing to do or ask in the first 48 hours of this engagement)
Be honest. If something in the responses concerns you, say so. If something contradicts itself, flag it. The goal is for me to walk into the kickoff call already understanding this client better than they understood themselves while filling out the form.
Here are the raw intake responses:
[PASTE INTAKE RESPONSES HERE]You’ll get back a 600-900 word profile in the six sections. The “Identified Risks” and “Open Questions” sections are typically where the value lives — they surface things you’d otherwise miss on a casual read.
What I’ve learned using it: The “be honest” instruction matters. Without it, the output trends toward diplomatic and useless. With it, the output flags real concerns I would have noticed on the third re-read of the intake form — or worse, in week three of the engagement. For clients where I want maximum candor, I add a line: “Don’t soften concerns — I’d rather hear hard truths now than discover them in week three.”
3. The error log analyzer
This is the prompt I reach for more than any other in midweek diagnostic work. Logs are dense. They take an hour to read manually if you’re disciplined, longer if you’re tired. AI processes them in seconds and consistently spots patterns I would have missed on the second pass.
The prompt does three things: separates distinct issues that happen to share a log file, ranks each issue by relevance to the symptom you’re investigating, and — distinctively — surfaces what’s not in the logs that you’d expect to be.
Analyze the following WordPress error logs. The goal is to identify the most likely root causes of the issue I'm investigating, ranked by probability.
For your analysis:
1. Identify the distinct issues in the logs (multiple unrelated issues often appear in the same log file — separate them)
2. For each distinct issue, identify:
- The error pattern (what's actually being reported)
- The frequency (how often it appears in the log)
- The likely cause (what typically produces this error)
- The probability this is related to the symptom I'm investigating (high / moderate / low)
- The next diagnostic step to confirm or rule out this cause
3. Surface any patterns I might miss:
- Errors that started at a specific time (and what was happening at that time)
- Errors that correlate with traffic patterns
- Errors that cluster around specific plugins or themes
- Cascading errors (where one error causes others downstream)
4. Identify what's NOT in the logs that you'd expect to be (sometimes the absence of expected entries is the clue — e.g., if cron isn't logging anything, cron might not be running)
Order issues by relevance to my symptom (most likely related first), then by severity.
Be honest about uncertainty. If the logs don't clearly point to a cause, say so and tell me what additional diagnostic data would help.
The issue I'm investigating:
[DESCRIBE SYMPTOM — WHAT'S BROKEN, WHEN STARTED, WHO'S AFFECTED]
Recent changes:
[ANY DEPLOYMENTS, UPDATES, CONFIG CHANGES, TRAFFIC SHIFTS]
WordPress and server context:
[HOSTING, PHP VERSION, WORDPRESS VERSION, PLUGIN COUNT, ANYTHING UNUSUAL ABOUT THE STACK]
Raw logs:
[PASTE LOG CONTENT]Output is a structured analysis with probability ratings against your stated symptom and recommended next diagnostic steps. Usually 600-1,500 words depending on log complexity.
What I’ve learned using it: The “what’s NOT in the logs” instruction is the distinctive part. Most error log analysis focuses on what’s there; the absence of expected entries is often the actual clue. If WP-Cron should be logging hourly and there are no cron entries in the log file, that’s the diagnosis. For very large log files (hundreds of MB), pre-filter by timestamp or grep before pasting — focused log segments produce better output than entire dumps. And the “honest about uncertainty” instruction prevents the model from over-committing to wrong root causes, which is the failure mode that wastes more time than reading the logs manually would have.
4. The technical-to-business translator
Once I have a finding from an audit, support investigation, or diagnostic — written in operator language — this prompt translates it for the person who will actually read the report. Usually a business owner, sometimes a marketing lead, occasionally an executive. None of them should have to learn what an OPcache hit rate is in order to understand why their checkout is slow.
Rewrite the following technical finding for a non-technical business audience. The audience is a smart, busy decision-maker who is not a WordPress expert but is responsible for the business outcomes affected by this finding.
The rewrite should have three components:
1. What's happening (one paragraph, plain language, no jargon — explain the issue in terms a smart non-technical person could repeat to a colleague)
2. Why it matters (one paragraph translating the technical issue into business impact — revenue at risk, user experience degraded, security exposure, scalability ceiling, whatever applies)
3. What to do about it (one paragraph describing the fix in plain language — what's involved, roughly how long, what they need to know to approve the work)
The tone should be confident and clear, not condescending. Assume the reader is smart but doesn't know WordPress specifics. Avoid jargon, but don't oversimplify to the point of imprecision — they need enough detail to make an informed decision.
If the finding requires technical vocabulary that can't be avoided (e.g., "HTTPS," "DNS," "database query"), use the term but explain it briefly in parenthesis the first time.
Length: 250-400 words total across the three paragraphs.
Technical finding:
[PASTE THE TECHNICAL FINDING]
Business context:
[CLIENT'S INDUSTRY, BUSINESS MODEL, WHAT THEY CARE ABOUT, WHO WILL READ THIS REPORT]Three paragraphs in plain business language. Slots directly into the report as the body of a finding section.
What I’ve learned using it: The “smart but doesn’t know WordPress” framing matters. Without it, the output either patronizes (over-simplifying) or over-explains (jargon with definitions). With it, the output reads the way a senior consultant would explain the issue to their boss — confident, clear, no hedging. The “business context” input is non-optional. The same finding (say, autoload bloat) gets translated very differently for an e-commerce site (in terms of cart abandonment) versus a publication (in terms of crawl budget and SEO).
5. The tightening prompt
Friday afternoon I’m usually editing — either a draft of an article like this one, or a section of a client deliverable, or an email I want to be precise about. There are always paragraphs that say the right thing in too many words.
Tighten the following paragraph. The goal is the same meaning in fewer words. Not "shorter and dumber" — same content, less prose.
Specifically:
- Remove redundancy (where the same idea is stated multiple ways)
- Cut hedges that don't add necessary nuance ("perhaps," "it might be argued," "in some sense")
- Replace wordy phrases with cleaner ones where it doesn't damage the voice
- Combine sentences that should be one sentence
- Eliminate filler words and phrases that don't contribute meaning
What to preserve:
- The argument or point being made
- The voice and tone
- Specific examples, references, or details
- Distinctive phrasings that have personality
- Any nuance the original is doing real work to establish
Produce three versions:
1. Light tightening (10-20% shorter — preserves nearly everything, just cleaner)
2. Moderate tightening (20-35% shorter — keeps the core but cuts secondary elements)
3. Aggressive tightening (35-50% shorter — reduces to essentials only)
Below the three versions, briefly note what was cut at each level and whether the cuts cost anything.
Must preserve: [ANY SPECIFIC PHRASES OR IDEAS THAT CAN'T BE CUT]
Paragraph:
[PASTE PARAGRAPH]Three tightened versions at different compression levels, plus notes on tradeoffs.
What I’ve learned using it: Producing three versions at different compression levels is what makes this prompt earn its keep. The right level depends on context — the same paragraph might warrant light tightening if it’s central to the argument, aggressive tightening if it’s transitional, or no tightening at all if you decide on review that it’s already correct. Run it on each problem paragraph individually rather than the whole draft — paragraph-by-paragraph produces sharper output than wholesale compression.
The three I’ll describe but not fully show
The remaining three prompts are larger or more context-dependent than fits cleanly in a blog post. They live in the Library along with the example outputs and the operator notes that make them work.
The symptom diagnoser is the companion to the error log analyzer. You reach for the analyzer when you have logs; you reach for the diagnoser when you don’t. A client describes a symptom — “the checkout is slow, but only sometimes” — and the prompt generates ranked hypotheses of what to investigate, with the diagnostic step that would confirm or rule out each one. Different from the error log analyzer because it works forwards from a description rather than backwards from data. The output is a prioritized investigation list, not a conclusion. It’s the prompt that decides where I spend the next hour.
The voice-preservation editor is the bigger sibling of the tightening prompt. You feed it a full draft plus a reference sample of your writing, and it produces a revised draft that’s tighter, sharper, and structurally cleaner — without standardizing your voice into generic-good-writing. The trick is the reference sample. Without an example of your actual past work, the output reads like a competent editor’s interpretation of your topic. With one, it reads like you on a better day. This prompt is the reason I publish articles faster than I used to without losing what makes them recognizable.
The objection handler comes out on the rare Friday I have a proposal to follow up on. A prospect raised a concern during discovery, or said the price felt high, or asked about timeline flexibility — the prompt produces three response options at different registers (the direct version, the diplomatic version, the consultative version), each grounded in the specifics of the conversation. The output isn’t the email I send; it’s the structured thinking that informs the email I write. There’s a difference, and the prompt is clear about which it produces.
What 8 prompts buy you
There’s a version of using AI for WordPress work that treats it as a magic trick — paste anything, get anything, ship it. That version produces dispatchable mediocrity. The output reads like AI output, the work doesn’t compound, and the operator who relies on it never quite gets faster than they were last year.
The version that actually works is the one above. A small set of well-tuned prompts, each tied to a specific repeated task, used in sequence as the natural shape of an operator week. Eight is approximately the right number. Fewer leaves leverage on the table; more becomes a library you have to maintain instead of a workflow you actually run.
These eight come from The AI Prompt Library for WordPress Operators — a 153-page reference covering the full operator workflow: client onboarding, audit and reporting, content production, support and troubleshooting, sales and proposals. About 40 prompts in total, plus appendices on customization, building your own, and the prompts I considered but rejected.
You got five working prompts in this article. The Library gets you the other 35, with the operator notes and example outputs that make them work in real practice. Together with the WordPress + AI Stack, it’s the operator’s actual reference shelf.
The compounding return is small per prompt and large in aggregate. Eight prompts, used consistently for a year, take a week of work down to four days. That’s the real claim — not that AI does the work, but that the right prompts in the operator’s hand compound the time the operator has.
— Saber