DEV Community: draftkit

10 AI Prompts I Use for Financial Analysis (FP&A, Models, Investor Memos)

draftkit — Tue, 21 Jul 2026 17:33:43 +0000

I work in finance — the kind of work where a wrong number in cell F42 becomes a problem in a board meeting. For a long time I treated AI as a writing assistant and nothing more. Then I started writing structured prompts for the analytical work itself: explaining variances, sanity-checking models, drafting investor commentary, and turning a mess of department inputs into a coherent narrative.

These prompts don't replace the spreadsheet. They replace the hour I used to spend staring at a variance trying to find the words, or the hour I spent rewriting a memo because the first draft buried the only number the CFO cared about. Here are ten I use regularly.

How these prompts are structured

Each one has four parts:

Role — a specific persona with expertise and a point of view.
Context — the actual numbers, draft, or scenario (paste it in).
Constraints — hard rules the output must obey.
Output — the exact format I want back.

The constraints are where the value is. An unconstrained "explain this variance" prompt produces a paragraph of hedging. A constrained one produces a decision-ready answer.

1. The variance explanation that leads with the number

Role: You are an FP&A manager writing a variance commentary for a CFO who reads 40 of these a month. You lead with the number, never with the narrative.

Context: Actual was $[X]. Budget was $[Y]. The variance is $[X-Y]. Here is what drove it: [LIST THE DRIVERS — e.g., "software revenue came in $40k above plan due to 2 enterprise deals closing early; consulting revenue was $15k below due to a project slipping to next month"].

Constraints:

First sentence must state the variance direction and dollar amount. Example shape: "Revenue came in $25k above plan (12% favorable)."
Then list the drivers in descending order of dollar impact.
Do not use the word "primarily" or "mainly" without a number attached.
Do not open with "Overall," "In general," or "For the period."
If a driver is unfavorable, say so plainly — no "headwinds," no "softness."

Output: 4-6 sentences. No paragraphs longer than 3 sentences.

This is the prompt that fixed my commentaries. The constraint "first sentence states the number" eliminates the 200-word throat-clearing that makes variance reports unreadable.

2. The model sanity check

Role: You are a financial modeler auditing a colleague's model for the five most common errors before it goes to the investment committee.

Context: Here are the key outputs of the model: [PASTE REVENUE PROJECTIONS, MARGINS, CASH BALANCE FOR YEARS 1-5]. Here are the key assumptions: [PASTE GROWTH RATE, PRICING, CAC, CHURN, etc.].

Constraints:

Flag any year where revenue growth accelerates without a stated driver in the assumptions.
Flag any year where gross margin moves more than 5 points without explanation.
Flag if cash balance hits zero in any year (funding gap).
Flag if CAC payback exceeds 24 months.
Flag if the terminal growth rate exceeds the long-term GDP growth assumption.
For each flag, state the specific cell/line and the specific concern in one sentence.

Output: A numbered list of flags. If no flags, say "No flags" — do not invent concerns.

The "do not invent concerns" constraint is critical. AI will manufacture problems to seem thorough. You want it to only surface real ones.

3. The investor memo draft (from bullet points)

Role: You are a CFO's chief of staff drafting the monthly investor update. You know investors read the first paragraph and skim the rest, so the first paragraph must contain the three things they actually care about.

Context: Here are this month's raw notes in bullet form: [PASTE MESSY BULLETS — revenue, hires, product, asks, lowlights].

Constraints:

Paragraph 1 (the "headline paragraph"): revenue vs plan in one sentence, cash runway in months in one sentence, the single most important thing that happened this month in one sentence.
Then four labeled sections: Highlights, Lowlights (mandatory — do not omit), Asks (specific, not "intros welcome"), Hiring.
Each section: max 3 bullets, each bullet a complete sentence with a specific number or name.
Do not use the words "excited," "thrilled," "pleased to announce," or "milestone."
The Asks section must contain at least one specific request (a name to meet, a role to fill, a customer intro), not "we'd love introductions."

Output: The memo, ready to edit. No placeholder text.

Forcing the lowlights section is the constraint that builds trust. Investors discount updates that only report good news.

4. The board-deck commentary for a single slide

Role: You are a strategy consultant writing the speaker notes for a single board slide. The CEO will read these notes verbatim if nervous, so they must sound like a person, not a slide.

Context: The slide title is: [TITLE]. The slide shows: [DESCRIBE THE CHART — e.g., "a bar chart of ACV by customer segment for the last 4 quarters"]. The one point the CEO wants the board to take away is: [THE TAKEAWAY].

Constraints:

Write 90-120 words of speaker notes.
Open with the takeaway, not the data description ("What this shows is that mid-market ACV has stabilized" — not "This chart displays...").
Reference one specific number from the chart.
End with the implication or the ask, not with a description of the chart.
No bullet points in the notes — flowing prose.

Output: The speaker notes.

5. The "what would kill this deal" red-team prompt

Role: You are a skeptical due-diligence analyst. Your job is to find the three reasons this investment would lose money, even if you're bullish on the business.

Context: Here is the investment thesis and the key metrics: [PASTE].

Constraints:

Identify the three highest-velocity risks — the things that would go wrong fastest if they go wrong.
For each risk, name the specific metric or assumption that would prove the risk is materializing (a "canary" metric).
Rank by speed of onset, not by magnitude.
Do not include generic risks like "competition" or "macro" unless tied to a specific assumption in the thesis.
Do not hedge — state each risk as a conditional that could be true.

Output: Three risks, each with: the risk, the canary metric, and the onset speed.

The "specific canary metric" constraint forces specificity. "Competition" is not a risk; "if CAC rises 30% in two quarters while organic search stays flat, we've lost positioning" is.

6. The scenario commentary (bear / base / bull)

Role: You are a CFO explaining three scenarios to a board that wants to know which triggers would move you from one to another.

Context: Bear case: [SUMMARY + KEY NUMBER]. Base case: [SUMMARY + KEY NUMBER]. Bull case: [SUMMARY + KEY NUMBER].

Constraints:

Write a 3-paragraph commentary.
Paragraph 1: state the spread between bear and bull in one number (e.g., "$8M revenue spread").
Paragraph 2: name the two variables that explain 80% of the spread.
Paragraph 3: the specific trigger that would move the company from base to bear, and the specific trigger that would move it from base to bull — each tied to a measurable threshold, not a vibe.
Do not say "we remain cautiously optimistic."

Output: Three paragraphs, labeled.

7. The KPI dashboard narrative

Role: You are a RevOps analyst writing the Monday-morning Slack summary of last week's metrics. The leadership team reads this on their phones before 9am.

Context: Here are last week's KPIs vs target: [PASTE — e.g., "MRR $420k vs target $415k; new logos 12 vs target 15; churn 1.2% vs target 1.5%; pipeline $1.9M vs target $2.2M"].

Constraints:

First line: one word — "Green," "Yellow," or "Red" — based on whether the majority of KPIs hit target.
Then exactly 3 bullets: the best metric (with the delta), the worst metric (with the delta), and the one metric most likely to move next week.
Total length under 100 words.
No commentary longer than one sentence per bullet.

Output: Slack-ready summary.

This replaced a 400-word Monday email nobody read. The "one word first" constraint forces a verdict instead of a hedge.

8. The financial glossary entry (for non-finance readers)

Role: You are a finance educator writing for smart non-finance people — engineers, designers, founders who need to understand a term to do their jobs, not to pass the CFA.

Context: Define this term for an internal wiki: [TERM].

Constraints:

Definition in one sentence, plain English, no jargon in the definition itself.
Then a 2-sentence example using a concrete small-business scenario (not a public company).
Then: "What it is NOT" — one sentence clarifying the most common confusion.
Max 80 words total.

Output: The glossary entry.

The "what it is NOT" constraint is the one that makes these useful. Most confusion in finance is between adjacent terms (EBITDA vs cash flow, gross margin vs contribution margin) and the disambiguation is what actually teaches.

9. The quarterly business review (QBR) narrative

Role: You are a consulting manager drafting the narrative arc of a QBR. You know the audience (a client's leadership team) will remember the story, not the slides.

Context: Here are the quarter's results and themes: [PASTE — wins, misses, strategic shifts, next-quarter focus].

Constraints:

Write a 4-section narrative.
Section 1 ("Where we said we'd be"): restate last quarter's commitments and mark each met / missed / partial.
Section 2 ("Where we are"): the actual results, leading with the miss if there was one (do not bury it).
Section 3 ("What changed"): the 1-2 strategic shifts made this quarter and why.
Section 4 ("Where we're going"): next quarter's 3 commitments, each measurable.
No section longer than 150 words.

Output: Four labeled sections.

Leading with the miss in section 2 is the constraint that makes QBRs credible. Burying a miss in slide 14 is how trust erodes.

10. The "translate this for the CEO" prompt

Role: You are a chief of staff translating a technical finance memo into language a non-financial CEO can act on in the next 10 minutes.

Context: Here is the memo: [PASTE].

Constraints:

Produce a 5-bullet summary.
Bullet 1: the decision being asked for, in one sentence.
Bullet 2: the cost or risk of the decision, in one number.
Bullet 3: the cost or risk of NOT deciding, in one number.
Bullets 4-5: the two most important caveats.
Remove every piece of jargon. If "EBITDA" or "net working capital" appears, replace with the plain-English equivalent on first use.

Output: Five bullets. No preamble.

This prompt exists because too many memos are written for the author, not the reader. The constraint "the decision in one sentence" forces the memo author to know what they're actually asking for.

A note on using AI with financial data

Be deliberate about what you paste. I never paste customer names, deal-specific pricing, or anything contractually confidential into a third-party model. I paste structures, formats, and numbers with labels stripped or generalized. The prompts above are designed to work with the shape of the analysis — they don't need the actual sensitive figures to be useful. A variance explanation prompt works whether the variance is $25k or $2.5M; the structure is the same.

If your organization has an approved internal AI environment, use that for anything sensitive. If not, sanitize first.

How I test a finance prompt

Three runs on the same input. I'm looking for structural consistency (the output always leads with the number, always lists drivers by magnitude) but acceptable variation in phrasing. If the output changes its structure between runs, the prompt's constraints are too loose for work where consistency matters. Tighten until the structure is reliable, then trust it.

The goal isn't to remove judgment — it's to remove the blank-page tax. Every one of these prompts replaces 20-60 minutes of "where do I start" with a draft I can edit in five.

If these were useful, I maintain a larger library of tested prompts for the full range of operational work — product management, engineering management, marketing, customer support, data analysis, recruiting, sales, and more. The Developer Product-Launch Prompt Pack is the $9 entry point, and the full set is on my Gumroad storefront.

Every prompt in the packs uses the same Role → Context → Constraints → Output structure and the same emphasis on hard constraints over verbosity.

10 AI Prompts I Use for Content Creation (YouTube Scripts, Blogs, Newsletters)

draftkit — Tue, 21 Jul 2026 17:33:07 +0000

I write for a blog, a weekly newsletter, and a YouTube channel. For two years I did it the slow way: stare at a blank doc, draft, rewrite, scrap, draft again. Then I built a small set of AI prompts that handle the mechanical 70% of content work — the structure, the hooks, the repurposing — so I can spend my time on the 30% that actually requires taste.

These aren't "write me a blog post" prompts. Those produce generic filler. Each one below is a structured prompt with a defined role, real constraints, and a specific output format. I've tested every one on real content over months. Here's what works.

How these prompts are structured

Every prompt follows the same four-part shape:

Role — who the AI is pretending to be (e.g., "a YouTube script editor who has worked on channels with 1M+ subscribers").
Context — the raw material you're feeding it (your outline, a rough draft, source notes).
Constraints — the rules it cannot break (word counts, banned phrases, tone).
Output — the exact format you want back.

The constraints are the part most people skip, and they're the part that separates usable output from generic mush.

1. The 15-second hook rewriter

Role: You are a YouTube script editor who has worked on channels with over 1 million subscribers. You specialize in the first 15 seconds — the window where viewers decide to stay or leave.

Context: Here is the opening of my script: [PASTE OPENING]

Constraints:

Rewrite the first 15 seconds (about 40 words spoken).
Open with a specific, concrete statement — not a question, not "in this video," not "today we're going to."
The hook must make a promise the rest of the video keeps.
Do not use the words "ultimate," "comprehensive," "everything you need to know," or "deep dive."
Do not start with "Hey guys" or "Welcome back."

Output: Three different 15-second openings. Label them A, B, C. After each, write one sentence explaining why it works.

This forces variety and forces me to pick instead of accept. A good hook makes a specific claim ("This keyboard shortcut saved me 4 hours last week") rather than a vague one ("Keyboard shortcuts are important").

2. The blog intro that earns the scroll

Role: You are a magazine editor who rejects 90% of submissions in the first paragraph. You know readers decide whether to continue within three sentences.

Context: Here is my article topic and rough first paragraph: [PASTE]

Constraints:

Write a 3-sentence intro.
Sentence 1: a specific, surprising fact or scene — not a definition, not a question.
Sentence 2: the tension or problem that fact creates.
Sentence 3: what the reader will walk away able to do.
Banned openers: "In today's world," "It's no secret that," "In recent years," "With the rise of."
Banned phrases: "game-changer," "revolutionize," "delve into," "navigate the complexities."

Output: Two intro options. Then a one-line note on which you'd publish and why.

The ban list is the real work here. AI defaults to those phrases because they're statistically common in training data — which is exactly why they signal "generic" to any experienced reader.

3. The newsletter subject line generator

Role: You are an email strategist who has written subject lines for newsletters with open rates above 50%.

Context: This week's newsletter is about: [ONE SENTENCE SUMMARY]. The key insight readers will care about is: [THE INSIGHT].

Constraints:

Write 8 subject line options.
Max 45 characters each.
No clickbait — the subject must be deliverable on by the email.
No emojis.
No ALL CAPS words.
At least 2 must be curiosity-driven (tease the answer), at least 2 must be benefit-driven (state the payoff), at least 2 must be specific (include a number).

Output: 8 options in a numbered list. After each, label it [curiosity], [benefit], or [specific].

The labeling forces the AI to actually distribute across strategies instead of producing 8 variations of the same idea.

4. The one-to-many repurposer

Role: You are a content operations lead at a media company. Your job is to turn one strong piece of content into a full week of derivative content without duplicating it.

Context: Here is my finished [BLOG POST / VIDEO SCRIPT / PODCAST NOTES]: [PASTE]

Constraints:

Produce: 3 tweets (each under 280 chars, each a standalone idea, no threads), 1 LinkedIn post (130 words, one specific takeaway, no humblebrag openers), 1 newsletter teaser (2 sentences, link-style), 5 short-form video hooks (each a single sentence).
Each derivative must contain at least one idea NOT stated identically in the source — rephrase, extract a sub-point, or take a contrarian angle.
Do not repeat the original's opening line in any derivative.

Output: Group by platform with clear headers.

This is the prompt that compounds. One strong blog post becomes a week of social presence, and the "no identical phrasing" constraint prevents the lazy copy-paste that makes cross-posting feel spammy.

5. The script outline that holds attention

Role: You are a YouTube producer who has planned scripts that average 8+ minutes of watch time. You think in open loops — questions raised early that are only answered later.

Context: My video topic is: [TOPIC]. My target length is [X] minutes. The one thing viewers must understand by the end is: [KEY TAKEAWAY].

Constraints:

Produce a section-by-section outline.
Open with a 15-second hook (unanswered question or counterintuitive claim).
Identify 2 "open loops" — sub-questions raised in the first third that are only resolved in the last third.
Place the most counterintuitive point in the middle, not the end (viewers who might click away get re-hooked).
Do not write "intro" and "outro" as sections. Give each section a concrete title.

Output: Outline with timestamps. Mark open loops with ⟲ and where they close with ⟲✓.

Open loops are the retention mechanic that most creators never use deliberately. This prompt forces them into the structure.

6. The blog section that doesn't pad

Role: You are an editor who cuts 30% of every draft. You believe every paragraph must either advance the argument or provide necessary context — never both at once, and never neither.

Context: Here is a section of my draft that feels weak: [PASTE SECTION]

Constraints:

Rewrite the section in fewer words than the original.
Cut any sentence that restates the previous one in different words.
Cut any sentence that begins with "It's important to note that" or "It's worth mentioning that" — if it were important, it wouldn't need that preamble.
Replace any abstract claim with a concrete example. If you can't, cut the claim.
Output must be at least 20% shorter than the input.

Output: The tightened section. Then the count: original words → new words.

Forcing the word-count reduction is the constraint that does the work. Without it, the AI preserves your flab out of politeness.

7. The meta description that earns the click

Role: You are an SEO copywriter who writes meta descriptions with above-average click-through rates. You know the description is a sales pitch, not a summary.

Context: My article URL is [URL]. The article title is [TITLE]. The main benefit to the reader is: [ONE PHRASE].

Constraints:

Write 5 meta descriptions, max 155 characters each.
Each must contain the primary keyword naturally.
Each must end with an implied reason to click (a specific payoff, not "learn more").
No two can share the same opening three words.

Output: 5 options, each with a character count.

8. The FAQ section generator (for SEO and genuine usefulness)

Role: You are a content strategist who adds FAQ sections that answer questions real people search for — not invented questions.

Context: My article topic is [TOPIC]. Here is the article: [PASTE OR SUMMARIZE].

Constraints:

Generate 6 questions a reader might have AFTER finishing this article — things the article implies but doesn't fully answer.
For each question, write a 2-3 sentence answer.
Each answer must add information not already stated verbatim in the article.
Do not include "What is [topic]?" — assume the reader has read the article.

Output: Q&A format, question as H3, answer below.

This adds SEO surface (FAQs often win featured snippets) without the stale "What is X?" padding that signals low-effort content.

9. The "is this done?" self-editor

Role: You are a ruthless editor. Your job is to find the weakest part of a draft and tell the writer exactly why it's weak and what to do about it.

Context: Here is my draft: [PASTE]

Constraints:

Identify the single weakest paragraph.
Explain in one sentence why it's weak (vague? unsupported? repetitive? wrong tone?).
Suggest one specific fix — not "make it better," but a concrete action ("replace this with a number from your data," "cut this sentence entirely," "move this example earlier").
Identify any paragraph that could be cut entirely without losing the argument.
Do not praise the draft anywhere in your response.

Output: Weakest paragraph (quoted) → why → fix → optional cuts.

The "no praise" constraint matters. AI's default is to sandwich criticism in compliments, which trains you to ignore the useful part.

10. The content calendar from one pillar idea

Role: You are a content manager who plans 30 days of content from a single pillar topic, ensuring no two pieces overlap and each serves a different stage of the reader's journey.

Context: My pillar topic is: [TOPIC]. I publish on: [blog twice weekly / newsletter weekly / YouTube biweekly — LIST YOURS].

Constraints:

Produce 8 distinct content pieces derived from the pillar.
Each must target a different angle: beginner explainer, advanced tactic, case study, contrarian take, tool/tutorial, FAQ roundup, comparison, and personal story/opinion.
For each, give: working title, one-line summary, target platform, and which angle it fills.
No two pieces can cover the same sub-point.

Output: A table with columns: Title | Summary | Platform | Angle.

This is the prompt that turned my content from reactive ("what do I post today?") to planned. One pillar topic now carries a month.

How I test a prompt before trusting it

I run every new prompt three times on the same input. If the three outputs are nearly identical, the prompt is too rigid (it's just template-filling). If they're wildly different, the prompt is too loose (it's not constraining anything useful). The sweet spot is three outputs that share the structure but differ in the specifics — that tells you the constraints are working and the model still has room to think.

Then I take the best output, edit it, and publish. The prompt isn't a replacement for judgment. It's a replacement for the blank page.

If these were useful, I keep a larger library of tested prompts for the full range of work — launching products, writing marketing copy, running engineering teams, doing customer support, analyzing data, and more. The Developer Product-Launch Prompt Pack is the $9 starter (7 prompts with example outputs), and the full libraries are linked from my Gumroad storefront.

Every prompt in the packs follows the same Role → Context → Constraints → Output structure, with the same emphasis on constraints over verbosity. No filler prompts.

10 AI Prompts I Use for Recruiting (JDs, Sourcing, Interview Prep, Offer Letters)

draftkit — Tue, 21 Jul 2026 16:49:22 +0000

Recruiting is mostly communication work: writing job descriptions that attract the right people, sourcing messages that get replies, interview rubrics that don't bias the hire, offer letters that don't get renegotiated.

I've been running these through an AI assistant for the past year. The prompts below are the ones that survived real use — each has a fixed structure (Role, Context, Constraints, Output) and each has been tested against real inputs. I'll show the prompt, then what it produced, then why it works.

If you want the full library (50+ prompts across recruiting, people ops, and hiring strategy), I keep an updated pack here. But these 10 are the ones I reach for most weeks.

1. Job description that filters for the right people

Role: You are a hiring manager writing a job description.
Context: We're hiring a senior backend engineer. The team is 4 people, builds in Go and Postgres, ships weekly, and values ownership over hand-holding.
Constraints:

Lead with the actual work (3-5 bullet points of "what you'll do in week 1"), not the company mission.
Requirements section: split into "Must have" (≤5) and "Nice to have" (≤4). Each must-have is a filter — if a candidate lacks it, we pass.
No "rockstar," "ninja," "10x," "wear many hats," "fast-paced environment," "work hard play hard."
Salary range stated. Remote policy stated. No "competitive" — it means nothing.
End with: "What the first 30 days look like" — concrete, not aspirational. Output: Full JD, ready to post.

Why it works: JDs attract the wrong people when they're vague and repel the right people when they're loaded with bro-culture code words. Banning the clichés forces specificity. Stating salary and remote policy upfront saves everyone time. The "first 30 days" section signals what the job actually is.

2. Sourcing message that earns a reply

Role: You are a technical recruiter writing a cold sourcing message.
Context: Candidate is a senior frontend engineer at a mid-size SaaS. Their GitHub shows React + TypeScript work. We're a Series B devtools startup.
Constraints:

Subject line: ≤5 words, lowercase, no exclamation, references something specific from their work (a repo, a talk, a post).
Body: ≤90 words. First line references the specific thing. Second line is the role in one sentence. Third line is why them specifically (not "your background is impressive").
CTA: a question, not a meeting link. "Open to a 20-min chat?" not "Book time here."
No "exciting opportunity," "game-changing," "disrupt," "revolutionize."
PS: one sentence on compensation range + equity + remote. Honesty builds trust. Output: Subject + body + PS.

Why it works: Generic sourcing messages get ignored. The "reference something specific" constraint forces research. The lowercase short subject reads as human, not automated. Putting comp in the PS (not buried) respects the candidate's time. The question CTA lowers friction — a meeting link feels like a commitment.

3. Interview rubric from a messy job description

Role: You are a hiring manager building an interview rubric.
Context: Here's a JD for a product designer. I need a rubric for the portfolio round (4 interviewers, 45 min each).
Constraints:

4-5 signals per interviewer, each observable ("can articulate trade-offs" not "is strategic").
Each signal: what to ask, what a "strong" answer looks like, what a "weak" answer looks like.
Banned signals: "culture fit," "passion," "grit," "hunger," "is a team player." Replace with observable behaviors.
Calibration: every interviewer scores independently BEFORE the debrief. No "well, they seemed nice" influence. Output: Per-interviewer rubric + a debrief template (scores first, discussion second).

Why it works: Interview bias creeps in through vague signals. "Culture fit" is a bias magnet — banning it forces observable criteria. The "strong/weak answer" anchors calibrate the panel. Scoring before discussion prevents the loudest interviewer from anchoring the group.

4. Interview question that tests for the job, not trivia

Role: You are an interviewer designing a technical screen.
Context: We're hiring a backend engineer. The job involves designing APIs, not memorizing Big-O.
Constraints:

One scenario-based question that mirrors real work (e.g., "design the API for a rate limiter" not "what's the time complexity of a hash map").
The question has multiple valid answers, not one "right" one.
Follow-up probes: 3, escalating in ambiguity. The third should be unanswerable without asking a clarifying question — tests whether they push back.
Provide a "what good looks like" and "what bad looks like" for scoring. Output: Question + probes + scoring guide.

Why it works: Trivia questions test test-prep, not ability. Scenario questions test the actual job. The deliberately-ambiguous third probe separates candidates who guess from those who clarify — a core engineering skill. The scoring guide keeps it fair across interviewers.

5. Candidate rejection that doesn't burn the bridge

Role: You are a recruiter writing a rejection email.
Context: Candidate made it to the final round but wasn't selected. They were strong — we'd reconsider for a different role.
Constraints:

First line: the decision, clearly. No "we've decided to move forward with other candidates" softening.
One specific thing they did well (from the rubric, not generic).
One specific growth area, framed as "for roles like this" not "you need to."
If we'd reconsider: say so explicitly, with a timeframe.
No "keep your resume on file" unless we mean it. Output: Email, ≤150 words.

Why it works: Vague rejections feel disrespectful and damage your employer brand. Specific feedback (from the rubric) shows the process was real. The "for roles like this" reframe makes the growth area actionable, not personal. The "would reconsider" line is honest — it either opens a door or doesn't.

6. Offer letter that survives the first counteroffer

Role: You are a hiring manager writing an offer letter.
Context: Senior engineer, base $X, equity Y, remote. They have a competing offer.
Constraints:

Lead with the role and start date — the decision-relevant facts.
Compensation: base, equity (with vesting schedule and strike), bonus, sign-on. Each on its own line. No "total compensation" aggregation that hides the base.
Benefits summary: ≤5 bullets, the ones that actually matter (health, PTO, remote, learning budget). Skip the 401k match boilerplate.
One sentence on why we made the offer (ties to the interview — shows it wasn't arbitrary).
Expiry date stated. No "we look forward to your response" pressure language. Output: Offer letter, one page.

Why it works: Offers lose candidates when the details are buried. Putting each comp component on its own line (no "total comp" sleight of hand) builds trust. Tying the offer to the interview signals it was earned. The expiry date creates a clean decision frame without pressure tactics.

7. Reference check that surfaces the real signal

Role: You are a hiring manager conducting a reference call.
Context: 30-min call with a candidate's former manager. Candidate is up for a senior IC role.
Constraints:

Open with: "I have 30 minutes and I want to use them well. What's the one thing I should know that isn't in their resume?" (forces the reference past the prepared talking points).
5 questions max: one on strengths (specific example required), one on growth area (specific example required), one on "would you rehire," one on team dynamics, one wildcard.
No "rate them 1-10" questions — they produce noise.
End with: "Is there anything I haven't asked that I should have?" Output: Call script + a notes template (strength / growth / rehire / wildcard).

Why it works: References default to positivity. The opening question ("one thing not in the resume") cuts through the prep. Forcing specific examples (not ratings) gets real signal. The closing question often surfaces the most important data point.

8. Onboarding plan for the first 90 days

Role: You are a hiring manager building an onboarding plan.
Context: New senior engineer starts in 2 weeks. Team of 5, Go/Postgres stack, weekly shipping cadence.
Constraints:

Week 1: setup, meet everyone, ship one tiny thing (a docs fix, a small bug). Goal: feel productive.
Week 2-4: first real feature, paired with a buddy. Goal: learn the codebase by doing.
Day 30: review. What's working, what's not. Adjust the plan.
Day 60: lead a small project end-to-end.
Day 90: full ownership of a domain.
Each milestone: success criteria (observable), not "ramp up" (vague). Output: 90-day plan, week by week, with success criteria.

Why it works: Onboarding fails when it's "read the wiki and figure it out." The "ship one tiny thing in week 1" builds confidence fast. Observable success criteria ("shipped X, reviewed Y") beat vague ones ("ramped up"). The day-30 review lets you course-correct before day 90.

9. Hiring manager intake that aligns before you start sourcing

Role: You are a recruiter running an intake meeting with a hiring manager.
Context: 30-min kickoff for a new role. I need to extract the real requirements, not the wishlist.
Constraints:

6 questions: (1) What's the #1 thing this person must do in month 1? (2) Who on the current team does this role complement? (3) What does "great" look like at 6 months? (4) What's non-negotiable vs trainable? (5) Why would someone take this job over a competitor's? (5) What's the budget and how firm is it?
For each answer: push back once if it's vague ("'strong communicator' — what does that look like in week 2?").
End with: the sourcing strategy in one sentence (which companies, which communities). Output: Intake notes + a one-paragraph "role brief" the hiring manager signs off on.

Why it works: Intakes fail when the wishlist is treated as requirements. The "month 1" question forces prioritization. Pushing back on vague answers ("'strong communicator' — what does that look like?") converts adjectives into criteria. The signed role brief prevents scope drift mid-search.

10. Candidate debrief that avoids groupthink

Role: You are a hiring manager running a debrief.
Context: 4 interviewers just met a candidate. 30-min debrief.
Constraints:

Round 1: each interviewer states their recommendation (hire/no-hire/leaning) + one piece of evidence. No discussion. (forces independent thinking).
Round 2: open discussion, but every claim must cite a specific moment from the interview. No "I got a good vibe."
Round 3: decision. If split, default to the rubric — does the evidence meet the bar?
Banned: "culture fit," "I could see myself grabbing a beer with them," "they'd be fun to work with." Output: Decision + reasoning + (if hire) the onboarding focus areas based on rubric gaps.

Why it works: Debriefs go sideways when the loudest interviewer anchors the group. The "state recommendation + evidence first, no discussion" round forces independent judgment. Requiring specific moments (not vibes) keeps it evidence-based. Banning "beer test" language removes the likeability bias that produces homogenous hires.

How I test these prompts

Three steps, every time:

Run it 3× on the same input. If the output varies wildly, the prompt is under-specified. Tighten the constraints.
Generalize to a second domain. Take a sourcing prompt built for engineers and run it for designers. If it breaks, the constraints are too narrow. If it holds, it's portable.
Read it aloud. If it sounds like an AI wrote it — "delve into," "in today's competitive talent market," "it's important to note" — rewrite the constraints to ban that register.

The pattern across all 10: constraints do more work than instructions. Telling the model what NOT to do (no "rockstar," no "culture fit," no leading questions) produces sharper output than telling it what to do.

If these were useful, I keep a larger library — 50+ prompts covering recruiting, people ops, hiring strategy, and offer negotiation. It's here ($9). If you're also building a team and shipping product, the AI Startup Operations Prompt System covers the full org (hiring, onboarding, ops, planning).

Good hiring.

10 AI Prompts I Use for UX Research and Design (Interviews, Personas, Usability Tests)

draftkit — Tue, 21 Jul 2026 16:48:24 +0000

I've spent the last year running UX research and design work with an AI assistant in the loop. Not to replace research — to speed up the parts that eat hours without adding insight: turning 12 interview transcripts into themes, writing a usability test script that doesn't lead the witness, drafting personas that don't read like stereotypes.

Below are 10 prompts I keep coming back to. Each one has a fixed structure — Role, Context, Constraints, Output — and each has been tested against real inputs. I'll show the prompt, then what it produced, then why it works.

If you want the full library (50+ prompts across UX, research, design ops, and product work), I keep an updated pack here. But these 10 are the ones I use most weeks.

1. Interview synthesis that preserves verbatim quotes

Role: You are a senior UX researcher.
Context: I'm pasting 6 interview transcripts (30 min each) from a study on how freelance designers choose project management tools.
Constraints:

Group findings into themes. Each theme needs ≥3 quotes from ≥2 different participants.
Preserve quotes verbatim — no paraphrasing, no "cleaning up."
Flag any theme supported by only one participant as "single voice."
Do NOT invent quotes. If a theme has no quote, say so. Output: A themes table: Theme | Quote 1 (P#, verbatim) | Quote 2 | Quote 3 | Confidence (high/med/single-voice).

Why it works: The "no paraphrasing" constraint kills the thing LLMs do worst — smoothing quotes into bland summaries that lose the participant's actual words. The "single voice" flag prevents one loud participant from dominating the synthesis.

2. Persona built from research, not stereotypes

Role: You are a UX researcher writing a persona.
Context: Based on these 6 transcripts, build a persona. Avoid stock persona language.
Constraints:

Name, role, and one specific quote that anchors them.
Goals: 3, each tied to a verbatim quote.
Frustrations: 3, each tied to a verbatim quote.
Banned phrases: "tech-savvy," "time-poor," "busy professional," "values efficiency," "wants things to just work," "demands seamless experiences."
Do NOT invent demographics not in the data (age, location, income). Output: One-page persona markdown.

Why it works: Personas go wrong when they drift into fiction. Banning the stock phrases forces the model to reach for the actual words participants used. Anchoring every goal/frustration to a quote keeps it honest.

3. Usability test script that doesn't lead the witness

Role: You are a moderated usability test moderator.
Context: I'm testing a new onboarding flow for a budgeting app. 5 participants, 45 min each.
Constraints:

Task-based, not question-based. Each task starts with a goal, not "click here."
Neutral language. No words like "easy," "simple," "obviously," "as you'd expect."
After each task: one open probe ("What were you expecting?"), one specific probe ("What made you click there?"). Never "Why did you do that?" — it sounds accusatory.
End with one question the participant must answer without help: "If you had to do this again tomorrow, what would you remember?" Output: Full script: intro, 6 tasks with probes, post-task questions, wrap-up.

Why it works: Leading questions are the #1 usability test sin. Banning the loaded words and forcing neutral probes catches the subtle bias that creeps in. The "remember tomorrow" question surfaces mental models better than "how was that?"

4. Heuristic review that cites the specific heuristic

Role: You are a Nielsen Norman-style heuristic evaluator.
Context: Here are 12 screens from a checkout flow. Review against Nielsen's 10 heuristics.
Constraints:

For each finding: Severity (1-4) | Heuristic violated (name it specifically) | Screen | What's wrong | Why it matters for the user | Suggested fix (one sentence).
Do NOT list "violations" that are actually preferences. If it's a preference, label it "Polish, not violation."
Group by severity, not by heuristic. Output: Severity-ordered findings table + a 3-bullet "top priorities" summary.

Why it works: Heuristic reviews turn mushy when the evaluator waves at "consistency" without naming which consistency. Forcing the specific heuristic name and a severity score keeps it actionable. The "polish vs violation" split stops bikeshedding.

5. Survey that avoids double-barreled and leading questions

Role: You are a survey designer.
Context: I need a 12-question survey to understand why users churn after the free trial.
Constraints:

No double-barreled questions (one concept per question).
No leading questions (no "How much do you love…").
No loaded wording ("powerful," "intuitive," "frustrating").
Mix of scale (1-5), multiple choice, and one open-ended at the end.
The open-ended question must be neutral: "What almost stopped you from continuing?" not "What did you dislike?" Output: Survey in order, each question labeled with type.

Why it works: Survey design has well-known failure modes. Naming them explicitly as constraints makes the model police itself. The neutral open-ended reframe is the single biggest lever — "what almost stopped you" gets more honest answers than "what did you dislike."

6. Wireframe annotation a developer can build from

Role: You are a designer writing wireframe annotations for engineering.
Context: Here's a low-fi wireframe of a settings page. Write the handoff notes.
Constraints:

Per component: Purpose | States (default/hover/active/disabled/error) | Empty state | Loading state | Edge cases (max char, null, permission denied).
No design-system jargon without a link. If you say "use the primary button," link to the component.
Flag any state you can't infer from the wireframe as "ASSUMPTION — confirm with designer." Output: Component-by-component annotation, grouped by section.

Why it works: Handoff docs fail when they describe the happy path and forget states. Forcing every component to enumerate its states catches the gaps. The "ASSUMPTION" flag makes the model admit uncertainty instead of inventing specs.

7. Competitor teardown focused on decisions, not features

Role: You are a UX strategist.
Context: Here are 3 competitor apps in the habit-tracking space. I want a teardown, not a feature list.
Constraints:

For each competitor: One decision they made that's interesting (not "they have streaks" — everyone has streaks). Why it's interesting. The trade-off it implies.
No "feature comparison table." Decisions, not checkboxes.
End with: "What I'd steal" (1 thing) and "What I'd avoid" (1 thing) per competitor. Output: Per-competitor analysis + a cross-competitor "patterns" section.

Why it works: Feature lists are useless — they tell you what exists, not why. Forcing "one interesting decision + the trade-off" surfaces the actual design thinking. "What I'd steal / avoid" forces a point of view.

8. Accessibility review beyond color contrast

Role: You are an accessibility specialist (WCAG 2.2 AA).
Context: Here's a Figma-exported screen description. Review for accessibility.
Constraints:

Cover: color contrast, focus indicators, alt text, heading hierarchy, touch target size, form labels, error identification, motion/animation, keyboard nav.
For each finding: WCAG criterion number | Issue | Who it affects | Fix.
Do NOT only flag contrast. If contrast is the only issue, say "contrast is the only automated-detectable issue; manual testing needed for the rest." Output: Findings by category + a "needs manual testing" list.

Why it works: LLMs default to "check contrast" and stop. Enumerating the categories forces a fuller pass. The honesty caveat ("manual testing needed") prevents false confidence — automated review has real limits.

9. Research recruitment screener that filters without biasing

Role: You are a UX research recruiter.
Context: I'm recruiting 8 freelance designers who use project management tools weekly. Write a screener.
Constraints:

Disqualifying questions must be behavior-based, not demographic ("How many hours per week do you use a project management tool?" not "Are you a designer?").
No "killer questions" that telegraph the right answer ("Do you love trying new tools?").
Include one attention-check question ("Select 'sometimes' for this question").
Incentive, time commitment, and recording consent stated upfront. Output: Screener survey + a one-line recruitment blurb for each channel (Twitter, Slack, email).

Why it works: Screeners go wrong when they signal what you're looking for. Behavior-based questions and the "no killer questions" rule keep the filter honest. The attention-check catches panel-study junk responses.

10. Stakeholder readout that leads with the decision needed

Role: You are a UX researcher writing a readout for a product VP.
Context: Here are the findings from a 6-person usability study. The VP has 5 minutes.
Constraints:

Line 1: The decision this research enables or blocks (one sentence).
Then: 3 findings max, each with a quote and a recommendation.
Banned: "interesting insights," "rich data," "participants generally," "users expressed."
End with: "Open question" — the one thing this study couldn't answer. Output: One-page readout. No executive summary separate from the body — the body IS the summary.

Why it works: Researchers bury the lede. Forcing line 1 to be the decision reframes the whole doc around action. Banning the filler phrases ("interesting insights") forces specificity. The "open question" builds trust — it says you know the limits of your own research.

How I test these prompts

Three steps, every time:

Run it 3× on the same input. If the output varies wildly, the prompt is under-specified. Tighten the constraints.
Generalize to a second domain. Take a prompt built for UX research and run it on, say, customer support transcripts. If it breaks, the constraints are too narrow. If it holds, it's portable.
Read it aloud. If it sounds like an AI wrote it — "delve into," "in today's fast-paced world," "it's important to note" — rewrite the constraints to ban that register.

The pattern across all 10: constraints do more work than instructions. Telling the model what NOT to do (no paraphrasing, no stock phrases, no leading questions) produces sharper output than telling it what to do.

If these were useful, I keep a larger library — 50+ prompts covering UX research, design ops, product discovery, and stakeholder communication. It's here ($9). There's also a deeper developer productivity library and a SaaS marketing copy pack if you're wearing multiple hats.

Happy researching.

10 AI Prompts I Use for Technical Writing (API Docs, Tutorials, Release Notes)

draftkit — Tue, 21 Jul 2026 16:12:04 +0000

Technical writing is mostly rewriting. The first draft of a doc is never the one users can follow. You write it, then you walk through it as a beginner, then you find the six places you assumed knowledge the reader doesn't have, then you rewrite. The AI doesn't replace that loop — it shortens it.

These are the ten prompts I use in my own writing loop. Each follows Role → Context → Constraints → Output, and each was tested against real docs (real API references, real tutorials, real release notes that shipped to real users). Fill the brackets, run it, then edit. None of these are "write me some documentation." They're instruments for specific failures in the documentation process.

The full set of prompts I use across docs, support, and developer relations lives in the launch pack — but these ten are free to copy.

The structure, once

Every prompt below fills four slots:

Role — a specific writer, not "a technical writer." Example: "a writer who documents REST APIs for a developer audience that has never used the product before."
Context — the doc you're working on, the audience, what's already written, what the code does. Concrete inputs.
Constraints — the rules. Voice, reading level, banned words, required sections, maximum length. This is where prompts go wrong — too few constraints, too much latitude.
Output — the exact shape of what comes back. "A numbered list of gaps" beats "help me improve this."

Internalize that structure and you can write your own prompts for your own worst documentation problems.

1. Doc audit that finds the actual gaps

The moment: You inherited a docs site. You don't know what's missing, outdated, or wrong. You need an audit, not a vibe check.

Role: You are a senior technical writer auditing an existing 
documentation set for gaps and rot.

Context: Product: [name, one-line description]. Docs URL or 
pasted table of contents: [paste TOC or link]. Audience: 
[beginner developers / experienced integrators / internal 
engineers / non-technical admins]. Known recent changes to 
the product: [list — features added, APIs deprecated, UI 
redesigned].

Constraints:
- Audit for four categories of problem, in this order:
  1. Missing docs (things a user needs to do that have no 
     doc — infer these from the product description and 
     audience. Example: if there's a "create API key" flow 
     but no doc on key rotation or permissions, that's a gap.)
  2. Outdated docs (things that likely changed but the doc 
     wasn't updated — flag any doc that references a version, 
     a UI label, a default, or a limit without a "last verified" 
     date)
  3. Wrong-order docs (prerequisites that come after the step 
     that needs them; concepts that reference features not yet 
     introduced)
  4. Orphan docs (pages nothing links to; pages that reference 
     deprecated things)
- For each finding: cite the specific doc/page. No generic 
  "your authentication docs could be clearer" — that's useless. 
  "auth.md step 3 references a 'Token' field but the UI now 
  labels it 'Access Key' as of [version]" is useful.
- Do NOT rewrite anything. This is an audit, not a rewrite.

Output: A markdown table with columns: Category | Doc | 
Finding | Severity (blocker/major/minor). Sort by severity 
within each category.

The severity column is what makes the output actionable. Without it, you get a list of 40 problems that all feel equal and you fix none of them.

2. Tutorial a true beginner can follow

The moment: You need a getting-started tutorial. The failure mode is writing one that assumes the reader already knows the thing the tutorial is supposed to teach.

Role: You are a technical writer producing a getting-started 
tutorial. The reader has never used this product. They may be 
new to the broader category.

Context: Product: [name]. What the tutorial should accomplish: 
[in one sentence — "set up a webhook receiver and verify it 
works"]. Prerequisites the reader can be assumed to have: 
[list — e.g., a terminal, Node 18+, a free account]. 
Prerequisites they CANNOT be assumed to have: [list — e.g., 
prior experience with webhooks, knowledge of our SDK].

Constraints:
- Structure as numbered steps. Each step does exactly ONE thing.
- Every step has three parts: (1) what you're about to do 
  and why, (2) the command or action, (3) what the output 
  should look like — quote the literal expected output.
- If a step could fail, add a "If you see [X]" subsection 
  with the fix. Cover the top 2 failure modes only — not 
  every possible error.
- No step may reference a concept, file, or tool that hasn't 
  been introduced in an earlier step. If a step requires a 
  concept not yet covered, add a prerequisite step.
- Banned phrases: "simply," "just," "obviously," "as you 
  can see," "it's easy to." If it were simple you wouldn't 
  be writing a tutorial.
- Reading level: aim for a developer who is competent but 
  new to THIS. Not a junior, not a staff engineer.

Output: The full tutorial in markdown. Include the intro 
(one paragraph on what they'll build and why it matters) 
and the success state (how they know it worked).

The "what the output should look like" rule is the most important. Tutorials fail when the reader runs a command, gets output, and can't tell if it's right. Quote the literal success output every time.

3. API reference entry that matches the code

The moment: You're documenting an API endpoint. The failure mode is writing prose that drifts from what the code actually does.

Role: You are a technical writer documenting a REST API 
endpoint from its implementation. You do not invent behavior — 
you describe what's there.

Context: Endpoint: [METHOD /path]. Source code or behavior 
description: [paste the handler, the route definition, or a 
precise description of what it does — including auth required, 
rate limits, side effects]. Request parameters: [list with 
types]. Response shape: [paste the JSON schema or an example 
response].

Constraints:
- Document in this exact structure:
  1. One-line description (what it does, in plain language, 
     no marketing)
  2. HTTP method + path + required auth (none / API key / OAuth)
  3. Parameters table (name | type | required | default | 
     description — description must state what happens if 
     omitted, not just "the foo value")
  4. Example request (curl, copy-pasteable)
  5. Example response (the full JSON, with a comment on any 
     non-obvious field)
  6. Errors (list the status codes this endpoint can return 
     and what each means — only ones this endpoint actually 
     returns, not the generic set)
- Every field description must answer: what is it, what shape 
  is it, what happens if I omit it or send it wrong.
- If the code does something the doc should warn about 
  (a side effect, a performance cost, a deprecation), include 
  a "Notes" section. Do not hide warnings in prose.

Output: The reference entry in markdown. No preamble.

The "errors this endpoint actually returns" rule prevents the most common API doc failure: a generic error table that lists every HTTP status code whether or not the endpoint can produce it. Readers learn to ignore those tables. Specific ones get trusted.

4. Release notes that don't bury the breaking change

The moment: You shipped a release. You need notes that users can scan in 30 seconds and that don't hide the one thing that'll break their integration.

Role: You are a technical writer producing release notes 
from a list of changes. Your reader is an existing user 
deciding whether to upgrade.

Context: Version: [x.y.z]. Change list (from PRs, commits, 
or engineering notes): [paste the raw list — messy is fine]. 
Known breaking changes: [flag any]. Migration required: 
[yes/no, and what].

Constraints:
- Structure as three sections, in this order:
  1. ⚠️ Breaking changes (if any — lead with these. For each: 
     what changed, who's affected, the one-line migration 
     step. If none, write "No breaking changes.")
  2. ✨ New (new features and capabilities — each as one 
     bullet, what it does, no marketing words)
  3. 🛠 Fixed (bug fixes — each bullet names the symptom 
     the user would have seen, not the internal cause)
- Banned: "various improvements," "stability enhancements," 
  "performance improvements" unless you can attach a number 
  or a specific before/after.
- Each bullet is one line. If a change needs explanation, 
  link to the full changelog or migration guide — don't 
  expand inline.
- Reading level: a user who skimmed this in 20 seconds 
  should know (a) whether they need to change their code 
  and (b) what they get by upgrading.

Output: The release notes in markdown. Ready to post.

The order is the whole prompt. Breaking changes first is the opposite of what most release notes do — and it's the only order that respects the reader's time.

5. Explain-a-concept that doesn't condescend

The moment: You need to explain a concept (webhooks, JWT, event sourcing, idempotency) to an audience that's smart but new to it.

Role: You are a technical writer explaining a concept to a 
competent developer who hasn't encountered this specific 
concept before. You respect their intelligence.

Context: Concept: [name]. Why they need to understand it: 
[the doc or task that requires this concept — e.g., "before 
implementing our retry logic, you need to understand 
idempotency keys"]. What they already know (safe assumptions): 
[list — e.g., "knows HTTP, knows JSON, has used REST APIs"]. 
What they don't know: [the specific gap this fills].

Constraints:
- Structure:
  1. The one-sentence definition (no analogy yet — the 
     precise technical definition, then a plain-language 
     restatement)
  2. Why it exists (the problem this concept solves — 
     name the problem before the solution)
  3. How it works (a step-by-step walkthrough, with a 
     concrete example using real values, not abstract 
     placeholders)
  4. The gotcha (the one thing people get wrong about 
     this concept — the common misunderstanding)
  5. When you'd use it vs. not (the decision frame — 
     when this concept applies and when a simpler 
     alternative is better)
- Banned analogies that oversimplify: "think of it like 
  a restaurant" / "imagine a library" / any analogy that 
  requires explaining the analogy. If an analogy helps, 
  use it briefly; don't build the whole explanation on it.
- Do not say "simply put" or "in other words" more than once.
- Respect the reader: no "don't worry, it's not as scary 
  as it sounds." It's not scary. It's a concept.

Output: The explanation in markdown. 400-600 words.

The "gotcha" section is where this prompt earns its keep. AI explanations are good at the what and the how; they're bad at the common misunderstanding because the misunderstanding isn't in the training data — it's in the gap between the concept and how people actually misuse it. Forcing the model to produce a gotcha makes it surface the thing you'd otherwise only learn from a support ticket.

6. Rewrite for reading level without dumbing down

The moment: You have a doc that's technically accurate but written for someone three levels more senior than the actual audience. You need it rewritten without losing precision.

Role: You are a technical writer editing a doc to match the 
audience's reading level. You do not remove technical detail. 
You make the detail accessible.

Context: Audience: [who they are — e.g., "frontend developers 
integrating our API, no backend experience"]. Current doc: 
[paste]. What's wrong with it for this audience: [your 
diagnosis — e.g., "assumes knowledge of database internals," 
"uses internal jargon," "sentences average 35 words"].

Constraints:
- Keep every piece of technical information. Do not delete 
  facts, parameters, or warnings to "simplify."
- Change these things:
  1. Sentence length — break sentences over 25 words into two.
  2. Jargon — replace internal terms with the term the audience 
     would search for. If you must keep an internal term, 
     define it inline on first use.
  3. Assumed knowledge — if the doc references a concept the 
     audience doesn't have, add a one-line orientation, not a 
     paragraph. Link out for depth.
  4. Voice — prefer second person ("you configure") over 
     passive ("is configured"). Active voice for actions.
- Do NOT add analogies, metaphors, or "think of it like." 
  This is an edit, not a rewrite for tone.
- Do NOT add motivational language ("great job getting this 
  far!"). 
- Preserve all code blocks, parameter tables, and structured 
  data exactly.

Output: The rewritten doc in markdown, same structure.

The "don't delete facts to simplify" rule is the guardrail. The failure mode of reading-level edits is stripping out the precision that made the doc useful. This prompt keeps the precision and fixes the surface.

7. Doc-tree generator from a feature list

The moment: You're starting docs from scratch. You have the product/features. You need the doc structure before you write any page.

Role: You are a technical writer planning a documentation 
information architecture from scratch.

Context: Product: [name, one-line description]. Features to 
document: [list every feature/capability]. Audience segments: 
[list — e.g., "evaluators, integrators, admins"]. 
Entry points users will arrive from: [e.g., "search for 'how 
to X', in-product help link, sales handoff, onboarding email"].

Constraints:
- Produce a doc tree (nested list) with these top-level sections:
  - Getting Started (the fastest path to first success)
  - Concepts (what you need to understand before the reference 
    makes sense)
  - Guides (task-oriented, one doc per task)
  - Reference (API, SDK, CLI, configuration — exhaustive, 
    not narrative)
  - Troubleshooting (symptom-first, not cause-first)
- Under each section, list specific doc titles. Each title 
  is the task or question the doc answers, not a content type 
  ("Create an API key" not "API Keys Overview").
- For each doc, mark the audience segment(s) it serves.
- Flag any feature that doesn't fit cleanly into a section — 
  that's a signal the IA is wrong or the feature is poorly 
  scoped.
- Do not create "Overview" pages for overview's sake. Every 
  page must answer a question someone would search for.

Output: The doc tree as a nested markdown list. One line per 
doc. Audience tags in parentheses.

The "no Overview pages for overview's sake" rule kills the most common IA failure: a docs site full of pages titled "X Overview" that say the same thing as the section above them.

8. Changelog entry from a messy PR description

The moment: Engineering shipped. The PR description is "fixes stuff" and three commit hashes. You need a user-facing changelog entry.

Role: You are a technical writer turning engineering output 
into a user-facing changelog entry.

Context: PR title: [title]. PR description: [paste — messy 
is fine]. Commits: [paste, or summary]. Files changed: [list 
or summary of what subsystem]. The user-visible symptom before 
(if a fix): [what users experienced].

Constraints:
- Produce ONE changelog line. Format: 
  [Type] [Component] — [What changed, in user terms].
  - Type: Fixed / Added / Changed / Removed / Deprecated / Security
  - Component: the user-facing area (Auth, Billing API, Dashboard), 
    not the internal module
  - What changed: described as what the user will now experience 
    or no longer experience. Never reference internal files, 
    functions, or architecture.
- If the change is internal-only (refactor, dependency bump with 
  no behavior change), output: "Internal: no user-facing change." 
  Do not invent a user benefit.
- If the change is a breaking change, prefix with "⚠️ Breaking:" 
  and add the one-line migration step on a second line.
- Maximum 2 lines per entry.

Output: The single changelog entry. Nothing else.

The "internal-only → say so" rule matters. Too many changelogs invent user-facing benefits for refactors. Once users catch you doing that, they stop reading the changelog.

9. Troubleshooting doc organized by symptom

The moment: You have a list of common errors and fixes. You need a troubleshooting page users can scan when something breaks.

Role: You are a technical writer producing a troubleshooting 
doc. Users arrive at this page when something is broken and 
they're frustrated. They will not read top to bottom.

Context: Product: [name]. Known errors and their fixes: 
[paste your list — error messages, symptoms, root causes, 
fixes]. Common environmental causes: [list — wrong Node 
version, firewall, expired token, etc.].

Constraints:
- Structure as a table of symptoms, not causes. Users search 
  by what they see, not by what's wrong internally.
- Columns: Symptom (the exact thing the user sees — error 
  message, unexpected behavior, blank page) | Likely cause 
  (one line) | Fix (numbered steps, copy-pasteable commands).
- Sort by frequency — the most common symptom first.
- After the table, add a "General debugging" section with 
  3 universal first steps (e.g., "check your API key," 
  "check the status page," "try in a clean environment").
- If a symptom has multiple possible causes, list each cause 
  with its distinguishing signal ("if you also see X, it's 
  cause B").
- Banned: "please contact support" as the only fix. If the 
  fix is "contact support," say what information to include 
  in the ticket.

Output: The troubleshooting doc in markdown.

Symptom-first organization is the single highest-impact change you can make to a troubleshooting page. Users Google the error message they see; they don't Google "what causes ERR_INVALID_AUTH."

10. Glossary entry that defines, then disambiguates

The moment: You're building a glossary. The failure mode is definitions that are technically correct but useless because they don't distinguish the term from its neighbors.

Role: You are a technical writer producing a glossary entry 
for a term that is commonly confused with related terms.

Context: Term: [the word]. Domain: [your product's domain]. 
Common confusion: [the related terms people mix this up with 
— e.g., for "idempotent," confusion is with "pure function" 
and "cached"].

Constraints:
- Structure each entry as:
  1. One-sentence definition (precise, no analogy, no "simply")
  2. An example (a concrete instance, not an abstract one)
  3. "Not to be confused with:" — for each related term, 
     one sentence on the difference. This is the most 
     important part. The definition alone won't stick if 
     the reader can't tell the term from its neighbors.
  4. "See also:" — cross-references to other glossary terms.
- Definition must use the audience's vocabulary, not more 
  jargon. If the term is itself jargon, define it in terms 
  a competent developer would know.
- Maximum 80 words per entry. Glossary entries are looked up, 
  not read.

Output: The single glossary entry in markdown.

The "not to be confused with" section is the whole prompt. A glossary that defines "authentication" without distinguishing it from "authorization" has failed its reader. The disambiguation is the value.

How I tested these

Each prompt was run against three real docs I'd written or inherited. A prompt that produced a good audit once was an anecdote; I kept the ones that produced good audits across an API reference, a tutorial, and a troubleshooting page.

Then I checked generalization: does the tutorial prompt work for a CLI tool the same way it works for a web API? Does the release-notes prompt work for a library the same way it works for a hosted product? The ones above generalized.

Finally, I read every output as a hostile reader — looking for hallucinated parameters, invented error codes, sections that sounded right but were wrong. The constraints (quote literal output, only list errors the endpoint actually returns, mark internal changes as internal) exist because those are the failure modes. The prompt structure is designed to make the failure modes hard to produce.

What's in the full pack

These ten are the technical-writing slice. The full launch pack has seven prompts that cover the core docs-to-launch workflow — release notes, API reference, tutorials, README, and the audit method. There's a larger productivity library with 30 prompts across docs, support, engineering, and ops if you want the broader set.

The prompts aren't the asset. The structure is. Once you can write Role→Context→Constraints→Output for the worst part of your documentation process, you stop needing other people's prompt libraries.

The best thing you can do with this is steal the structure, write a prompt for the doc task you hate most, and run it three times on three real inputs. That's the entire method.

10 AI Prompts I Use for Sales Work (Outreach, Discovery, Objection Handling)

draftkit — Tue, 21 Jul 2026 16:11:16 +0000

Every sales team I've worked with spends more time writing than talking to prospects. Cold emails, follow-ups, discovery notes, deal summaries for the weekly pipeline review, the "just checking in" message you send fourteen times a day. It's a writing job with a quota attached.

These are the ten prompts I actually use. Each one follows the same shape — Role → Context → Constraints → Output — and each one was tested against the real thing: my last three quarters of outreach, discovery notes, and objection logs. Fill the bracketed fields, run it, edit the result. None of them are "write me a sales email." They're specific instruments for specific moments.

If you want all 30+ prompts I use across sales, marketing, and customer success in one file, the pack is here — but the ten below are free to copy.

The structure I use for every prompt

Before the prompts, the structure — because once you internalize it you can write your own.

Role — who the model is pretending to be. Not "you are a salesperson." A specific one: "a B2B SaaS AE with 8 years selling to mid-market ops teams."
Context — the situation. The prospect's industry, last quarter's results, what they said on the last call. Concrete, not vague.
Constraints — the hard rules. Word count, banned phrases, required format, tone. This is where most prompts fail — too loose.
Output — exactly what you want back. "Eight subject lines" is better than "ideas for a subject line."

Every prompt below fills those four slots. When you write your own, ask: did I tell it who to be, what's happening, what it can't do, and what shape the answer takes?

1. Cold outreach that earns a reply

The moment: You found a prospect. You need a first email that doesn't read like every other cold email.

Role: You are a B2B SDR who books 3+ meetings a week from cold email, 
selling [product] to [buyer role] at [company size] companies.

Context: The prospect is [name], [title] at [company]. Their team 
[recent trigger — funding round, hiring spree, exec change, product 
launch, public complaint]. Our product helps with [specific problem].

Constraints:
- Subject line: 5 words or fewer, lowercase, no question marks, 
  no exclamation points, no "quick," no "checking in."
- Body: 90 words max. First sentence references the trigger. 
  Second sentence is the problem we solve — stated as pain, 
  not as feature. Third sentence is one proof point (a number, 
  a logo, a before/after). CTA is a question, not a meeting link.
- Banned: "I hope this finds you well," "revolutionary," 
  "game-changing," "synergy," "circle back," any emoji.

Output: 1 subject line + 1 email body. Then 2 alternate subject 
lines, each a different angle (urgency / curiosity / referral-style).

The alternates matter. Your first subject line is rarely your best one.

2. Discovery-call prep in 4 minutes

The moment: You have a discovery call in an hour. You need to walk in knowing what to ask.

Role: You are a senior AE preparing a discovery call.

Context: Prospect is [company], [industry], ~[employee count] 
employees. They booked after [source: inbound demo request / 
outbound reply / referral from X]. Public info: [paste 3-5 bullets 
from their site, a recent press release, or their job postings].

Constraints:
- Identify the 3 most likely business problems we solve for 
  someone in their role. Rank by likelihood.
- For each: write 2 diagnostic questions that would confirm or 
  rule it out. Questions must be open-ended (no yes/no). 
  Each question should surface a number, a frequency, or a 
  workflow — not an opinion.
- End with 1 "landmine" question — something that, if they 
  answer it a certain way, kills the deal. State what the 
  deal-killing answer sounds like.

Output: A numbered list. No preamble. No "great question!" energy.

The landmine question is the point. Most discovery prep lists questions you want to ask. This one forces you to surface the question you don't want the answer to.

3. Objection handler that doesn't sound defensive

The moment: The prospect said "it's too expensive" / "we need to think about it" / "we already use [competitor]." You need a response that isn't a rebuttal script.

Role: You are a consultative AE. You do not "overcome" objections. 
You diagnose them.

Context: Prospect said: "[exact objection, verbatim]." 
What we know: [their budget cycle / their current solution / 
their stated priority / who else is involved in the decision].

Constraints:
- First, name the 3 possible real meanings behind this objection. 
  "It's too expensive" almost never means the price is too high. 
  List what it actually might mean (no budget this quarter, 
  haven't seen value yet, comparing to a cheaper tool, needs 
  boss approval, using it as a polite no).
- For each possible real meaning: write the one question that 
  would tell you which one it is. No defending, no justifying, 
  no "but actually our ROI is…"
- Mark which real meaning is most dangerous (the one that kills 
  the deal no matter what you say) and what you'd do if it's that.

Output: The 3 meanings, the 3 diagnostic questions, and the 
diagnosis. Plain text. No motivational framing.

This prompt exists because most objection-handling training teaches you to argue. Good sellers diagnose.

4. The "just checking in" replacement

The moment: You've been ghosted. You need to follow up without saying "just checking in."

Role: You are a persistent-but-not-annoying AE following up on 
a stalled deal.

Context: Last contact was [date]. Last topic was [what we 
discussed — their stated pain, the demo they saw, the question 
they were going to ask their boss]. Since then: [anything new — 
a feature shipped, a case study from their industry, a regulatory 
change affecting them].

Constraints:
- 60 words or fewer.
- Do NOT use the phrase "just checking in," "circling back," 
  "following up," "touching base," "wanted to see," or "bumping this."
- The email must contain exactly one new piece of value — 
  a fact, a stat, a relevant change. Not a "thought you'd find 
  this interesting" — a specific thing tied to their situation.
- CTA is either: (a) a question about their timeline, or 
  (b) a single binary choice ("worth a 15-min call this week, 
  or should I follow up next quarter?"). No open-ended "let me know."

Output: 1 email. Then 1 shorter alternate (under 35 words) that 
leads with the value, not the context.

The short alternate usually wins. Long follow-ups signal you're anxious; short ones signal you're busy and they should be too.

5. Deal update your VP actually reads

The moment: It's pipeline review. You need to summarize a deal in a way that surfaces what your manager needs to know — not everything that happened.

Role: You are an AE writing a deal update for your VP. 
Your VP reads 200 of these a week. They skim.

Context: Deal is [company], [stage — discovery/demo/proposal/
negotiation], [ACV], [target close date]. Last week's status was: 
[copy last update]. This week: [the 2-3 things that happened — 
call happened, doc sent, legal reviewed, champion changed].

Constraints:
- First line MUST be one of: "On track," "At risk," or "Slipped," 
  followed by the one-sentence reason. No other first line allowed.
- Then 3 bullets max: what changed, what's next, what you need 
  (from the VP or anyone). Each bullet under 20 words.
- If "At risk" or "Slipped": the third bullet must be the specific 
  ask — "I need you to call [champion's boss] by Thursday" or 
  "I need legal to expedite redlines." Vague asks are banned.
- Word cap: 120 words total.

Output: The update. Plain text, no headers. Ready to paste into 
CRM notes.

The "first line must be On track / At risk / Slipped" rule is the single highest-leverage constraint. It forces you to have a point of view before you write the rest.

6. Post-call notes that become the CRM record

The moment: Call just ended. You have 40 minutes of notes. You need them turned into something your team can use.

Role: You are an AE turning raw call notes into CRM-ready discovery 
documentation.

Context: Raw notes (transcript, scratch notes, or memory dump):
[paste everything — messy is fine, abbreviations fine, half-thoughts 
fine]. Deal context: [company, stage, what we're trying to sell].

Constraints:
- Extract and structure into exactly these sections:
  1. Situation (2-3 sentences: who they are, why we're talking)
  2. Pain points (list, each tied to a quote or paraphrase 
     from the notes — mark which is verbatim vs paraphrased)
  3. Current state (what they do today, what tools, what process)
  4. Decision process (who's involved, what timeline, what 
     criteria — only what was actually said, mark gaps as "UNKNOWN")
  5. Next steps (with owner and date)
- Anything not said in the notes gets marked "not discussed," 
  not inferred. Hallucinating a budget or a timeline from a vague 
  note is worse than leaving it blank.
- Mark anything that sounded like a commitment with ✅ and 
  anything that sounded like hesitation with ⚠️.

Output: The 5 sections. No editorializing. No "this is a great 
opportunity" — let the facts imply that or not.

The "mark verbatim vs paraphrased" rule is what makes this safe to use. AI will confidently turn "they mentioned budget season is coming up" into "they have budget next quarter." Don't let it.

7. Competitive battle card from a messy win-loss log

The moment: You have six months of win-loss notes against a competitor. You need a one-page battle card.

Role: You are a sales enablement lead building a competitive 
battle card from raw field notes.

Context: Competitor: [name]. Win-loss notes (last 6 months):
[paste your CRM notes, Gong summaries, rep recollections — 
messy is fine]. Our product: [ours].

Constraints:
- Structure as:
  1. Where we win (3 bullets max, each backed by a specific 
     deal or quote from the notes — no generalities)
  2. Where we lose (3 bullets max, same standard of evidence)
  3. The trap (the one thing reps keep doing that loses deals 
     against this competitor — name it bluntly)
  4. The one-line pivot (the single sentence a rep should say 
     when the prospect brings up this competitor)
- Banned: "feature parity," "comparable offering," "robust 
  solution." Use specific capabilities or specific outcomes.
- If the notes don't support a claim, don't make it. 
  Mark as "insufficient data" instead.

Output: The 4 sections. One page. A rep should be able to 
read it in 90 seconds before a call.

The "trap" section is the most valuable and the one AI is worst at producing on its own — it requires the model to find the pattern in what your reps keep doing wrong. That's why you feed it your actual notes, not a feature list.

8. Proposal that doesn't read like a proposal

The moment: Procurement asked for a written proposal. You don't want a 40-page document nobody reads.

Role: You are an AE writing a proposal a prospect will actually read.

Context: Prospect: [company], [industry], [team size]. Problem 
we're solving: [their words, from discovery — not our marketing 
copy]. What we're proposing: [product + scope + timeline]. 
Stakeholders involved: [list]. Their stated success criteria: 
[what they said they'd measure].

Constraints:
- Structure: 
  1. The situation (3 sentences, in their language, describing 
     where they are today — no product names yet)
  2. What success looks like (their criteria, restated so 
     they recognize them)
  3. What we'd do (the scope — described as outcomes and 
     milestones, not features)
  4. Investment (one line: price + term. No tiers, no "contact 
     us," no 3-column comparison)
  5. What we need from them (the 2-3 things required to start)
- Maximum 2 pages. No executive summary, no table of contents, 
  no "thank you for the opportunity."
- Banned: "leverage" (as a verb), "best-in-class," "world-class," 
  "seamless," "robust," "comprehensive."

Output: The proposal. Ready to send as a PDF.

The investment line is the constraint that scares people. One number. If your pricing genuinely needs three tiers, this prompt isn't for that deal — it's for the 80% of deals where a single clean number closes faster than a menu.

9. Referral request that doesn't feel transactional

The moment: A customer is happy. You want introductions without sounding like you're mining them.

Role: You are an AE asking a happy customer for referrals, 
without making it feel like a transaction.

Context: Customer: [name] at [company]. We've been working 
together since [date]. Recent win: [specific outcome they got — 
a number, a solved problem, a moment]. Relationship: [warm / 
very warm / just-delivered-big-win].

Constraints:
- Do NOT ask for "anyone who might benefit." That's a fishing 
  net and customers ignore it.
- Do NOT offer a referral fee or gift card unless that's genuinely 
  your company's policy — it changes the relationship.
- The email must propose 1-2 specific people or 1 specific 
  profile, based on what you know about their network/industry. 
  "Someone else running [their function] at a similar-stage 
  company" is specific. "Anyone in your network" is not.
- Make it easy to say no: explicitly state "no pressure, and if 
  no one comes to mind that's totally fine."
- Under 120 words.

Output: 1 email. Tone: peer-to-peer, not vendor-to-customer. 
The reader should feel like you respect their time and their 
relationships.

The specificity rule is everything. "Do you know anyone who needs this?" gets ignored. "I noticed you used to work at [their former employer] — is there anyone still there running ops who's dealing with [specific problem]?" gets a reply.

10. Quarterly business review that surfaces the renewal risk

The moment: It's QBR time. You need to present value delivered AND surface the things that might lose the renewal.

Role: You are a CSM/AE preparing a QBR for an existing customer. 
Your job is two things: prove value, and surface renewal risk early.

Context: Customer: [company], contract value [ACV], renewal 
date [date]. This quarter we delivered: [list]. Usage data: 
[active users, frequency, features used, features not touched]. 
Known issues: [support tickets, complaints, churn signals]. 
Their original goals: [what they said they wanted at signing].

Constraints:
- Structure the QBR as:
  1. Goals vs. reality (their stated goals at signing, 
     and where each one actually landed — on track, ahead, 
     or behind. Be honest. Hiding a miss loses the renewal 
     later, surfacing it now saves it.)
  2. The one number (the single metric that best proves 
     value this quarter — with the before/after)
  3. What we're worried about (the 1-2 risks to renewal — 
     low usage on a key feature, a champion who left, 
     a competitor being evaluated. Name it.)
  4. Next quarter's bet (the one thing we'll focus on to 
     compound value before renewal)
- Banned: vanity metrics (logins, "engagement," total users 
  if it's not tied to outcomes).
- If a goal from signing is behind, say so and propose 
  a fix in the same sentence. Don't bury it.

Output: A 1-page QBR brief. Slide-ready, but text first.

The "what we're worried about" section is why this prompt exists. Most QBRs are victory laps. The renewals you lose are the ones where the risk was visible for months and nobody said it out loud.

How I tested these

Each prompt was run three times against three different real inputs (real prospects, real calls, real deals). A prompt that only works once is an anecdote, not a tool. The ones above held up across inputs.

Then I generalized: does the prompt work for a different product, a different industry, a different deal size? If a prompt only works for "SaaS sold to VPs of Engineering," it's not a prompt — it's a script. These ten generalized.

Finally, I read every output aloud. Anything that sounded like marketing copy got cut. Anything that sounded like a human who'd done the job got kept.

What's in the full pack

These ten are the sales-specific slice. The full productivity library has 30 prompts across sales, marketing, ops, and customer success — each tested the same way, each with the Role→Context→Constraints→Output structure broken out so you can adapt them. There's also a $9 launch pack if you want the core seven to start.

The point isn't the prompts. The point is the structure. Once you can write Role→Context→Constraints→Output for your own job, you stop needing other people's prompt libraries — including mine.

If you found this useful, the best thing you can do is steal the structure, write your own prompt for the worst part of your week, and test it three times. That's the whole method.

10 AI Prompts I Use for Data Analysis (SQL, EDA, Stakeholder Summaries, Anomaly Hunting)

draftkit — Tue, 21 Jul 2026 15:30:57 +0000

Most "AI for data analysis" content is either too generic ("ask it to explain your data!") or too narrow ("here's a prompt that writes a GROUP BY"). Neither survives contact with a real Monday morning.

Below are 10 prompts I actually use as an analyst. Each one has the structure, the constraints that make it produce usable output instead of a confident-sounding hallucination, and a real example.

The pattern, as always: Role → Context → Constraints → Output format. The constraints are where the magic is. A prompt without constraints gives you a Wikipedia summary. A prompt with sharp constraints gives you a first draft you can ship.

1. SQL query from a business question (the one that doesn't hallucinate columns)

Role: You are a senior analyst writing SQL against a known schema.
Context: Business question: {question}. Schema (tables + columns + types): {DDL}. SQL dialect: {postgres/mysql/bigquery/snowflake}.
Constraints:

Only reference columns that exist in the schema I pasted. If the question needs a column that doesn't exist, say so explicitly — do not invent one.
Prefer CTEs over subqueries for readability.
Every JOIN must specify the join condition. No implicit joins.
Wrap column names with spaces or reserved words in double quotes.
If the query needs a window function, use it; do not fake it with a self-join.
Add a one-line comment above each CTE explaining what it returns.

Output: The SQL, then a 2-sentence explanation of the approach.

Why this works: Pasting the schema and constraining the model to it is the difference between a query that runs and a query that references a user_signups table you don't have.

2. Exploratory analysis plan for an unfamiliar dataset

Role: You are a senior data scientist planning the first 60 minutes of EDA on a new dataset.
Context: Dataset description: {what it is}. Columns + types: {list}. Row count: {approx}. Business context: {why we care}.
Constraints:

Output a numbered list of 8-10 specific analyses to run, in order.
For each, state the question it answers and the chart type to use.
The first three analyses must be data-quality checks (nulls, dupes, ranges), not business questions.
Flag any column that looks like a free-text field and propose how to handle it.
Do not propose machine learning in the first 60 minutes.

Output: An EDA plan, ordered.

3. Variance explanation for a non-technical stakeholder

Role: You are explaining a metric change to an executive who does not want to see SQL.
Context: Metric: {metric}. Change: {from X to Y, over period Z}. Driver breakdown (if known): {segment-level deltas}.
Constraints:

First sentence states the direction and magnitude in plain English ("Revenue dropped 12% last week").
Second sentence names the single biggest driver, as a share of the change.
Use a "what changed / what didn't / what we don't know yet" structure.
No p-values, no statistical jargon, no "the data suggests."
If a segment moved in the opposite direction of the headline, call it out — do not bury it.

Output: A 5-sentence summary.

Example (revenue dropped 12%):

Revenue dropped 12% last week, from $84k to $74k. The drop is almost entirely driven by the mid-tier plan, which fell 31%; enterprise and free-tier were flat. We did not lose customers — the mid-tier contraction was driven by 8 accounts downgrading to free. What we don't know yet is whether this is a reaction to the price change two weeks ago or a coincidence. I'm pulling the downgrade reasons from the exit survey today.

4. Anomaly investigation checklist

Role: You are an analyst who just got a spike/drop alert and needs to triage it.
Context: Metric: {metric}. Anomaly: {spike/drop of X% at time T}. Alerting system: {what fired}.
Constraints:

Produce a checklist of 6-8 investigation steps, ordered by "most likely cause" to "least likely."
Step 1 must be a data-pipeline check (did the data actually arrive? is the anomaly real or a pipeline gap?).
Include a "what would confirm this is not real" check.
For each step, state what result would point to that cause.
Do not recommend "monitor it" as a step — that's not an investigation.

Output: A numbered triage checklist.

5. Metric definition document

Role: You are writing the canonical definition for a business metric so that finance, product, and analytics stop arguing about it.
Context: Metric name: {name}. Intent: {what it's supposed to capture}.
Constraints:

Sections: Definition / Inclusions / Exclusions / Edge cases / Refresh cadence / Owner.
"Inclusions" and "Exclusions" must each have at least 4 concrete examples.
"Edge cases" must cover: refunds, trials, internal/test accounts, cross-currency, timezone.
The definition sentence must be one sentence that a non-analyst can repeat back.
Name the system of record (which table/view is authoritative).

Output: A metric definition doc, ready to drop into the metrics catalog.

6. Dashboard critique (the one that tells you what to cut)

Role: You are a senior analyst reviewing a dashboard for usefulness.
Context: Dashboard purpose: {stated purpose}. Charts: {list each chart + what it shows}. Audience: {who looks at it}.
Constraints:

For each chart, state: does it answer a decision? If not, recommend cutting it.
Identify any chart that duplicates information already on the dashboard.
Flag any chart where the audience would not be able to interpret the axis or filter.
Propose 1-2 charts that are missing and would actually drive a decision.
Do not recommend "make it more visually appealing" — that is not the problem.

Output: A chart-by-chart review with cut/keep/add recommendations.

7. Cohort analysis design

Role: You are designing a cohort analysis to answer a retention question.
Context: Question: {are monthly users retained better than weekly? / does the signup source matter? / etc.}. Available data: {user events, signup dates, etc.}.
Constraints:

Define the cohorting key (what groups users into a cohort).
Define the cohort size (weekly? monthly? why).
Define the retention metric (D7? D30? active-in-window? why).
State the comparison you're going to make and the decision it would drive.
Call out the selection bias risk — what kind of user is over-represented in this cohort definition?

Output: A cohort spec, not the query.

8. A/B test results summary (that doesn't overclaim)

Role: You are summarizing an A/B test for a product team.
Context: Hypothesis: {what we tested}. Variant: {what changed}. Samples: {n per arm}. Result: {lift, confidence interval, p-value}.
Constraints:

State whether the result is statistically significant, full stop.
If significant, state the effect size in the original units (not just "% lift").
Report the confidence interval, not just the point estimate.
Name one segment where the effect was different (if sliced). If not sliced, say so.
Explicitly state what this test does NOT prove (no causal claims beyond the intervention).

Output: A 4-sentence summary + 1-sentence recommendation.

Example:

The new checkout flow increased conversion from 3.1% to 3.4% (relative lift of +9.7%, 95% CI [+2.1%, +17.9%], p=0.012). This is statistically significant. The effect was consistent across desktop and mobile. This test proves the new flow converts better; it does not prove why, and it does not guarantee the lift holds at higher traffic.

9. Data quality report for a new table

Role: You are profiling a new table before anyone else uses it.
Context: Table: {name}. Columns + types: {list}. Sample rows: {paste 5 rows}.
Constraints:

For each column, report: null rate (if estimable from sample), distinct values, min/max or top-3 values.
Flag any column with inconsistent formatting (dates in two formats, mixed case IDs).
Flag any column that looks like it should be unique but isn't.
Identify likely foreign keys and state whether they appear to join to the expected parent table.
Rate overall trust: production-ready / use-with-caveats / do-not-use-yet.

Output: A profiling report with a trust rating.

10. Stakeholder question → analysis plan (the de-scoping prompt)

Role: You are a senior analyst responding to a vague stakeholder ask.
Context: The ask (verbatim): {paste}. Stakeholder: {role}. Timeline: {how much time they have}.
Constraints:

Restate the question in your own words to confirm understanding.
Identify the 2-3 sub-questions buried in the vague ask.
For each sub-question, state whether the data exists to answer it.
Propose the minimum viable analysis (the 20% that answers 80% of the question).
Explicitly name what you are NOT going to do, and why (data doesn't exist / not worth the time / out of scope).

Output: A reply to the stakeholder that confirms scope and de-scopes gracefully.

How I test analysis prompts

Run it on a dataset you already understand. If the prompt's EDA plan misses something you know is in the data, the constraints are too loose.
Check the SQL against an actual schema. Hallucinated columns are the #1 failure mode. If you don't paste the schema, you will get invented table names.
Read the stakeholder summary aloud. If it sounds like a data scientist wrote it for another data scientist, rewrite the constraints to ban jargon.

The library these came from

These prompts are part of a larger library I've built and tested across real analysis, product, and engineering work. If you want the full set:

Developer Product-Launch Prompt Pack ($9) — 7 prompts for launching data-informed products: gum.co/qevvy
Developer Productivity Prompt Library ($49) — 30 prompts including data + engineering workflows: gum.co/plytri
SaaS Marketing Copy Prompt Pack ($49) — 25 prompts for analytics-informed marketing: gum.co/orcwxs
AI Startup Operations Prompt System ($199) — 50+ prompts + 10 workflows for running a data-driven company: gum.co/aeqnd
AI Business Transformation Playbook ($999) — 100+ prompts + 12 workflows, the full system: gum.co/boivub

The $9 pack is the cheapest entry point. If it saves you one round of "what column is that again?" it's paid for itself.

The structure is the asset, not the specific prompts. Once Role → Context → Constraints → Output is muscle memory, you'll write your own for every repeatable part of your analytical workflow. The 10 above are the ones that have survived actual weekly use.

If you've got an analysis prompt that outperforms these, I want to see it — the best prompts always come from people who run queries every day.

10 AI Prompts I Use for Customer Support (Tickets, Macros, Escalations, Churn Saves)

draftkit — Tue, 21 Jul 2026 15:30:02 +0000

If you work in customer support, AI can take the boring 70% of your job — the boilerplate replies, the thread summaries, the macro drafting — and leave you with the parts that actually need a human: judgment, empathy, and the messy edge cases.

I've spent the last year refining prompts for support work. Below are the 10 I use every week. Each one has a structure, a set of constraints that matter, and a real example output so you can see what good looks like.

The pattern across all of them: Role → Context → Constraints → Output format. Skip the constraints and you get generic slop. Keep them and you get something you can actually send.

1. The macro that doesn't sound like a macro

Role: You are a senior support specialist writing a reusable macro.
Context: Product is {product}. Common issue: {issue}. Customer tier: {free/pro/enterprise}.
Constraints:

Max 4 sentences.
No "Hi there!" or "Thanks for reaching out!" — open with the answer.
No apology unless the issue is actually our fault.
End with one specific next step, not "let us know if you need anything else."
If a workaround exists, state it before the root-cause explanation.

Output: A macro body, ready to paste into the ticket.

Example (issue: webhook deliveries delayed):

Webhook deliveries are currently running ~15 minutes behind due to a backlog on our processing cluster. Deliveries are not being dropped — they will all complete, just delayed. As a workaround until we clear the backlog, you can poll the /events endpoint on a 60-second interval. We'll post an update in the status page within the hour.

2. De-escalating an angry ticket without sounding robotic

Role: You are a support lead handling an escalated, frustrated customer.
Context: Ticket: {paste ticket}. Customer is {describe emotional state from their message}.
Constraints:

First sentence acknowledges the specific impact they described — not a generic "I understand your frustration."
Name the thing we got wrong, plainly. No "seems like there may have been."
Do not promise a resolution timeline you don't control.
Offer exactly two options: (a) what we can do right now, (b) what we can do if they want to wait.
Tone: calm peer, not apologetic subordinate.

Output: A reply draft.

3. Thread summary for engineering (the one that actually gets read)

Role: You are a support engineer summarizing a long ticket thread for the engineering team.
Context: Full thread: {paste thread}. Suspected bug area: {area}.
Constraints:

Use this structure: What they expected / What happened / Steps to reproduce / Reproduction rate / Account + resource IDs / Already tried.
"Steps to reproduce" must be numbered and each step must be one action.
"Reproduction rate" must be a fraction (e.g., 3/5 attempts), not "sometimes."
Cut every pleasantry, signature, and back-and-forth from the summary. Engineering does not need the "any update?" pings.
If the customer shared logs, quote the exact error line — do not paraphrase.

Output: A summary under 200 words, formatted for a Slack thread or bug ticket.

4. Changelog entry from a support perspective

Role: You are writing a customer-facing changelog entry for a fix that support has been fielding tickets about.
Context: Fix: {describe}. Tickets this resolves: {count or themes}.
Constraints:

Lead with what the customer will notice, not what we changed internally.
One sentence on the symptom, one on the fix, one on what to do if they still see it.
No version numbers or internal identifiers in the customer-facing line.
If action is required on their side, flag it in bold at the end.

Output: A changelog entry (3-4 sentences).

5. Churn-save email for an at-risk account

Role: You are a customer success manager writing to an account that has signaled churn risk.
Context: Account: {name}. Signal: {reduced usage / support complaint / downgrade request}. Contract value: {tier}. Last positive interaction: {what it was}.
Constraints:

Do not offer a discount in the first email. Discounts train customers to threaten churn.
Reference one specific outcome they've gotten from the product (pull from usage).
Propose a 20-minute call with a specific agenda — not "to check in."
Subject line must be lowercase, 5 words or fewer, and not contain the word "touching" or "checking."
End with a question that requires a substantive answer, not a yes/no.

Output: An email under 120 words.

6. Internal knowledge base article from a resolved ticket

Role: You are turning a resolved ticket into a reusable knowledge base article.
Context: Ticket resolution: {paste}. Product area: {area}.
Constraints:

Title is phrased as the customer would search for it, not as engineering would name it.
Structure: Symptom → Cause → Fix → Verification. Each section is its own H2.
"Fix" steps are numbered and each starts with a verb.
Include a "When this doesn't apply" section listing 2-3 similar-looking issues that are actually different.
No internal links or agent-only context.

Output: A KB article in markdown, ready for the help center.

7. Bug report from a vague customer complaint

Role: You are a support agent converting a vague customer complaint into a structured bug report.
Context: Customer message: {paste}. Environment (if known): {browser/OS/plan}.
Constraints:

Fill the standard bug template: Title / Environment / Steps to reproduce / Expected / Actual / Severity / Frequency / Attachments.
If the customer didn't provide steps, write "Steps not provided — requesting from customer" rather than inventing them.
Severity must be justified in one sentence using impact, not urgency ("blocks checkout for 100% of mobile users" not "customer is very upset").
List the 3 most likely related code areas for engineering to check first.

Output: A filled bug report.

8. Onboarding reply for a confused new user

Role: You are responding to a new user who is confused about where to start.
Context: Product: {product}. Their signup signal: {what they said they want to do}.
Constraints:

Do not send them to the docs homepage. Link the one specific page that matches their goal.
Give them exactly one first action, not a list of five things to explore.
Acknowledge what they're trying to accomplish before telling them how.
Keep it under 6 sentences. Over-explaining signals the product is complicated.

Output: A reply.

9. Quarterly review of recurring ticket themes

Role: You are a support manager analyzing the last quarter's tickets for product and process improvements.
Context: Ticket themes (paste list or CSV): {themes}. Volume per theme: {counts}.
Constraints:

Group into 3 buckets: product bugs / documentation gaps / feature requests.
For each theme, state the likely root cause category (not the specific fix).
Rank by {volume × severity}, not volume alone.
Propose one process change that would eliminate the top theme — not a tool, a process.
Do not recommend "more training" as a solution.

Output: A review under 400 words with a prioritized table.

10. Post-resolution follow-up that earns a reply

Role: You are sending a follow-up 3 days after resolving a ticket to confirm the fix held.
Context: Original issue: {issue}. Resolution: {what we did}.
Constraints:

Subject references the specific issue, not "following up."
One sentence confirming it's resolved on our end.
One direct question: is it still working for them?
No satisfaction survey link in this email — that belongs in a separate cadence.
If they don't reply, that's a positive signal; frame the email so non-reply is acceptable.

Output: A 3-sentence email.

How I test prompts like these

Three habits that separate prompts that work from prompts that produce slop:

Run it 3 times on the same input. If the outputs vary wildly in quality, the prompt is under-specified. Tighten the constraints.
Generalize one step. After it works for support tickets, try it on a sales email or a PM user story. If the structure breaks, the constraints were too narrow.
Read it aloud. If the output sounds like an AI wrote it, add a negative constraint ("no em-dashes," "no 'delve', 'leverage', 'seamless'"). The banned-words list is the single biggest quality lever.

The pack these came from

These prompts are pulled from a larger library I built and tested across real support, product, and engineering work. If you want the full set — 50+ prompts covering support, product management, engineering management, marketing copy, and founder workflows — it's here:

Developer Product-Launch Prompt Pack ($9) — 7 prompts for launching products: gum.co/qevvy
Developer Productivity Prompt Library ($49) — 30 prompts for engineering + support workflows: gum.co/plytri
SaaS Marketing Copy Prompt Pack ($49) — 25 prompts for landing pages, emails, ads: gum.co/orcwxs
AI Startup Operations Prompt System ($199) — 50+ prompts + 10 workflows for running a company with AI: gum.co/aeqnd
AI Business Transformation Playbook ($999) — 100+ prompts + 12 workflows, the full system: gum.co/boivub

The $9 pack is the cheapest way in — if it saves you one ticket-writing session, it's paid for itself.

The pattern matters more than the specific prompts. Once you internalize Role → Context → Constraints → Output format, you can write your own for any repeatable part of your job. The prompts above are just the ones I've found survive contact with real tickets.

If you've got a support prompt that works for you, I'd genuinely like to see it — the best ones always come from the people closest to the tickets.

A Beginner's Guide to Prompt Engineering: 7 Patterns That Work on Any LLM

draftkit — Tue, 21 Jul 2026 14:41:42 +0000

Most "prompt engineering" advice online is a list of magic phrases someone swears by. "Start with 'You are an expert.'" "End with 'think step by step.'" "Use the word 'delve.'"

Here's the thing: none of those words matter on their own. What matters is structure. After writing and testing hundreds of prompts across GPT, Claude, Gemini, and open models, I've found that every prompt that works falls into one of seven patterns. Learn the patterns and you can write a good prompt for any task on any model — without memorizing magic phrases.

This is the guide I wish I'd had when I started.

Pattern 1: Give the model a role

Tell the AI who it's supposed to be. This isn't theater — it loads relevant context into the response.

Weak:

Write a bug report.

Strong:

You are a senior QA engineer who has filed 500+ bug reports. Write a bug report for this issue: [DESCRIBE].

The role "senior QA engineer" pulls in conventions the model knows: repro steps, expected vs actual, severity levels. Without the role, you get a generic description.

When to use it: Always. It's the cheapest improvement you can make.

Pattern 2: Give context and constraints separately

The two most common mistakes are (a) not giving enough context, and (b) burying constraints inside the context so the model ignores them.

Structure your prompt so context and constraints are visually separate:

Context: I'm writing a cold email to a VP of Engineering at a Series B startup. Our product is an AI code reviewer. They just posted about hiring 5 senior engineers.

Constraints:

Subject line: max 5 words, no capitalization (looks human)

Body: max 90 words

No exclamation marks, no "revolutionary," no "game-changer"

End with a question, not a meeting link

Output: The subject line on its own line, then the body.

Notice how the constraints are a bulleted list. Models follow bulleted constraints far more reliably than constraints buried in a paragraph.

When to use it: Anytime the output needs to follow rules (length, tone, format, banned words).

Pattern 3: Few-shot examples

Show, don't tell. Give the model 1–3 examples of the input → output you want, then give it a new input.

Convert each customer complaint into a structured ticket.

Example 1:
Input: "The app keeps crashing when I upload photos."
Output: {"issue": "crash", "trigger": "photo upload", "severity": "high", "area": "mobile"}

Example 2:
Input: "Can't log in, says invalid token."
Output: {"issue": "auth_failure", "trigger": "login", "severity": "high", "area": "auth"}

Now convert:
Input: "Took forever to load the dashboard this morning."

Few-shot is the single most reliable way to get consistent formatting. It works because the model learns the pattern from examples better than from description.

When to use it: Whenever you need a specific output format, especially structured data (JSON, tables, tickets).

Pattern 4: Chain-of-thought (but only when it helps)

"Think step by step" became famous because it improves performance on math and logic problems. But it doesn't help — and can hurt — on simple tasks.

Use chain-of-thought when the task has multiple reasoning steps:

A customer's order shipped on Tuesday and was supposed to arrive in 3 business days. Today is the following Monday. They're asking for a refund. Walk through whether they're eligible step by step, considering our policy: [PASTE POLICY]. Then give a verdict.

For simple tasks ("summarize this paragraph"), skip it. Adding "think step by step" to a summary just makes it longer for no benefit.

When to use it: Math, eligibility/logic checks, multi-step decisions, debugging.

Pattern 5: Specify the exact output format

The #1 reason AI output is hard to use: the model decides its own format. Fix this by being explicit.

Output a markdown table with these columns: Tool | Price | Best For | Limitation.
One row per tool. No intro paragraph, no outro paragraph. Just the table.

Or for code:

Output only the function. No explanation before or after. No markdown code fences if I'm pasting into an editor.

The "no intro, no outro" instruction alone will save you from deleting hundreds of words of filler.

When to use it: Always, if you're going to paste the output somewhere. Vagueness costs you editing time.

Pattern 6: Negative constraints (ban the filler)

Models have verbal tics. They love "certainly," "I'd be happy to," "it's important to note," and "in conclusion." You can ban them.

Do not use any of these phrases: "certainly," "I'd be happy to," "it's important to note," "in conclusion," "feel free to," "delve," "robust," "leverage," "seamless."
Do not add an opening or closing paragraph. Start with the content directly.

Negative constraints are powerful because models are predictable about which filler they reach for. Banning the top 5 cleans up most output.

When to use it: Whenever you're editing out filler repeatedly — that's a signal to ban it at the source.

Pattern 7: Iterate — your first prompt is a draft

Nobody writes a perfect prompt on the first try. The process is:

Write the prompt
Run it
Look at the output and ask: what's wrong with it?
Add a constraint or example that fixes that specific problem
Run it again
Repeat until the output is usable

I typically go through 3–5 iterations before a prompt is production-ready. The iteration is the engineering in "prompt engineering."

Pro tip: Save your final prompt in a document. Next time you have a similar task, start from it instead of from scratch. Over a few months you build a personal library that makes you dramatically faster.

Putting it all together: a real example

Here's a prompt that uses all seven patterns at once:

Role: You are a technical writer who simplifies API docs for junior developers.

Context: I'm documenting an endpoint that returns user notifications. The current docs assume the reader knows webhooks. Junior devs don't.

Constraints:

Max 150 words for the explanation

Assume the reader has never heard of a webhook

Include one code example in JavaScript

Ban these words: "simply," "just," "obviously," "straightforward"

Examples of the tone I want:
Instead of "Simply subscribe to the webhook," write "Tell our server to send you updates by registering a URL."

Output: A heading, the explanation, then the code block. No intro or outro.

This prompt works because each pattern handles a different failure mode. The role loads the right conventions. The constraints control length and tone. The example shows the voice. The output format saves editing.

Common mistakes to avoid

Too long, too early. Don't write a 500-word prompt for a simple task. Start minimal and add constraints only when the output disappoints you.
Trusting the first output. Always check. Models hallucinate confidently.
Copy-pasting magic phrases. "Act as a world-class expert" does nothing if the rest of your prompt is vague.
Skipping the output format. This is the #1 time-waster. Tell the model exactly what shape you want.

These seven patterns are the foundation. Once you internalize them, you stop hunting for "the perfect prompt" and start engineering prompts that work. I've collected the prompts I use most — across writing, coding, marketing, and operations — into a few packs. If you want a tested starting point, the Developer Product-Launch Prompt Pack has 7 prompts you can copy today, and the Developer Productivity Prompt Library has 30 for everyday dev work.

What pattern has made the biggest difference in your prompts? I'm always refining the list.

10 AI Prompts I Use for DevOps and SRE Work (Incidents, Runbooks, On-Call)

draftkit — Tue, 21 Jul 2026 14:40:52 +0000

On-call shifts used to eat my evenings. The worst part wasn't the 2 AM page — it was writing up the incident afterward, updating the runbook, and explaining what happened to leadership in a way that didn't sound like panic.

Over the last year I built a small library of AI prompts specifically for DevOps and SRE work. These aren't "write me a status update" filler. Each one solves a concrete operational problem: turning a messy incident timeline into a postmortem, generating a runbook from a Slack thread, writing an on-call handoff that the next person can actually follow.

Here are 10 prompts I use regularly, with the structure behind each one and a real example output so you can see what good looks like.

The structure I use for every prompt

Every prompt below follows four parts:

Role — who the AI is pretending to be
Context — the situation and constraints
Constraints — the rules it cannot break
Output — the exact format

Skip any part and the output drifts into generic noise. I learned this the hard way.

1. Incident timeline → structured timeline

You are an SRE writing an incident timeline for a postmortem.
Here is a raw timeline from Slack, dashboards, and pager messages, pasted out of order: [PASTE].
Produce a clean chronological timeline. Each entry: timestamp (UTC), event, source (which tool/person), and severity (info/warning/critical). Merge duplicate events. Flag any gap longer than 5 minutes as "[GAP — investigate]". Do not invent events that aren't in the source.

Why it works: SREs paste timelines out of order because that's how you reconstruct them. This prompt forces the AI to deduplicate, normalize timestamps, and explicitly flag gaps — the gaps are usually where the real story is.

2. Blameless postmortem draft

You are an SRE writing a blameless postmortem.
Incident: [SHORT DESCRIPTION]. Timeline: [PASTE]. Root cause (if known): [DESCRIBE].
Write a postmortem with these sections: Summary (3 sentences), Impact (duration, affected users, revenue if known), Timeline, Root Cause, Contributing Factors, What Went Well, What Went Wrong, Action Items.
Rules: every Action Item must have an owner, a due date, and a priority (P0/P1/P2). Never attribute fault to a person — always to a system, process, or missing safeguard. Ban the phrase "human error" — replace it with the specific missing safeguard that would have prevented it. If root cause is unknown, write "Under investigation" rather than guessing.

Why it works: The "ban human error" constraint is the single most important line. It forces the AI to surface the actual safeguard gap (no alert, no runbook step, no rate limit) instead of blaming the on-call engineer.

3. Runbook from a Slack thread

You are an SRE writing a runbook from a loose Slack thread where engineers debugged an issue.
Thread: [PASTE].
Produce a numbered runbook. Each step must be completable in under 5 minutes. Start each step with an action verb (Check, Restart, Verify, Roll back, Scale). Add a "What NOT to do" section preserving the wrong turns from the thread — those are the real lessons. Add a "Prerequisites" section (access, tools, permissions needed).

Why it works: The wrong turns are more valuable than the right steps. Most AI-generated runbooks delete them. This prompt forces them to survive as a "What NOT to do" section, which is where the next on-call engineer actually learns.

4. On-call handoff document

You are an SRE writing an on-call handoff for the engineer taking over the rotation.
Here are my open issues, in-progress mitigations, and watch items: [PASTE].
Write a handoff with three sections: (1) Active Incidents — status, current mitigation, next check-in time; (2) Watch Items — things that aren't incidents yet but could escalate, with the threshold that would make them one; (3) Heads Up — anything weird from my shift the next person should know. Keep it under 200 words. The first line must be either "Nothing active — quiet shift" or "X active incidents" so the next person knows the severity in one second.

Why it works: The forced first line ("Nothing active" vs "X active incidents") means the incoming on-call engineer knows the stakes before reading anything else. Most handoffs bury the lead.

5. Capacity planning memo

You are an SRE writing a capacity planning memo for leadership.
Service: [NAME]. Current: [QPS/CPU/MEM/DISK]. Growth rate: [% per month]. Headroom threshold: [%]. Budget: [$ or "not specified"].
Project when we hit the headroom threshold (show the math). Recommend 3 options ranked by cost: (1) cheapest short-term, (2) balanced, (3) long-term architectural change. For each: cost estimate, time to implement, risk, and what breaks if we do nothing. No jargon in the executive summary — assume the reader has never heard of this service.

Why it works: The "show the math" constraint kills the AI's tendency to hand-wave. The three ranked options force a real decision instead of "we should monitor the situation."

6. Alert deduplication review

You are an SRE reviewing alert fatigue. Here is a list of all alerts fired in the last 7 days with frequency: [PASTE].
Group alerts that likely have the same root cause. For each group: list the alerts, estimate how many pages they caused, and recommend ONE of: keep as-is, make multi-alert (group by 15 min), make info-only, or delete entirely. Prioritize reducing pages without losing signal. Flag any alert that fired more than 10 times as a candidate for a runbook or auto-remediation.

Why it works: Alert fatigue is the #1 quality-of-life issue for on-call engineers. This prompt treats alerts as a clustering problem and forces a concrete recommendation per group, not a vague "consider tuning."

7. Change failure summary for the changelog

You are an SRE summarizing a failed deployment for the public changelog and internal retro.
Deployment: [DESCRIBE]. What happened: [PASTE]. Rollback: [YES/NO, HOW].
Write two versions: (1) External — 2 sentences, customer-facing, no internal service names, states the impact and the fix. (2) Internal — the same story with the actual service names, the rollback mechanism, and one process change that would catch this next time. Both versions must be honest about the impact — do not minimize.

Why it works: Writing the external version forces honesty without exposing internals; the internal version forces a process change. The "do not minimize" constraint prevents the corporate reflex to downplay.

8. Health check → alerting rule

You are an SRE turning a manual health check into an automated alerting rule.
Manual check: [DESCRIBE what you do — e.g. "I curl /health and check the db_latency field is under 100ms"].
Generate a Prometheus-style alerting rule (or [OTHER SYSTEM]). Specify: metric name, threshold, for-duration, severity, and the runbook link to attach. Explain the threshold choice in one sentence. Suggest one related alert that would catch the failure mode this one misses.

Why it works: The "suggest one related alert that catches the failure mode this misses" line is gold — it forces the AI to think about what a single alert can't see.

9. Disaster recovery walkthrough script

You are an SRE writing a DR (disaster recovery) test walkthrough for the team to run quarterly.
Service: [NAME]. RTO: [X min]. RPO: [Y min]. Backup mechanism: [DESCRIBE].
Write a step-by-step DR test script. Each step: action, expected result, and what to do if the result differs (roll back? escalate?). Include a "Time check" after every step — if we're past the RTO, stop and document where we are. End with a pass/fail criteria section that's binary, not subjective.

Why it works: DR tests fail silently when the criteria are vague ("it basically worked"). Binary pass/fail and time-check-per-step make the test honest. The "stop if past RTO" rule prevents the common failure of running past the recovery objective and pretending it passed.

10. Cost anomaly investigation starter

You are an SRE investigating a cloud cost spike.
Bill summary: [PASTE — service, amount, period]. Normal baseline: [$].
List the 5 most likely causes of a spike of this size, ranked by probability for [AWS/GCP/Azure]. For each: how to confirm it (the exact metric or report to check), and how to fix it. Do not list generic advice — every item must be verifiable in under 10 minutes.

Why it works: Cost spikes are urgent and the AI's default is generic "check for unused resources." The "verifiable in under 10 minutes" constraint forces specific, checkable causes.

How I test these prompts

Before I trust a prompt in production, I run it 3 times on the same input. If the output structure stays consistent but the wording varies naturally, the prompt is stable. If the structure changes, the constraints are too loose — I tighten the Output section.

I also read every output aloud. If it sounds like it could have been written for any company, it's too generic and I add company-specific context.

These prompts are part of a larger set I use across engineering, operations, and product work. If you want the full operations-focused collection (50+ prompts covering incidents, capacity, on-call, deployments, and team workflows), I keep them here: AI Startup Operations Prompt System. For a lighter starting point, the $9 launch-day prompt pack covers the essentials.

What DevOps or SRE prompts have saved your shift? I'm always looking to add to the library.

I Built a Personal AI Prompt Library. It Changed How I Work Forever.

draftkit — Tue, 21 Jul 2026 14:20:09 +0000

Everyone uses AI prompts ad-hoc. You type something, get a result, use it, and forget the prompt. Then next week you type something worse and get worse results.

Building a prompt library changed that for me. Here's how.

The problem with ad-hoc prompting

You reinvent the wheel every time
You can't reproduce good results
Your prompts degrade over time (you forget what worked)
You can't share them with your team
You never improve them systematically

How a prompt library works

Every prompt is stored with:

Name (what task it handles)
Tags (when to use it)
Variables (what you fill in)
Output format (what you get)
Quality notes (what to watch for)
Version (how many times you've refined it)

Example entry:

Name: Launch Tweet Generator
Tags: marketing, product-launch, twitter
Variables: [PRODUCT], [KEY_FEATURE], [LINK]
Output: 3 tweet variants
Quality: Works best when product has a clear pain point. 
         Avoid if product is too abstract.
Version: 4 (refined after 20+ uses)
Prompt:
Write 3 launch tweets for [PRODUCT]. Each must:
- Under 280 chars
- Lead with problem or result
- One concrete number
- Vary tone: confident, humble, data-driven
- End with soft CTA

The workflow

When you need to do a task, check the library first
If a prompt exists, use it and note any improvements
If not, write one, test it 3 times, and add it to the library
Periodically review and refine existing prompts

What changes

Tasks that took 30 minutes now take 5
Output quality is consistent, not random
You build up institutional knowledge
New team members ramp faster
You stop paying for tools that just wrap prompts in UI

How to start

You can build your own library from scratch (testing each prompt 5+ times, refining over weeks). Or you can start with a pre-built, tested collection.

My library of 200+ tested prompts:

$9 starter pack (7 prompts): https://innovate01.gumroad.com/l/qevvy
$49 developer pack (30 prompts): https://innovate01.gumroad.com/l/plytri
$49 marketing pack (25 prompts): https://innovate01.gumroad.com/l/orcwxs
$199 operations system (50+ prompts + workflows): https://innovate01.gumroad.com/l/aeqnd

The point isn't the product. The point is having a SYSTEM instead of ad-hoc prompting. Whether you build it yourself or start with mine, organize your prompts.

How to Write README Files That Developers Actually Read (With AI Prompts)

draftkit — Tue, 21 Jul 2026 14:19:33 +0000

A bad README kills adoption. A good README drives stars, forks, and contributions. Here's how to write ones developers actually read — using AI prompts.

Why most READMEs fail

They're too long (nobody reads 500-line READMEs)
They lead with installation instead of the problem
They assume the reader already cares
They have no quick start (just walls of configuration)
They don't show what the tool actually does

The README prompt

Write a README for [PROJECT].
Structure:
1. Project name + one-line description (what it does)
2. Badges (build status, version, license)
3. Why this exists (the problem it solves — 2 sentences)
4. Quick start (3 commands maximum to get running)
5. What it does (3-5 bullet points, outcome-focused)
6. Configuration (table format, only essential options)
7. Examples (1-2 real usage examples)
8. Contributing (how to contribute, link to guidelines)
9. License

Constraints:
- Write for someone who skims
- No walls of text
- Use code blocks for all commands and code
- If a section would be longer than 5 lines, use bullets

Example output

# DataPipe

Fast, lightweight ETL pipeline for small-to-medium datasets.

[![Build Status](badge)] [![Version](badge)] [![License: MIT](badge)]

## Why

Most ETL tools are enterprise-grade and complex. DataPipe handles the 80% case: moving data between databases, APIs, and files — without a learning curve.

## Quick Start

npm install datapipe
datapipe init
datapipe run

## What it does

- Moves data between PostgreSQL, MySQL, CSV, JSON, and REST APIs
- Handles schema mapping automatically
- Runs transformations with JavaScript expressions
- Schedules recurring pipelines
- Logs everything for debugging

## Configuration

| Option | Default | Description |
|--------|---------|-------------|
| source | required | Connection string or file path |
| target | required | Connection string or file path |
| transform | null | Optional JavaScript expression |
| schedule | null | Cron expression for recurring runs |

The pattern

Every README should answer 3 questions in order:

What does this do? (first line)
Why should I care? (second paragraph)
How do I try it? (quick start)

Everything else is reference material that goes below the fold.

The full developer productivity library (30 prompts including README, code review, testing, debugging, and documentation prompts): https://innovate01.gumroad.com/l/plytri ($49)

Start with the $9 pack: https://innovate01.gumroad.com/l/qevvy