Enterprise GenAI Prompt Library

You are a B2B sales rep writing a first-touch email to {{prospect_name}}.

Their LinkedIn profile summary:
"""
{{linkedin_summary}}
"""

Their recent posts / activity:
"""
{{recent_activity}}
"""

Our product does: {{product_one_liner}}.

Write a 4-sentence email that:
1. Opens with something specific from their profile or recent activity (not their job title).
2. Bridges to a business problem their role plausibly faces.
3. Positions our product as one specific way to address it — not a full pitch.
4. Ends with a low-friction ask (e.g., "would a 15-min chat next Tue work?").

Do not fabricate anything about them. If a bridge sentence is not warranted from the material, say "insufficient signal" instead of guessing.

Below is our current proposal / pitch, followed by the target persona.

Proposal:
"""
{{proposal_text}}
"""

Target persona: {{persona_role}}. Their top priorities are: {{persona_priorities}}. Their skepticisms are: {{persona_skepticisms}}.

Rewrite the proposal so that:
- Every value proposition connects to their listed priorities.
- Skepticisms are addressed directly (not ignored).
- Jargon that would land with a different persona (e.g., engineering detail for a CFO) is either translated or removed.
- Structure and word count stay close to the original.

Return the rewritten proposal only.

Extract structured next-step data from the meeting notes below.

Meeting notes:
"""
{{notes}}
"""

Return a JSON object matching this schema:
{
  "next_steps": [{ "owner": string, "action": string, "due": string_or_null }],
  "blockers": [{ "blocker": string, "owner_to_unblock": string }],
  "stakeholder_updates": [{ "name": string, "role_or_change": string }],
  "deal_signals": [{ "signal": string, "sentiment": "positive"|"negative"|"neutral" }],
  "summary": string
}

If a field has no items, return an empty array. Do not invent an item to avoid an empty array. Preserve names exactly as written.

You are drafting an enterprise case-study skeleton from the interview transcript below.

Transcript:
"""
{{transcript}}
"""

Produce:
1. Two-sentence problem statement in the customer's voice.
2. Three-step approach summary (max 20 words each).
3. Up to five quantified results (only include those actually mentioned in the transcript).
4. Three pull-quote candidates (verbatim from the transcript), each with the speaker attribution.
5. Two risks / caveats the customer mentioned that we should be careful about in publication.

Never invent metrics. If a claim is not sourced in the transcript, omit it.

Score the lead below against our Ideal Customer Profile.

ICP definition: {{icp_definition}}
Weighted criteria: {{weighted_criteria_json}}

Lead data:
"""
{{lead_data}}
"""

Return JSON with:
- per_criterion: [{ criterion, weight, score_0_to_5, one_line_reasoning, evidence_source }]
- weighted_total: number 0-5
- classification: "hot"|"warm"|"nurture"|"disqualify"
- top_3_risks: string[]

Base every score on lead data or public info you can cite. Where data is missing, score = null and reasoning = "data missing".

Produce an article outline for the target search keyword: {{keyword}}.
Buyer persona: {{persona}}.
Article goal: {{goal}}.

Deliver:
1. Search intent classification (informational / commercial / navigational / transactional).
2. Three People-Also-Ask questions this article must answer.
3. Sectioned outline (H2 + H3) covering the full intent.
4. One quantified stat per section that would strengthen it (mark [research needed] — do not fabricate).
5. Three internal-link opportunities to our existing content: {{our_content_topics}}.
6. Meta title (<=60 chars) and meta description (<=155 chars).

Do not invent statistics. Mark every claim requiring a source as [research needed].

Build a competitive positioning matrix.

Our product: {{our_product_description}}
Competitors: {{competitors_json}}
Buying criteria: {{buying_criteria}}
Sources (public): {{public_source_snippets}}

Return a Markdown table with:
- Row per buying criterion
- Column per competitor + ours
- Each cell: Strong / Moderate / Weak, followed by one supporting fact per public source
- Cells where no source exists: mark "unknown" — do not infer from brand impression

Below the table, list the three criteria where we are strongest and the three where we are weakest.

Analyze the lost-deal notes below.

Notes:
"""
{{notes}}
"""

Return JSON:
- primary_loss_reason: one of ["price", "features", "integration", "trust", "timing", "champion_lost", "other"]
- secondary_factors: string[]
- signals_missed: [{ signal, when_visible: "discovery"|"proposal"|"negotiation"|"close", how_to_catch_earlier }]
- what_we_did_well: string[]
- proposed_playbook_updates: string[]

Base every entry on the notes. If a category is not evident, return [].

Draft a multi-channel campaign brief.

Concept: {{concept}}
Target segment: {{segment}}
Available channels: {{channels}} (e.g., email, LinkedIn ads, webinar, direct mail, sales outbound)
Business goal + measurable target: {{goal_and_target}}

Produce:
1. Campaign narrative in 3 sentences.
2. Per-channel: hook (<=15 words), primary CTA, sequence position (1-N), what makes it channel-appropriate.
3. Timeline: week-by-week for 6 weeks.
4. Instrumentation: how each channel's contribution to the business goal will be measured.
5. Kill criteria: what signal would cause us to pull the campaign.

Review the pull request diff below at the architectural / risk level, not line by line.

Diff:
"""
{{diff}}
"""

Context: {{repo_purpose_and_norms}}

Answer:
1. What is this PR actually trying to change (in one sentence)?
2. What system properties (availability, correctness, performance, security, cost) does it affect?
3. Which invariants does it protect, and which does it put at risk?
4. What is the blast radius if this ships broken?
5. What tests or observability would you add before merge?
6. What is one thing you would push back on?

Do not restate what the diff clearly says. Focus on what a senior reviewer would ask that an automated linter would not.

Structure the user bug report below into a repro plan.

Report:
"""
{{report}}
"""

Product context: {{product_context}}

Return:
1. Restatement of the bug in one sentence.
2. Minimal repro steps as an ordered list. Each step: user action, expected system state after, actual state per user.
3. Missing information — what would you ask the user to gather next?
4. Two most likely component / code-path candidates (name them; do not speculate on cause).
5. Severity classification (data-loss / broken-workflow / degraded-UX / cosmetic) with reasoning.

Design a phased migration for the breaking change below.

Change: {{change_description}}
Consumers: {{consumer_list}}
Constraints: {{constraints}} (e.g., zero-downtime, no schema change on the DB primary, no client re-issue)

Deliver:
1. Compatibility strategy — which of dual-write, versioned endpoint, feature-flag, or migration adapter fits best, and why.
2. Phased plan: T-N weeks → T+N with per-phase owner, exit criteria, and rollback trigger.
3. Communication plan — who is notified, when, and via which channel.
4. Instrumentation — what metrics tell us the migration is on track or in trouble.

Turn the rough proposal below into an RFC.

Sketch:
"""
{{sketch}}
"""

Team RFC template sections: Problem, Non-goals, Approach, Alternatives considered, Risks + mitigations, Rollout, Open questions.

Fill each section. For any section where the sketch does not contain enough information, write "[decision needed]" — do not invent commitments. Preserve the sketch author's technical instincts; do not silently upgrade decisions.

Draft a blameless postmortem for the incident described below.

Incident timeline (chronological):
"""
{{timeline}}
"""

Impact summary: {{impact}}
Root cause hypothesis (may be incomplete): {{root_cause_hypothesis}}

Produce sections:
- Executive summary (max 5 sentences)
- Timeline (from your input, cleaned up)
- What went well (specific actions, not vague praise)
- What went poorly (specific processes, not people)
- Contributing factors (technical + process + tooling)
- Action items (owner + rough date + linked issue placeholder)
- Detection improvements
- Response improvements

Follow blameless conventions: no attribution to individuals for errors. If the timeline attributes actions to a person, replace with role.

Sanity-check the design below against its stated constraints.

Design:
"""
{{design}}
"""

Constraints (in priority order): {{constraints}}
Anti-goals: {{anti_goals}}

For each constraint, answer:
- Does the design satisfy it? (yes / no / unclear)
- Where in the design is it demonstrated (or missing)?
- What would break it?

Then flag any anti-goal the design violates. Do not restate the design; assume the reader has read it.

Review the API design below.

API surface:
"""
{{api_definition}}
"""

Existing API conventions in our ecosystem: {{existing_conventions}}

Cover:
1. Consistency with existing conventions (naming, pagination, filtering, sorting, error shape).
2. Ergonomics — is the happy path obvious? Are common operations easy? Are dangerous operations gated?
3. Versioning approach — is it forward-compatible? What breaks a client?
4. Error model — are errors structured for programmatic handling? Are 4xx vs 5xx boundaries defensible?
5. Two specific changes you would push back on.
6. Two specific things this API does well that we should preserve.

Design a test strategy for the feature below.

Feature: {{feature}}
Existing test conventions: {{conventions}} (frameworks, tiers, coverage expectations)

Return:
1. Test tiers — which of unit, integration, contract, E2E, load, chaos should apply, and why.
2. Per-tier: three specific test scenarios (the ones a senior would specifically ask for).
3. Non-tests — what should be validated by observability / feature flag / runbook instead of by test.
4. What we will NOT test, and the trade-off.
5. Test data strategy — where does it come from, how is it kept fresh, how is PII handled.

Design a first-week onboarding tour of our codebase.

Engineer profile: {{engineer_profile}} (background, seniority, likely first work area)
Codebase top-level structure: {{codebase_structure}}
Team norms doc: {{team_norms}}

Return an ordered reading list of 8-12 items. For each: file/module path, why they should read it, what they should be able to do or explain after, and how long it should take. End with a 2-hour first-week task that exercises what they just read.

Given the list of feature flags below (with age, rollout percent, and last modification date), classify each as: deprecate-now / deprecate-soon / keep / needs-decision.

Flags:
"""
{{flag_dump}}
"""

For each deprecate-now flag, produce a specific removal plan:
1. Order of code sites to clean (from your best inference of the flag dump).
2. Consumer notification if any external observer depends on the flag behaviour.
3. Rollback strategy (in case removal reveals a hidden dependency).

Flag any needs-decision entry with the specific ambiguity to resolve.

Write a SQL query answering the business question below against the given schema.

Question: {{question}}
Schema:
"""
{{schema_dump}}
"""
Dialect: {{dialect}} (Postgres / BigQuery / Snowflake / etc.)

Return:
1. The SQL — commented on non-obvious joins or filters.
2. Assumptions you made (e.g., "included cancelled orders" or "used order_date not ship_date"). List each explicitly.
3. Data quality risks the query could hit (nulls, duplicates, timezone, incomplete recent partition).
4. What the caller should do if the result looks wrong.

If the schema does not clearly support the question, say so instead of guessing at joins.

Audit the data quality of the table below.

DDL:
"""
{{ddl}}
"""

Random row sample:
"""
{{sample_rows}}
"""

Return:
- Column-by-column: expected type / nullability / cardinality / plausible range vs observed. Flag divergences.
- Cross-column consistency: any obvious constraints violated in the sample?
- Freshness inference: what does the sample tell you about update cadence?
- Top 5 remediation actions in priority order.

Do not invent statistics beyond the sample; qualify claims as "based on 100 sampled rows" or similar.

Reverse-engineer a rigorous metric definition from the dashboard tile below.

Tile description: {{tile_description}}
Underlying dataset(s): {{datasets}}
Filters visible on the tile: {{filters}}

Return a metric spec:
- Name
- One-sentence business meaning
- Formula (in words, then in SQL-like pseudocode)
- Grain (per user / per session / per calendar day / etc.)
- Filters applied (denylist and allowlist)
- Refresh cadence
- Known edge cases (timezone, deduplication, late-arriving data)
- Consumers who depend on this metric today
- Deprecation risk (is this the source of truth, or a decayed copy)

Design a cohort analysis to answer: {{question}}.

Available data: {{data_available}}
Constraints: {{constraints}} (e.g., no PII, weekly cadence, product-analytics tool = Amplitude / GA / custom)

Return:
1. Cohort definition — how a user enters the cohort.
2. Cohort dimensions — which axes to slice (acquisition channel, plan, geography, etc.).
3. Behavior metric — the outcome you're measuring.
4. Time window and comparison baseline.
5. Sample-size sanity check — will this reach significance?
6. Pitfalls specific to this analysis and how to mitigate.

Explain the lineage of the query below.

Query:
"""
{{query}}
"""

Known data-catalog metadata:
"""
{{catalog}}
"""

Return a lineage summary:
- Direct sources (tables + views referenced).
- One-hop upstream sources feeding those.
- Any views that hide complex joins — surface them.
- Ownership per source (from catalog).
- Freshness per source.
- Any missing catalog info that would leave the lineage story incomplete.

Do not invent lineage that is not in the query or catalog.

Review the experiment design below.

Design:
"""
{{design}}
"""

Answer:
1. Is the hypothesis testable? If not, why?
2. Is the primary metric the right one for the hypothesis? Are there guardrail metrics missing?
3. Sample-size / duration sanity check — will the design reach the minimum detectable effect the team wants?
4. Randomization unit — appropriate for the intervention? Any interference / SUTVA risk?
5. Segmentation traps — could the effect wash out at the aggregate level while being real in a subgroup?
6. Two questions you would ask before green-lighting.

A downstream metric drifted starting {{drift_date}}. Metric: {{metric}}. Observed change: {{observed_change}}.

Pipeline stages (in order, upstream to downstream):
"""
{{stages}}
"""

Recent changes deployed near the drift date:
"""
{{recent_changes}}
"""

Return:
1. Ranked list of stages most likely responsible, with reasoning.
2. For the top 3 candidates: a specific check the on-call could run to confirm or rule out.
3. External factors worth checking (seasonality, upstream vendor, calendar change).
4. What log or metric to add so this class of drift is caught earlier next time.

Turn the chart description into a 4-sentence narrative appropriate for an exec brief.

Chart: {{chart_description}}
Business context: {{context}}
Audience: {{audience_role}}

Rules:
- Lead with the "so what", not the chart title.
- One sentence for the primary observation, one for the cause hypothesis, one for the implication, one for the decision this should prompt.
- If the chart genuinely does not support a cause hypothesis, say so — do not invent one.
- Do not restate axes; assume the reader will look at the chart.

Summarize the contract clause below in plain business language.

Clause:
"""
{{clause}}
"""

Rules:
- Do not change legal meaning; if a term of art is essential, keep it and note "term of art".
- Call out obligations we accept, rights we get, and the parties responsible.
- List the top 3 practical scenarios where this clause bites.
- Flag anything unusual for this contract type.

Do not draft; only explain. Always end with: "This is a summary. Verify with counsel before relying on it."

Review the AI vendor data-processing addendum (DPA) below against common enterprise expectations.

DPA:
"""
{{dpa_text}}
"""

Check for:
1. Prohibition on using customer data (prompts, completions, embeddings) for model training or fine-tuning.
2. Logical tenant isolation guarantee.
3. Sub-processor list transparency and change-notification period.
4. Cross-border transfer basis (SCCs / TIA where relevant).
5. Deletion terms — how long after contract end, evidence of deletion.
6. Breach notification window.
7. Audit rights — self-audit acceptable? Third-party audits (SOC 2 / ISO 27001)?
8. Indemnification for third-party IP claims tied to model outputs.

For each: present, missing, or unclear. List the top 3 clauses to push back on. This is not legal advice.

Provisionally classify the AI use case below under the EU AI Act risk tiers.

Use case description: {{description}}
Intended users: {{users}}
Deployment context: {{deployment}} (public sector / private, EU / non-EU users, safety-critical / not)
Outputs and downstream consequences: {{outputs}}

Return:
1. Provisional classification: unacceptable / high-risk / limited-risk / minimal-risk.
2. The specific EU AI Act article(s) or annex that supports the classification (or Annex III category).
3. Two counter-arguments — how this could reasonably classify differently.
4. What additional information would resolve the ambiguity.
5. The obligations that follow from the provisional classification.

This is not legal advice; a Notified Body / qualified counsel decides in disputes.

Trace how a data-subject deletion request would flow through the systems below.

Systems / data stores:
"""
{{systems}}
"""

Return:
1. Per-system: does deletion propagate, is it eventual, are there known holdouts (backups, logs, vector-store embeddings, third-party integrations)?
2. Statutory-window compliance risk — will we meet 30-day / 45-day / other applicable window?
3. Documentation gap — what evidence would we struggle to produce if audited?
4. Two highest-priority remediation actions.

Not legal advice; validate with DPO / counsel.

Triage the suspected prompt-injection incident below.

Alert / evidence:
"""
{{evidence}}
"""

System context: {{system_context}} (what the agent has access to, what it can call)

Return:
1. Was the injection successful (yes / no / unclear) and what specifically did the model do differently?
2. Blast radius — what data or actions were exposed?
3. Immediate containment steps.
4. Preservation checklist — what to snapshot before rotating credentials / restarting services.
5. Notification triggers — regulatory / customer / internal thresholds this incident may cross.
6. Postmortem items to add to the eval harness so this class is caught.

Review the user consent flow below for legitimacy and practicality.

Flow:
"""
{{flow_description}}
"""

Return:
- Is consent freely given, informed, specific, unambiguous? (per GDPR standards)
- Is opt-out at least as easy as opt-in?
- Are non-essential defaults set to off?
- Is data-purpose-per-consent granular enough to avoid "consent bundling"?
- Two concrete UX changes to strengthen the flow.
- One question a data protection authority would probably ask.

Not legal advice.

An existing AI system was previously classified as {{current_tier}} on {{original_date}} under the EU AI Act.

Current classification reasoning:
"""
{{original_reasoning}}
"""

Change now proposed / occurred:
"""
{{change}}
"""

Return:
1. Does the change plausibly move the classification to a different tier? Explain.
2. Which new obligations would apply if it does?
3. What documentation must be updated regardless of whether the tier changes.
4. Recommended action: re-review now / re-review at next release / no change.

Draft a response to the data-subject request below.

Request:
"""
{{request_text}}
"""

What we found on the subject:
"""
{{disclosure_summary}}
"""

Constraints: {{constraints}} (jurisdiction, statutory deadline, redaction rules)

Draft:
1. Cover letter acknowledging the request, describing scope of search, listing categories disclosed.
2. Redaction rationale for any withheld material.
3. Instructions for the subject on how to exercise further rights (correction, deletion, complaint).

Do not include actual PII in the draft — use placeholders like [subject_name]. Not legal advice.

Rewrite the job description for {{role}} to target the profile below and pass an inclusion audit.

Current JD:
"""
{{jd}}
"""

Target candidate profile: {{profile}}
Company principles / must-preserve messages: {{principles}}

Rewrite. Then audit the result:
- Gendered language flagged and removed.
- Non-essential requirements demoted or removed (e.g., a degree where equivalent experience should suffice).
- Vague language ("rockstar", "ninja") removed.
- Growth signal — what the candidate learns in year 1.
Return the rewrite followed by the audit checklist showing what changed.

Design a structured interview rubric for {{role}}.

Role responsibilities: {{responsibilities}}
Success criteria at 6 months: {{success_criteria}}
Existing loop stages: {{stages}}

For each stage: define 3-5 competencies, define what "strong" / "on-target" / "concern" looks like as observable behaviour (not adjectives). Add a set of debiasing rules ("do not weigh school prestige", "do not penalize career gaps"). End with a scorecard template interviewers can fill in-line.

Summarize the employee open-response answers below. Preserve dissent — do not smooth into consensus.

Responses (one per line or delimited):
"""
{{responses}}
"""

Question asked: {{question}}

Return:
1. Top 5 themes with representative verbatim quotes (paraphrase never — quote or omit).
2. Minority views worth surfacing (even if only 2-3 people voiced them).
3. Sentiment split — positive / neutral / negative / mixed with rough counts.
4. Two "signal not to lose" — quotes that would be tempting to ignore but shouldn't be.
5. What this data does NOT tell us.

Never invent a quote or assign a quote to a role that isn't attributed in the source.

Synthesize the peer feedback below into a performance review for {{employee_name}} (role: {{role}}).

Peer inputs:
"""
{{peer_inputs}}
"""

Rules:
- Do NOT anonymize contradictory feedback — flag it as "peer X sees Y, peer Z sees the opposite".
- Growth areas: 3, ranked by impact if addressed.
- Strengths: 3, backed by specific examples from the peer inputs.
- Actionable next-quarter goals: 3, each measurable.
- Two questions the manager should ask the employee that the feedback surfaces.

Do not invent examples. If a claim in the review isn't backed by an input, mark [needs manager corroboration].

Explain the compensation band for {{role}} at {{level}}.

Band data: {{band_data}} (base range, target variable, equity range if any)
Positioning principle: {{principle}} (e.g., "we target 60th percentile of the target market")
Market reference: {{market_reference}} (source and cut date)

Explain in a way the recipient can trust:
- What the band covers and why it has a range (experience, geography, performance).
- Where along the band the current offer sits and why.
- How movement within and above the band works over time.
- What is NOT in this compensation number (benefits, learning budget, etc.) — briefly.

Do not reference specific colleagues' pay. If the recipient asks about a peer, explain the policy of not disclosing.

Analyze the GenAI skills gap for {{team_or_function}}.

Current team profile: {{team_profile}}
Planned GenAI initiatives: {{initiatives}}
Target competency baseline: {{competency_baseline}}

Return:
1. Skills the team already has that transfer well.
2. Skills missing at production quality (with rough count of people needed).
3. Skills that can be developed vs those that require hiring.
4. Recommended 6-month curriculum (order + rough hours per module).
5. Which two skills would give the highest ROI if invested in first.

Draft an internal communication for the change below.

Change: {{change}}
Rationale: {{rationale}}
Impact on affected people: {{impact}}
What is NOT changing: {{unchanged}}
Timeline: {{timeline}}
Available support: {{support}}

Rules:
- Lead with the change and the reason, not corporate throat-clearing.
- Directly address the "why me" implicit question of affected people.
- Do not oversell — acknowledge trade-offs and losses.
- End with what recipients are expected to do and by when.

Length: 250-400 words. Include: subject line, body, closing.

Design a calibration exercise for the interview rubric below.

Rubric: {{rubric}}
Recent divergent scoring examples: {{examples}}

Return:
1. Diagnosis of why interviewers diverged in each example.
2. Two calibration scenarios (candidate profiles) that surface the same disagreement.
3. Expected "correct" scoring with reasoning grounded in the rubric.
4. What language should be added to the rubric to prevent the divergence.
5. Time-boxed structure for a 60-minute calibration meeting.

Draft a one-page board memo recommending a decision on {{topic}}.

Context: {{context}}
Options considered: {{options}}
Data / evidence available: {{evidence}}
Constraints: {{constraints}}

Rules:
- Lead with the recommendation, not the background.
- Two-sentence rationale.
- Three risks and each risk's mitigation.
- What we'll do differently if the recommendation is wrong (rollback trigger).
- What is being decided vs what is not (avoid scope creep).
- Max 400 words. Prose only; no fluff.

Compress the strategy below into a plan-on-a-page narrative.

Full strategy:
"""
{{strategy}}
"""

Deliver five sections, one paragraph each (max 80 words per paragraph):
1. Where we're trying to go (destination).
2. Why now (the wave we're surfing).
3. How we win (the specific game we're playing, not what everyone plays).
4. The three moves this year that matter.
5. What we're deliberately not doing.

Prose should be direct enough that a VP could recite the essence from memory. Cut all buzzwords.

Run a pre-mortem for the strategic bet below.

Bet: {{bet}}
Investment: {{investment}}
Success criteria: {{success_criteria}}
Timeline: {{timeline}}

Assume it is 24 months from now and the bet failed. Produce:
1. The three most likely "why it failed" narratives (technology, market, organization, execution).
2. Leading indicators that would have shown each failure mode earlier.
3. Kill criteria — what specific evidence would justify pulling the bet before full spend?
4. Two second-order effects (positive or negative) of the failure that leadership should think about now.

Draft a {{cadence}} update for {{audience}}.

Metrics summary: {{metrics}}
Wins: {{wins}}
Losses / concerns: {{losses}}
Asks (what the audience can help with): {{asks}}
Next-period focus: {{next_focus}}

Rules:
- Losses section is not optional; investors trust founders who reliably surface issues.
- Metrics summary uses direction + magnitude + why (e.g., "MRR $2.1M, +8% MoM, driven by expansion in top-20 accounts") — never a bare number.
- Asks section: specific and named — introductions to whom, decisions on what.
- Length: 400-700 words.

A competitor just did {{competitor_move}}.

Our position: {{our_position}}
Their position: {{their_position}}
Their likely rationale: {{their_rationale}}

Answer:
1. What is the competitor actually optimizing for with this move?
2. Are we the intended target or collateral?
3. Do-nothing response — what changes for us if we ignore the move?
4. Match / mirror response — pros and cons.
5. Differentiate / flank response — pros and cons.
6. Recommended posture with reasoning, and the observable that would flip your recommendation.

Classify each of the initiatives below as kill / scale / defer with reasoning.

Initiatives:
"""
{{initiatives}}
"""

Portfolio criteria: {{criteria}} (strategic fit, current traction, resource cost, opportunity cost)

Rules:
- Prefer explicit kills over "let's keep watching". "Defer" is only valid if there is a specific trigger for reconsidering.
- Every scale recommendation lists what more resources unlock, not just "increase investment".
- Note dependencies between initiatives.
- End with the two decisions leadership should NOT delay.

Review the OKR set below.

OKRs:
"""
{{okrs}}
"""

For each Objective:
1. Is it a real objective (a change in the world) vs a task list?
2. Do the KRs actually measure achievement of the O, or something adjacent?
3. Are the KRs outcome-based (moving the needle) vs output-based (shipping the thing)?
4. What KR would you add to catch a "we hit the numbers but did the wrong thing" outcome?

Cross-set:
5. What is NOT covered by any O that should be?
6. What Os overlap (creating scoring ambiguity)?

Prepare talking points for a difficult announcement.

Announcement: {{announcement}}
Audience: {{audience}}
Deliverer: {{deliverer_role}}
Known audience reactions to anticipate: {{anticipated_reactions}}

Produce:
1. Opening 3 sentences — direct, not buried.
2. Reason narrative — the real reason, not corporate framing.
3. Impact narrative — what changes for the audience specifically.
4. What is NOT changing — anchoring points.
5. What comes next — timeline and support.
6. Three anticipated hard questions with drafted answers (do not sugarcoat).
7. What the deliverer should NOT say (traps to avoid).

Triage the customer ticket below and draft a first response.

Ticket:
"""
{{ticket}}
"""

Product context: {{product_context}}
Response tone: {{tone}}

Return:
1. Category (bug / how-to / billing / account / feature-request / abuse / other).
2. Urgency (P1 / P2 / P3 / P4) with reasoning.
3. Sentiment (positive / neutral / frustrated / angry / at-risk-of-churn).
4. Drafted first response (max 5 sentences). Acknowledge the specific issue, set expectation, ask for the one most useful clarifying question if any.
5. Skills / team the ticket should route to if this can't be resolved by first-line support.

Do not promise timelines you can't verify. Do not invent product features.

Produce an escalation memo from the support thread below.

Thread:
"""
{{thread}}
"""

Escalating to: {{destination}} (engineering / product / leadership / legal)

Memo sections:
- What the customer is trying to do.
- What actually happens.
- What has been tried (support side) and result.
- Reproducibility + scope (this customer only / this segment / all customers).
- Customer impact (revenue / churn risk / brand).
- Specific ask of the escalation destination.
- Two things I did NOT check that the destination might want to.

Explain the root cause of the issue below to a customer.

Internal RCA: {{rca_technical}}
Customer profile: {{customer_profile}} (technical / non-technical)
What we're doing about it: {{remediation}}
When we'll do it: {{eta}}

Rules:
- Translate jargon; if a technical term is essential, define it inline.
- Acknowledge the impact on them specifically, not just "customers".
- Say what we changed / are changing so this class of issue is prevented.
- Do not over-promise timelines; if the ETA is uncertain, say so.
- End with the concrete next step for the customer.

Length: 150-250 words.

Recommend a resolution for the situation below.

Situation summary: {{situation}}
Customer history: {{history}} (MRR, tenure, prior incidents, NPS if known)
Our policy: {{policy}}
Cost of proposed remediations: {{cost_matrix}}

Return:
- Proposed resolution (specific amount / duration / credit / product change).
- Reasoning tied to policy and customer history.
- Precedent risk — will this create expectations from other customers?
- Alternative if the customer rejects the initial offer.
- Sign-off level required (front-line CSM, manager, VP).

Turn the resolved support incident into a KB article.

Incident summary: {{incident}}
Resolution steps used: {{resolution}}
Root cause (if applicable): {{root_cause}}

Article structure:
- Title (question a user would search)
- Short answer (2 sentences)
- Cause (only if actionable for the user)
- Step-by-step resolution
- When this doesn't apply (edge cases)
- Related articles / commands / settings

Do not include internal-only information (people names, ticket IDs, dashboards). Keep it self-serve.

Analyze the account-management call transcript below.

Transcript:
"""
{{transcript}}
"""

Return JSON:
- overall_sentiment: "positive"|"neutral"|"mixed"|"negative"
- churn_risk_score: 0-100 with reasoning field
- signals: [{ signal, direction: "positive"|"negative", verbatim_quote }]
- next_steps: [{ owner, action, due_estimate }]
- escalation_recommended: boolean
- escalation_reason: string_or_null

Every verbatim quote must be traceable to the transcript. No inference beyond what the transcript supports.

Draft a public response to the negative review below.

Review:
"""
{{review}}
"""

Product context: {{product_context}}
Known facts about this customer: {{known_facts}}
What we're willing to do publicly: {{public_offer}}

Rules:
- Acknowledge their specific complaint, not a generic apology.
- Do not litigate the facts in public even if we disagree.
- Move to private channel for resolution (contact method + who will reach out).
- Sign with a real role (not "The Team").
- Keep under 120 words.

Design a 30-day onboarding plan for {{customer_name}} ({{segment}}).

Their stated goal: {{goal}}
Their tech stack: {{stack}}
Their team size and skill mix: {{team_profile}}
Our standard onboarding milestones: {{standard_milestones}}

Personalize the plan:
- Week 1: what they'll set up + who from our team is involved.
- Week 2: first workflow live end-to-end.
- Week 3: second use-case + skill transfer.
- Week 4: success review with metrics.

For each week: two things the customer must do, one thing we'll do, one risk to watch. Include an off-ramp: what triggers a re-scope conversation if progress stalls.