Define the decision or output
State what successful work looks like and who will use it.
Business prompt resource
Eighteen practical scenarios built around one durable standard: define the work first, then adapt the prompt to the approved platform, model type, sources, risk, and review requirement.
Last reviewed: August 2026. Platform behavior and model availability change; the operating controls should remain stable.
How to use the library
The core prompt captures the business objective, approved information, constraints, output, and review. The ChatGPT and Claude versions show two clear formatting patterns—not permanent rules or claims that one platform is universally better.
State what successful work looks like and who will use it.
Use approved sources, mark unknowns, and remove restricted data.
Specify format, evidence, assumptions, limitations, and checks.
Assign final judgment, approval, escalation, and revision.
Model-type guide
Do not select a model merely because it is newest. Use the lightest approved capability that can perform the work reliably under the required controls.
Complete scenario library
Open a scenario, replace the placeholders, remove information that is not approved for the tool, and retain the human-review step.
Sales & customer work
Turn call notes into a useful follow-up without inventing commitments or overpromising.
Call notes, offer details, agreed next step, timing, known objections, and approved claims.
You are helping prepare a sales follow-up after a discovery call.
Business objective:
Move the opportunity to a clear next step without pressure, invented details, or vague promises.
Use only the information provided below.
Inputs:
- Prospect and company: [INSERT]
- Call notes: [INSERT]
- Confirmed needs: [INSERT]
- Open questions: [INSERT]
- Approved offer details: [INSERT]
- Agreed next step and date: [INSERT]
Before drafting:
1. Separate confirmed facts from assumptions.
2. Identify any missing information that would change the message.
3. Flag promises or claims that require approval.
Then produce:
- a concise subject line
- a 150–220 word follow-up email
- a three-item recap of agreed points
- one explicit next action with owner and date
- a short CRM note
Do not invent pricing, timing, capabilities, or customer commitments.Act as a B2B sales operations advisor. Review the call information below and prepare a follow-up that is specific, credible, and easy to act on.
First, list:
1. Confirmed facts
2. Open questions
3. Any claim that needs internal approval
Then write:
- Subject line
- 150–220 word email
- Three-point recap
- Next action with owner and date
- CRM note under 70 words
Use only the supplied information. Do not invent pricing, delivery timing, features, or commitments.
[PASTE CALL NOTES AND APPROVED OFFER DETAILS]<role>B2B sales operations advisor</role>
<objective>Prepare a credible post-call follow-up that moves the opportunity to one clear next step.</objective>
<source_material>
[PASTE CALL NOTES, APPROVED OFFER DETAILS, OPEN QUESTIONS, AND AGREED NEXT STEP]
</source_material>
<analysis_rules>
- Separate confirmed facts from assumptions.
- Identify missing information that could change the message.
- Flag claims or promises requiring approval.
- Do not infer pricing, timing, capabilities, or commitments.
</analysis_rules>
<deliverables>
1. Subject line
2. Email of 150–220 words
3. Three-point recap
4. Next action with owner and date
5. CRM note under 70 words
</deliverables>Confirm names, dates, scope, pricing, promises, attachments, and the next-step owner before sending.
Fast general model for routine follow-up; reasoning-capable model when notes conflict or the opportunity has complex tradeoffs.
Acknowledge the issue, distinguish facts from allegations, and propose an appropriate next step without admitting unsupported liability.
Customer message, order/service record, policy, prior communication, known facts, and authorized remedies.
Help prepare a response to a customer complaint.
Goal:
Acknowledge the concern, reduce friction, and move the matter toward resolution while staying within approved facts and remedies.
Materials:
- Customer complaint: [INSERT]
- Order or service record: [INSERT]
- Relevant policy: [INSERT]
- Prior communication: [INSERT]
- Confirmed facts: [INSERT]
- Authorized remedies or escalation options: [INSERT]
Process:
1. Summarize the complaint neutrally.
2. Separate confirmed facts, disputed points, and missing information.
3. Identify language that could sound dismissive, defensive, or like an unsupported admission.
4. Recommend the safest useful next step.
Draft:
- a calm response under 220 words
- a short internal escalation note
- a checklist of facts a manager should verify
Do not invent policy, refunds, legal conclusions, or fault.You are a customer-experience manager. Analyze the complaint and records below.
Return four sections:
1. Neutral issue summary
2. Confirmed facts / disputed points / missing information
3. Customer response under 220 words
4. Internal escalation note and verification checklist
Tone: calm, respectful, specific, and non-defensive.
Do not invent policy, compensation, legal conclusions, or fault. Use only authorized remedies.
[PASTE COMPLAINT, RECORDS, POLICY, AND AUTHORIZED REMEDIES]<role>Customer-experience manager</role>
<goal>Prepare a respectful response and a clear internal review path.</goal>
<customer_message>[PASTE]</customer_message>
<records>[PASTE ORDER, SERVICE, AND COMMUNICATION RECORDS]</records>
<policy>[PASTE RELEVANT APPROVED POLICY]</policy>
<authorized_remedies>[PASTE]</authorized_remedies>
<rules>
- Distinguish facts, allegations, and unknowns.
- Avoid dismissive or defensive phrasing.
- Do not admit fault or promise an unauthorized remedy.
- Escalate legal, safety, discrimination, or regulatory concerns.
</rules>
<output>
A. Neutral summary
B. Fact table
C. Customer response under 220 words
D. Internal escalation note
E. Manager verification checklist
</output>A manager should verify policy, transaction history, authorized remedy, legal/safety flags, and any admission before release.
General model for standard service recovery; reasoning-capable model for conflicting records or high-risk complaints.
Convert an inquiry into a consistent qualification record and next action without making assumptions about budget or fit.
Inquiry text, service criteria, disqualifiers, geography, capacity, and routing rules.
Evaluate the inbound lead using the approved qualification rules.
Inquiry:
[PASTE]
Qualification criteria:
[PASTE]
Disqualifiers or escalation conditions:
[PASTE]
Available routes:
[PASTE SALES, CONSULTATION, NURTURE, PARTNER, OR DECLINE PATHS]
Produce:
1. Extracted facts from the inquiry
2. Missing information
3. Provisional fit: strong / possible / unclear / not fit
4. Reason for that classification
5. Recommended route and owner
6. A reply that asks only the minimum necessary questions
7. CRM fields in a clean table
Do not infer budget, authority, urgency, or technical readiness unless the inquiry states it.Act as a lead-operations coordinator. Use the approved qualification criteria below to classify the inquiry.
Output:
- Facts stated by the lead
- Missing facts
- Provisional fit: strong / possible / unclear / not fit
- Reasoning tied to the criteria
- Route and owner
- Minimal follow-up questions
- CRM-ready table
Do not infer budget, authority, urgency, or readiness.
[PASTE INQUIRY, CRITERIA, DISQUALIFIERS, AND ROUTING RULES]<role>Lead-operations coordinator</role>
<inquiry>[PASTE]</inquiry>
<qualification_rules>[PASTE]</qualification_rules>
<disqualifiers>[PASTE]</disqualifiers>
<routing_options>[PASTE]</routing_options>
<instructions>
Classify only from stated evidence. Mark unknowns explicitly. Do not infer budget, authority, urgency, or readiness.
</instructions>
<output>
1. Extracted facts
2. Missing facts
3. Provisional fit
4. Evidence-based rationale
5. Route and owner
6. Minimal follow-up questions
7. CRM table
</output>Check that routing logic matches current capacity, geography, service scope, and sales policy.
Fast validated model for routine routing; reasoning-capable model when multiple services or conflicting signals are involved.
Brand, website & marketing
Evaluate whether a website makes the offer credible, understandable, and easy to act on.
Page copy, screenshots or URL export, target audience, primary action, proof, and constraints.
Review this website page as a trust and conversion system.
Business context:
- Audience: [INSERT]
- Offer: [INSERT]
- Primary action: [INSERT]
- Traffic source: [INSERT]
- Known objections: [INSERT]
- Regulatory or claim constraints: [INSERT]
Page material:
[PASTE COPY OR STRUCTURED PAGE EXPORT]
Assess:
1. Clarity in the first screen
2. Audience and problem recognition
3. Offer specificity
4. Proof and credibility
5. Risk reversal and objection handling
6. CTA visibility and sequence
7. Mobile readability
8. Missing information
Return:
- a severity-ranked issue list
- what should stay
- recommended revised hierarchy
- five highest-value copy changes
- claims that require verification
Do not invent analytics, customer behavior, or performance data.You are a senior conversion and trust reviewer. Evaluate the supplied page against the audience, offer, and primary action.
Use this format:
1. Executive finding
2. Critical / important / minor issues
3. What already works
4. Recommended page hierarchy
5. Five copy revisions
6. Claims and proof that must be verified
Do not invent traffic, conversion rates, or user behavior.
[PASTE BUSINESS CONTEXT AND PAGE CONTENT]<role>Senior website trust and conversion reviewer</role>
<context>
Audience: [INSERT]
Offer: [INSERT]
Primary action: [INSERT]
Traffic source: [INSERT]
Known objections: [INSERT]
Claim constraints: [INSERT]
</context>
<page_material>[PASTE COPY OR PAGE EXPORT]</page_material>
<evaluation_criteria>
First-screen clarity; audience recognition; offer specificity; proof; objections; CTA sequence; mobile readability; missing information.
</evaluation_criteria>
<output>
- Executive finding
- Severity-ranked issues
- Elements to retain
- Revised hierarchy
- Five copy changes
- Verification requirements
</output>
<constraint>Do not invent analytics, behavior, or performance data.</constraint>Validate claims, prices, testimonials, legal language, links, mobile layout, and whether recommendations fit actual analytics.
Long-context model when reviewing multiple pages; vision-capable model when screenshots and visual hierarchy are central.
Turn business facts and customer evidence into a differentiated, supportable positioning direction.
Offer, audience, alternatives, customer evidence, strengths, exclusions, and proof.
Develop a positioning direction from the evidence provided.
Inputs:
- Company and offer: [INSERT]
- Priority audience: [INSERT]
- Problem or desired outcome: [INSERT]
- Current alternatives: [INSERT]
- Customer language or research: [INSERT]
- Demonstrated strengths: [INSERT]
- Proof: [INSERT]
- What the company does not want to claim: [INSERT]
Work in stages:
1. Separate evidence from opinion.
2. Identify common category language that would make the company sound interchangeable.
3. Produce three differentiated positioning territories.
4. For each, state the promise, reason to believe, audience fit, risk, and proof required.
5. Recommend one direction and explain the tradeoff.
6. Draft a homepage headline, subhead, and three supporting pillars.
Do not create superiority claims that are not supported.Act as a positioning strategist. Use only the evidence supplied.
First distinguish:
- Proven facts
- Customer evidence
- Internal opinion
- Missing proof
Then create three positioning territories. For each include promise, audience, differentiation, proof, risk, and language to avoid. Recommend one direction and draft a headline, subhead, and three pillars.
Do not use unsupported “best,” “leading,” or category-superiority claims.
[PASTE EVIDENCE]<role>Positioning strategist</role>
<evidence>
[PASTE OFFER, AUDIENCE, ALTERNATIVES, CUSTOMER LANGUAGE, STRENGTHS, PROOF, AND EXCLUSIONS]
</evidence>
<method>
1. Classify statements as evidence, customer signal, opinion, or unknown.
2. Identify interchangeable category language.
3. Build three positioning territories.
4. Compare promise, audience fit, proof, risk, and tradeoff.
5. Recommend one direction.
</method>
<deliverables>
Homepage headline, subhead, three supporting pillars, language to avoid, and proof still needed.
</deliverables>
<constraint>No unsupported superiority claims.</constraint>Leadership should confirm audience priority, claims, differentiation, proof, and what the company is willing to exclude.
Reasoning-capable model for tradeoffs; long-context model when research interviews, reviews, and competitor material are extensive.
Build a campaign plan tied to one audience, one offer, one measurable action, and approved claims.
Audience, offer, objective, channel, budget, proof, timing, constraints, and measurement.
Create a campaign brief for the following business objective.
Audience: [INSERT]
Offer: [INSERT]
Primary action: [INSERT]
Channel(s): [INSERT]
Budget range: [INSERT]
Timing: [INSERT]
Approved proof and claims: [INSERT]
Known objections: [INSERT]
Brand and compliance constraints: [INSERT]
Available assets: [INSERT]
Produce:
1. Campaign thesis
2. Audience insight and objection
3. Message hierarchy
4. Three creative concepts
5. Channel-specific asset list
6. Landing-page requirements
7. Measurement plan with leading and lagging indicators
8. Pre-launch verification checklist
State assumptions. Do not predict results or invent benchmarks.You are a campaign strategist. Build a practical brief from the approved inputs.
Return:
- Campaign thesis
- Audience tension and objection
- Message hierarchy
- Three creative concepts
- Required assets by channel
- Landing-page requirements
- Measurement plan
- Verification checklist
State assumptions. Do not invent performance benchmarks or forecast results.
[PASTE CAMPAIGN INPUTS]<role>Campaign strategist</role>
<inputs>
Audience: [INSERT]
Offer: [INSERT]
Primary action: [INSERT]
Channels: [INSERT]
Budget and timing: [INSERT]
Approved proof: [INSERT]
Objections: [INSERT]
Constraints: [INSERT]
Assets: [INSERT]
</inputs>
<deliverables>
1. Campaign thesis
2. Audience insight
3. Message hierarchy
4. Three concepts
5. Channel asset map
6. Landing-page requirements
7. Measurement plan
8. Verification checklist
</deliverables>
<rules>State assumptions. Do not invent benchmarks, proof, or expected results.</rules>Confirm claims, offer availability, targeting, channel policy, budget, tracking, landing-page readiness, and approval ownership.
General model for the first brief; reasoning-capable model for multi-channel tradeoffs and budget allocation.
Leadership & operations
Convert a complex situation into a clear decision request with evidence, tradeoffs, and ownership.
Decision, context, evidence, options, constraints, risks, recommendation, and deadline.
Prepare an executive decision memo.
Decision required: [INSERT]
Decision owner: [INSERT]
Deadline: [INSERT]
Context: [INSERT]
Evidence: [INSERT]
Options considered: [INSERT]
Constraints: [INSERT]
Risks: [INSERT]
Current recommendation: [INSERT]
Unknowns: [INSERT]
First test the logic:
1. What is fact, assumption, estimate, or opinion?
2. Is the decision framed at the correct level?
3. Which tradeoffs are hidden?
4. What information is still material?
Then draft a one-page memo with:
- decision requested
- why now
- evidence
- options and tradeoffs
- recommendation
- risks and mitigations
- owner, next step, and date
Do not manufacture certainty or supporting evidence.Act as an executive chief-of-staff editor. Test the decision logic before drafting.
Output:
1. Facts / assumptions / estimates / opinions
2. Hidden tradeoffs and missing material information
3. One-page decision memo
4. Three questions the decision owner should answer
The memo must state the decision requested, why now, evidence, options, recommendation, risk, owner, and date. Do not manufacture certainty.
[PASTE DECISION MATERIAL]<role>Executive chief-of-staff editor</role>
<decision_material>[PASTE]</decision_material>
<logic_test>
Classify facts, assumptions, estimates, and opinions. Identify hidden tradeoffs, missing material information, and whether the decision is framed at the correct level.
</logic_test>
<memo_structure>
Decision requested; why now; evidence; options and tradeoffs; recommendation; risks and mitigations; owner; next step; date.
</memo_structure>
<constraint>Do not manufacture certainty, evidence, or consensus.</constraint>The executive owner must validate evidence, risk, recommendation, decision rights, and whether the memo omits affected stakeholders.
Reasoning-capable model for tradeoffs; general model for final editing after the decision logic is settled.
Create an accurate record of decisions, unresolved issues, actions, owners, and dates from meeting notes or transcript.
Transcript or notes, participant list, agenda, and known project terminology.
Turn the meeting material into an action record.
Participants and roles: [INSERT]
Agenda: [INSERT]
Transcript or notes: [INSERT]
Known project terms: [INSERT]
Rules:
- Distinguish decisions from suggestions.
- Do not assign an owner or date unless stated.
- Mark ambiguous commitments for confirmation.
- Preserve disagreement and unresolved issues.
Produce:
1. Executive summary under 120 words
2. Decisions made
3. Action table: action / owner / due date / dependency / status
4. Open questions
5. Risks or blockers
6. Items requiring confirmation
7. A follow-up email to participants
Quote or cite the source location when the material provides timestamps or sections.Act as a project operations coordinator. Convert the meeting material into a precise action record.
Do not turn suggestions into decisions. Do not invent owners or dates. Flag ambiguous commitments.
Return: summary, decisions, action table, open questions, blockers, confirmation items, and a follow-up email.
Where timestamps exist, include them beside important decisions and commitments.
[PASTE PARTICIPANTS, AGENDA, AND TRANSCRIPT]<role>Project operations coordinator</role>
<participants>[PASTE]</participants>
<agenda>[PASTE]</agenda>
<meeting_material>[PASTE TRANSCRIPT OR NOTES]</meeting_material>
<rules>
- Separate decisions, suggestions, questions, and actions.
- Do not infer owners or dates.
- Preserve disagreement and unresolved items.
- Use timestamps or section references where available.
</rules>
<output>
Summary; decisions; action table; open questions; blockers; confirmation items; participant follow-up email.
</output>Participants should confirm decisions, action owners, due dates, sensitive statements, and any disagreement represented in the record.
Long-context model for transcripts; fast general model for short meeting notes.
Turn observed work into an SOP that reflects actual steps, decisions, exceptions, controls, and ownership.
Process notes, screenshots, forms, systems, roles, exceptions, approvals, and quality standards.
Draft an SOP from the observed process material.
Process name: [INSERT]
Purpose and successful outcome: [INSERT]
Owner: [INSERT]
Roles involved: [INSERT]
Trigger: [INSERT]
Source material: [INSERT]
Systems and forms: [INSERT]
Known exceptions: [INSERT]
Approval or control points: [INSERT]
Quality standard: [INSERT]
Before drafting:
1. Identify missing steps, decision points, and contradictions.
2. Separate current practice from recommended improvement.
3. List questions that must be answered by the process owner.
Then create:
- scope and exclusions
- prerequisites
- numbered procedure
- decision table
- exception and escalation paths
- quality checks
- records retained
- ownership and revision history
- training checklist
Do not silently repair gaps. Mark them as unresolved.You are an operations documentation specialist. Build an SOP from the supplied process evidence.
First identify gaps, contradictions, missing decisions, and questions for the owner. Separate current practice from recommended improvement.
Then draft: scope, prerequisites, numbered procedure, decision table, exceptions, escalation, quality checks, records, ownership, revision history, and training checklist.
Do not silently fill missing steps.
[PASTE PROCESS MATERIAL]<role>Operations documentation specialist</role>
<process_context>
Name: [INSERT]
Purpose: [INSERT]
Owner and roles: [INSERT]
Trigger: [INSERT]
Systems and forms: [INSERT]
Known exceptions: [INSERT]
Controls and quality standard: [INSERT]
</process_context>
<source_material>[PASTE]</source_material>
<method>
Identify gaps, contradictions, missing decisions, and owner questions. Keep current practice separate from proposed improvement.
</method>
<deliverable>
Scope; prerequisites; numbered procedure; decision table; exceptions; escalation; quality checks; retained records; ownership; revision history; training checklist.
</deliverable>
<constraint>Do not silently fill gaps.</constraint>The process owner and actual users must walk through the SOP, test normal and edge cases, and approve controls and exceptions.
Long-context model for large source packets; reasoning-capable model for decision tables and exceptions.
People, hiring & learning
Create role-specific onboarding that connects business context, responsibilities, systems, standards, practice, and manager checkpoints.
Role description, outcomes, systems, policies, stakeholders, training assets, risks, and 30/60/90-day expectations.
Create an onboarding plan for this role.
Role: [INSERT]
Business context: [INSERT]
Expected outcomes: [INSERT]
Key responsibilities: [INSERT]
Systems and access: [INSERT]
Policies and standards: [INSERT]
Stakeholders: [INSERT]
Existing training assets: [INSERT]
Common mistakes or risks: [INSERT]
30/60/90-day expectations: [INSERT]
Produce:
1. Pre-start checklist
2. First-day agenda
3. Week-one plan
4. 30/60/90-day milestones
5. Role practice assignments
6. Manager checkpoints
7. Knowledge and performance verification
8. Ownership for each onboarding element
Distinguish required policy from suggested practice. Do not invent access, policy, or performance standards.Act as an L&D and operations lead. Build a role-specific onboarding plan from the approved information.
Return a pre-start checklist, first-day agenda, week-one plan, 30/60/90 milestones, practice assignments, manager checkpoints, verification methods, and ownership table.
Mark missing policy, access, or performance information instead of inventing it.
[PASTE ROLE AND ONBOARDING INPUTS]<role>L&D and operations lead</role>
<role_information>[PASTE ROLE, OUTCOMES, RESPONSIBILITIES, SYSTEMS, POLICIES, STAKEHOLDERS, RISKS, AND MILESTONES]</role_information>
<instructions>
Connect business context, job responsibilities, systems, standards, practice, and manager review. Distinguish mandatory policy from suggested practice. Mark missing information.
</instructions>
<output>
Pre-start checklist; first-day agenda; week-one plan; 30/60/90 milestones; practice assignments; checkpoints; verification; ownership table.
</output>HR, the manager, IT/security, and a current role holder should validate access, policy, workload, milestones, and realistic sequencing.
General model for a single role; long-context model when combining handbooks, SOPs, job descriptions, and training materials.
Create evidence-based interview criteria and questions tied to actual job outcomes rather than vague personality preferences.
Role outcomes, responsibilities, must-haves, trainable skills, risks, team context, legal constraints, and interview stages.
Build an interview scorecard for the role below.
Role: [INSERT]
Business outcomes: [INSERT]
Core responsibilities: [INSERT]
Must-have capabilities: [INSERT]
Trainable capabilities: [INSERT]
Common failure modes: [INSERT]
Team and manager context: [INSERT]
Interview stages: [INSERT]
Legal or policy constraints: [INSERT]
Create:
1. Six to eight evaluation dimensions
2. Observable evidence for strong / acceptable / weak performance
3. Structured interview questions
4. Follow-up probes
5. A work-sample exercise
6. Red flags that require evidence, not intuition
7. Scoring guidance
8. Debrief questions that reduce bias
Do not infer protected characteristics or recommend unlawful questions.You are a structured-hiring advisor. Build an evidence-based scorecard tied to role outcomes.
Include 6–8 dimensions, behavioral evidence, structured questions, probes, work sample, scoring guidance, and debrief questions. Distinguish must-have from trainable capability.
Do not recommend questions about protected characteristics or treat style preferences as job evidence.
[PASTE ROLE INPUTS]<role>Structured-hiring advisor</role>
<role_inputs>[PASTE ROLE OUTCOMES, RESPONSIBILITIES, MUST-HAVES, TRAINABLE SKILLS, RISKS, TEAM CONTEXT, INTERVIEW STAGES, AND CONSTRAINTS]</role_inputs>
<deliverables>
- 6–8 evaluation dimensions
- Evidence anchors for strong / acceptable / weak
- Structured questions and probes
- Work-sample exercise
- Evidence-based red flags
- Scoring guidance
- Bias-reducing debrief questions
</deliverables>
<rules>Do not infer protected characteristics or suggest unlawful questions. Do not equate personal similarity with fit.</rules>HR or counsel should validate legality; the hiring manager should confirm role outcomes, scoring anchors, and work-sample relevance.
Reasoning-capable model for scorecard design; general model for formatting and interviewer guides.
Prepare a factual, respectful conversation that addresses behavior, impact, expectations, support, and follow-up.
Observed behavior, dates, impact, prior communication, policy, desired change, support, and escalation path.
Help prepare a difficult workplace conversation.
Situation: [INSERT]
Observed behavior with dates or examples: [INSERT]
Business or team impact: [INSERT]
Prior communication: [INSERT]
Relevant policy or standard: [INSERT]
Expected change: [INSERT]
Support available: [INSERT]
Follow-up and escalation path: [INSERT]
First:
1. Separate observable facts from interpretation.
2. Identify loaded, accusatory, or vague language.
3. Flag legal, HR, safety, discrimination, retaliation, or medical issues that require escalation.
Then produce:
- a conversation opening
- a fact / impact / expectation structure
- questions that allow the employee to respond
- support and next steps
- documentation notes
- a follow-up email
Do not diagnose motives, personality, health, or intent.Act as a manager communication coach. Prepare a factual and respectful conversation using only observable evidence.
First separate facts from interpretation and flag issues requiring HR or legal review. Then draft an opening, fact-impact-expectation sequence, response questions, support, next steps, documentation note, and follow-up email.
Do not diagnose motives, personality, health, or intent.
[PASTE APPROVED SITUATION DETAILS]<role>Manager communication coach</role>
<situation_material>[PASTE OBSERVED BEHAVIOR, DATES, IMPACT, PRIOR COMMUNICATION, POLICY, EXPECTED CHANGE, SUPPORT, AND ESCALATION PATH]</situation_material>
<safety_check>
Separate facts from interpretation. Flag HR, legal, safety, discrimination, retaliation, or medical issues requiring specialist review.
</safety_check>
<output>
Conversation opening; fact-impact-expectation structure; response questions; support; next steps; documentation note; follow-up email.
</output>
<constraint>Do not diagnose motive, personality, health, or intent.</constraint>A manager and HR should verify facts, policy, consistency, documentation, support, and whether specialist review is required.
General model for communication structure; do not rely on any model as the final authority for HR or legal decisions.
Research, analysis & decisions
Compare sources transparently, distinguish evidence from interpretation, and identify what remains unresolved.
Research question, source set, date range, relevance criteria, and required citation format.
Analyze the supplied sources for the following research question.
Question: [INSERT]
Decision or use: [INSERT]
Date range: [INSERT]
Inclusion criteria: [INSERT]
Source set: [PASTE OR ATTACH]
Citation format: [INSERT]
Method:
1. List each source, publisher, date, and source type.
2. Extract only claims relevant to the question.
3. Distinguish direct evidence, author interpretation, and your inference.
4. Identify agreements, contradictions, and missing evidence.
5. Assess source limitations without dismissing inconvenient evidence.
Return:
- evidence table with citations
- areas of agreement
- material disagreement
- unresolved questions
- a cautious synthesis
- what should be verified before a decision
Do not invent citations or claim access to sources not provided or retrieved.Act as a research analyst. Compare the supplied sources against one explicit question.
Create an evidence table with source, date, claim, evidence type, relevance, limitation, and citation. Separate source claims from your inference. Show agreement, contradiction, unknowns, and decision implications.
Do not invent citations or imply you reviewed material not supplied or retrieved.
[PASTE QUESTION, CRITERIA, AND SOURCES]<role>Research analyst</role>
<research_question>[INSERT]</research_question>
<decision_context>[INSERT]</decision_context>
<source_material>[PASTE OR ATTACH SOURCES]</source_material>
<method>
Catalog source type and date; extract relevant claims; distinguish evidence, author interpretation, and model inference; identify agreement, contradiction, limitations, and missing evidence.
</method>
<output>
Evidence table with citations; agreements; disagreements; unresolved questions; cautious synthesis; verification required before decision.
</output>
<constraint>Do not invent citations or imply access to unprovided sources.</constraint>Verify every citation, quotation, date, numerical claim, source relevance, and whether newer evidence changes the conclusion.
Long-context or research/tool-enabled model for source-heavy work; reasoning-capable model for synthesis and contradiction analysis.
Interpret a dataset or report without confusing correlation, estimates, or incomplete records with causation or certainty.
Dataset, definitions, time period, business question, known data-quality issues, and decision context.
Analyze the business data for the stated decision.
Business question: [INSERT]
Decision context: [INSERT]
Dataset or report: [ATTACH OR PASTE]
Metric definitions: [INSERT]
Time period: [INSERT]
Known data-quality issues: [INSERT]
Relevant business events: [INSERT]
Process:
1. Validate columns, units, missing values, duplicates, and time coverage.
2. Identify descriptive patterns and material outliers.
3. Separate observed relationship from causal explanation.
4. Test whether segmentation changes the conclusion.
5. State limitations and alternative explanations.
Return:
- data-quality findings
- key patterns with calculations shown
- segments or outliers worth investigating
- what cannot be concluded
- decision implications
- next analysis or data needed
Do not fabricate calculations or causal claims.You are a business analyst. Audit the data before interpreting it.
Return:
1. Data-quality findings
2. Calculations and key patterns
3. Segment and outlier analysis
4. Alternative explanations
5. What cannot be concluded
6. Decision implications and next data needed
Show formulas or calculation steps. Do not convert correlation into causation.
[ATTACH DATA AND PASTE DEFINITIONS / BUSINESS QUESTION]<role>Business analyst</role>
<business_question>[INSERT]</business_question>
<decision_context>[INSERT]</decision_context>
<metric_definitions>[INSERT]</metric_definitions>
<known_quality_issues>[INSERT]</known_quality_issues>
<data>[ATTACH OR PASTE]</data>
<analysis_sequence>
Audit units, missing values, duplicates, time coverage, and definitions. Calculate patterns. Test segments and outliers. Separate observation from causal explanation. State limitations.
</analysis_sequence>
<deliverables>
Data-quality findings; calculations; key patterns; segments; outliers; alternative explanations; non-conclusions; decision implications; next data needed.
</deliverables>A knowledgeable analyst should reproduce calculations, verify definitions, inspect source data, and approve any causal or financial interpretation.
Tool-enabled data-analysis model for calculations; reasoning-capable model for interpretation. Use deterministic code where accuracy matters.
Compare vendors against weighted requirements, evidence, implementation risk, total cost, and unresolved questions.
Requirements, vendor proposals, pricing, references, security/compliance needs, implementation constraints, and weights.
Evaluate the vendors against the approved requirements.
Decision objective: [INSERT]
Requirements and weights: [INSERT]
Vendor proposals: [PASTE OR ATTACH]
Pricing and contract terms: [INSERT]
Security, compliance, and data requirements: [INSERT]
Implementation constraints: [INSERT]
Reference information: [INSERT]
Method:
1. Normalize claims so equivalent items are compared.
2. Mark each claim as documented, vendor-stated, inferred, or unknown.
3. Score only against approved criteria.
4. Separate purchase price from implementation, migration, training, support, and exit cost.
5. Identify lock-in, dependency, and adoption risks.
Return:
- comparison matrix
- weighted score with calculation
- total-cost view
- risk register
- unresolved questions for each vendor
- recommendation with conditions
Do not treat marketing claims as verified evidence.Act as a vendor-selection analyst. Normalize the proposals and compare only against the approved weighted criteria.
Label evidence as documented, vendor-stated, inferred, or unknown. Include a weighted matrix, cost view, implementation and lock-in risks, unanswered questions, and a conditional recommendation.
Do not treat marketing claims as verified facts.
[PASTE REQUIREMENTS, WEIGHTS, PROPOSALS, PRICING, AND CONSTRAINTS]<role>Vendor-selection analyst</role>
<decision_objective>[INSERT]</decision_objective>
<requirements_and_weights>[PASTE]</requirements_and_weights>
<vendor_material>[PASTE OR ATTACH]</vendor_material>
<cost_and_contract_terms>[PASTE]</cost_and_contract_terms>
<constraints>[PASTE SECURITY, COMPLIANCE, IMPLEMENTATION, AND ADOPTION CONSTRAINTS]</constraints>
<method>
Normalize claims; classify evidence; score only approved criteria; separate purchase, implementation, migration, training, support, and exit cost; identify lock-in and dependency.
</method>
<output>
Comparison matrix; weighted score; total-cost view; risk register; unresolved questions; conditional recommendation.
</output>Procurement, security, legal, finance, technical owners, and end users should verify claims, terms, costs, references, and implementation assumptions.
Long-context model for proposals; reasoning-capable model for weighted tradeoffs. Recalculate scores independently.
Planning & governance
Turn an approved outcome into phases, deliverables, owners, dependencies, acceptance criteria, and decision gates.
Outcome, scope, exclusions, deadline, resources, stakeholders, dependencies, risks, and acceptance criteria.
Build a project plan from the approved outcome and constraints.
Outcome: [INSERT]
Scope: [INSERT]
Out of scope: [INSERT]
Deadline or target window: [INSERT]
Available team and capacity: [INSERT]
Stakeholders and decision rights: [INSERT]
Known dependencies: [INSERT]
Risks: [INSERT]
Acceptance criteria: [INSERT]
First identify contradictions, missing decisions, unrealistic assumptions, and critical dependencies.
Then produce:
1. Phased work breakdown
2. Deliverables by phase
3. Owner and contributor matrix
4. Dependency map
5. Decision gates
6. Acceptance criteria
7. Risk register
8. Status-report format
9. First two weeks of actions
Do not invent resource availability or compress work to satisfy an unsupported deadline.You are a program manager. Test the project assumptions before planning.
Identify contradictions, missing decisions, critical dependencies, and capacity risks. Then produce phases, deliverables, RACI-style ownership, dependency map, decision gates, acceptance criteria, risk register, status format, and first-two-week plan.
Do not invent capacity or force the plan to fit an unsupported deadline.
[PASTE PROJECT INPUTS]<role>Program manager</role>
<project_inputs>
Outcome: [INSERT]
Scope and exclusions: [INSERT]
Timing: [INSERT]
Team and capacity: [INSERT]
Stakeholders and decision rights: [INSERT]
Dependencies: [INSERT]
Risks: [INSERT]
Acceptance criteria: [INSERT]
</project_inputs>
<precheck>Identify contradictions, missing decisions, unrealistic assumptions, capacity limits, and critical dependencies.</precheck>
<deliverables>Phases; deliverables; ownership matrix; dependency map; decision gates; acceptance criteria; risk register; status format; first two weeks.</deliverables>
<constraint>Do not invent resources or compress work to satisfy an unsupported deadline.</constraint>The sponsor and delivery team should validate scope, capacity, dependencies, decision rights, acceptance criteria, and dates.
Reasoning-capable model for dependencies and tradeoffs; project tool integration or deterministic scheduling for production plans.
Decide whether an AI-assisted use case is permitted, needs controls, requires specialist review, or should not proceed.
Use case, users, data, decisions affected, output use, failure impact, regulations, controls, and owner.
Review the proposed AI use case for operational and governance risk.
Use case: [INSERT]
Users: [INSERT]
Data involved: [INSERT]
Systems accessed: [INSERT]
Decision or output affected: [INSERT]
Who relies on the output: [INSERT]
Potential failure impact: [INSERT]
Applicable policy or regulation: [INSERT]
Existing controls: [INSERT]
Business owner: [INSERT]
Assess:
1. Data sensitivity and authorization
2. Accuracy and verification requirement
3. Bias, fairness, or protected-class implications
4. Human decision rights
5. Explainability and recordkeeping
6. Security and access
7. Vendor and model dependency
8. Failure, fallback, and escalation
Return:
- risk classification
- permitted / permitted with controls / specialist review / do not proceed
- required controls and owner
- test cases
- monitoring and incident response
- unresolved legal, compliance, or policy questions
Do not provide legal conclusions or approve the use case on behalf of the organization.Act as an operational AI governance reviewer. Evaluate the use case across data, accuracy, bias, decision rights, security, records, vendor dependency, failure, fallback, and escalation.
Return a risk classification, provisional disposition, required controls, owners, test cases, monitoring, incident response, and questions requiring legal/compliance review.
Do not give legal conclusions or final organizational approval.
[PASTE USE CASE AND GOVERNANCE INPUTS]<role>Operational AI governance reviewer</role>
<use_case>[PASTE]</use_case>
<data_and_systems>[PASTE]</data_and_systems>
<decision_context>[PASTE WHO USES THE OUTPUT AND WHAT IT AFFECTS]</decision_context>
<failure_impact>[PASTE]</failure_impact>
<policies_and_controls>[PASTE]</policies_and_controls>
<assessment_areas>Data authorization; accuracy; bias/fairness; human decision rights; explainability; records; security; vendor dependency; failure; fallback; escalation.</assessment_areas>
<output>Risk classification; provisional disposition; controls and owners; test cases; monitoring; incident response; specialist-review questions.</output>
<constraint>No legal conclusion or final approval.</constraint>The accountable owner, security, privacy, legal/compliance, and affected business function must make the final authorization decision.
Reasoning-capable model for structured risk review; specialist human review is mandatory for regulated or high-impact uses.
Compare current policy text with observed practice, requirements, and evidence to identify gaps without silently rewriting obligations.
Current policy, observed practice, applicable requirements, incidents, ownership, and desired operating state.
Perform a gap analysis between the current policy, actual practice, and stated requirements.
Policy: [PASTE]
Observed practice: [PASTE]
Applicable requirements or standards: [PASTE]
Known incidents or exceptions: [PASTE]
Policy owner: [INSERT]
Desired operating state: [INSERT]
Method:
1. Map each relevant policy requirement to observed practice and evidence.
2. Classify as aligned, partially aligned, not aligned, unclear, or not evidenced.
3. Identify conflicts, ambiguity, missing ownership, and unenforceable language.
4. Distinguish a documentation gap from an operating gap.
Return:
- gap matrix
- severity and business impact
- evidence needed
- recommended remediation sequence
- owner and decision required
- draft revision notes, not final policy language
Do not provide legal conclusions or silently change obligations.You are a policy operations analyst. Compare current policy, actual practice, and stated requirements.
Create a matrix: requirement / policy language / observed practice / evidence / status / severity / owner / remediation. Separate documentation gaps from operating gaps. Identify ambiguity and conflicts.
Provide revision notes, not final legal policy. Do not give legal conclusions.
[PASTE MATERIALS]<role>Policy operations analyst</role>
<current_policy>[PASTE]</current_policy>
<observed_practice>[PASTE]</observed_practice>
<requirements>[PASTE]</requirements>
<incidents_and_exceptions>[PASTE]</incidents_and_exceptions>
<method>Map requirement to policy, practice, and evidence. Classify aligned, partial, not aligned, unclear, or not evidenced. Separate documentation gaps from operating gaps.</method>
<output>Gap matrix; severity and impact; evidence needed; remediation sequence; owner and decision; revision notes.</output>
<constraint>Do not provide legal conclusions or silently rewrite obligations.</constraint>Policy owner, counsel/compliance, operational users, and control owners should validate requirements, evidence, severity, and revisions.
Long-context model for multiple documents; reasoning-capable model for gap classification and remediation sequencing.
The operating standard
Across platforms and model types, keep the same controls around purpose, approved inputs, expected output, verification, ownership, and escalation.
Frequently asked questions
No. Start with a strong platform-neutral operating brief. Adapt only when a particular tool, model type, context window, output mode, or workflow requires it. Model names and behavior change, so the durable standard is the task, approved inputs, constraints, review, ownership, and successful output.
Neither is universally better. Suitability depends on the task, source material, required tools, speed, cost, account controls, and the organization’s ability to verify the result. The library keeps the business objective constant and shows two usable prompt structures.
Only after replacing placeholders and checking the organization’s data rules. Do not paste confidential, personal, regulated, contract-restricted, or security-sensitive information into an unapproved account or tool.
A fluent answer is not proof of accuracy, authorization, fairness, or business fit. The accountable person must verify facts, calculations, claims, policy, risk, exceptions, and final use.
Review it when the workflow changes, the approved platform or account changes, recurring errors appear, policy changes, or new model behavior materially affects output. Assign an owner and revision date rather than treating prompts as permanent documents.