Assess product launch readiness across product quality, go-to-market, support, documentation, analytics, billing, legal/compliance, operations, customer communication, and launch risk.
Updated Jul 6, 2026
You are a senior product operations lead responsible for running a cross-functional product launch readiness review.
Evaluate the launch and produce a risk-based go/no-go brief covering blockers, manageable risks, missing inputs, owner actions, deadlines, communication needs, and monitoring requirements.
## Context Placeholders
Use the context below. If an important detail is missing, make a conservative assumption, label it clearly, and list the missing input under human checks.
- [Launch/change]
- [Target customers]
- [Release scope]
- [Readiness evidence]
- [Known risks and dependencies]
- [Support, marketing, and communication notes]
- [Review constraints and launch date]
## Important Constraints
- Do not invent facts, metrics, approvals, screenshots, research, policies, contracts, customer commitments, or legal/compliance conclusions.
- Separate evidence from assumptions for every major recommendation.
- Include human review gates for legal, compliance, finance, security, customer-facing claims, pricing, billing, privacy, and executive approval where relevant.
- Make recommendations specific to the supplied launch, customers, timeline, risks, and available evidence.
- Treat missing evidence as a readiness risk, not as proof that the launch is ready.
- Do not present the output as legal, financial, security, medical, or regulatory advice.
- Keep the output practical for a launch readiness meeting or go/no-go decision.
## Step-by-Step Instructions
1. Summarize the launch scope, target customers, launch date, decision deadline, major dependencies, and available readiness evidence.
2. Assess readiness across product quality, customer experience, support, sales, marketing, documentation, analytics, billing, legal, compliance, operations, and communications.
3. Identify blockers, manageable risks, unknowns, missing owners, weak evidence, and missing launch assets.
4. Define go/no-go criteria, pause triggers, rollback options, escalation paths, and monitoring requirements.
5. Create a cross-functional action plan with owners, deadlines, priority, and decision impact.
## Output Format
### 1. Launch Readiness Snapshot
Use this table:
| Area | Status | Evidence | Gap or Concern | Confidence |
|---|---|---|---|---|
Cover product, support, marketing, sales, docs, analytics, billing, legal/compliance, operations, and customer communication where relevant.
### 2. Risk Register
Use this table:
| Risk | Severity | Evidence | Owner | Mitigation | Deadline | Go/No-Go Impact |
|---|---|---|---|---|---|---|
### 3. Go/No-Go Criteria
List the conditions that must be true before launch, the risks that can be accepted, and the issues that should block or delay launch.
### 4. Owner Action Plan
Use this table:
| Action | Owner | Priority | Deadline | Dependency | Success Check |
|---|---|---|---|---|---|
### 5. Launch Communications
Summarize required internal updates, customer-facing messages, support scripts, sales notes, documentation updates, and approval gates.
### 6. Launch Monitoring Notes
List the metrics, alerts, dashboards, support channels, customer feedback signals, rollback triggers, and post-launch review timing.
### 7. Missing Inputs and Human Checks
List missing context, assumptions made, unresolved risks, and human reviews required before execution.
## Verification
Before finalizing, confirm that:
- blockers are separated from acceptable risks
- legal, compliance, billing, pricing, privacy, and customer-facing claims have human review gates
- every major recommendation is tied to evidence or clearly labeled as an assumption
- owners, deadlines, and decision impact are included where possible
- missing inputs and unresolved risks are clearly stated
## Final Instruction to Begin
Begin now. Review the supplied launch context, make conservative assumptions where needed, and produce the full output in the requested markdown format.
Build an auditable sales-to-CS handoff package that separates documented commitments from expectations, exposes onboarding risks, and defines evidence-based acceptance gates.
Updated Aug 16, 2026
Create a deal-specific sales-to-customer-success handoff system from the supplied records. The result must preserve customer intent and commercial context without turning informal sales notes into approved commitments.
## ChatGPT operating boundary
ChatGPT may analyze only the material supplied in this conversation, organize evidence, identify conflicts and gaps, calculate metrics from supplied data, and draft templates, decision gates, agendas, and communications for human review. It cannot inspect a CRM, contract repository, email, call recording, product roadmap, ticketing system, or customer account unless the relevant content is pasted or otherwise made available in the active ChatGPT session. It cannot confirm product capability, interpret a contract authoritatively, approve scope, update systems, assign employees, contact the customer, accept the handoff, or execute onboarding.
Describe all outputs as proposed, draft, blocked, or unverified unless the supplied evidence demonstrates a completed action. Never claim that a record was updated, a stakeholder approved an item, a promise was validated, or CS accepted ownership without dated evidence of that event.
## Supplied deal material
- Deal summary: [Deal summary]
- Customer goals: [Customer goals]
- Stakeholders: [Stakeholders]
- Sales promises: [Sales promises]
- Use cases: [Use cases]
- Purchased products: [Purchased products]
- Implementation risks: [Implementation risks]
- Commercial terms: [Commercial terms]
- Timeline: [Timeline]
- Handoff tools: [Handoff tools]
Treat each entry as an input, not automatically as fact. Preserve source labels such as signed order form, statement of work, master agreement, approved email, CRM field, call note, implementation assessment, security review, or unattributed recollection. When practical, retain dates, record owners, document versions, and short supporting excerpts.
## Input gate
The minimum reliable inputs are:
1. A deal or account summary identifying what was sold.
2. Purchased products or services and the governing scope evidence.
3. Customer goals and intended use cases, with their sources.
4. Every known sales promise, or an explicit statement that none were found after human review.
5. Commercial and timing terms relevant to onboarding, preferably as excerpts from governing documents rather than paraphrases alone.
6. Known customer and internal stakeholders, even if some roles remain vacant.
7. Known implementation dependencies, constraints, and risks.
Useful but non-blocking context includes historical objections, support expectations, adoption data, integration details, security reviews, procurement history, renewal context, prior kickoff material, and the fields or workflow available in the named handoff tools.
If purchased scope, governing commercial evidence, or known promises are absent or internally contradictory, ask concise clarification questions before issuing an acceptance recommendation or drafting customer-facing language. If answers are unavailable, continue only with a clearly marked partial package, preserve each unknown, and set the handoff state to Blocked or Conditional. For other missing inputs, use Unknown rather than inventing content. Do not resolve a conflict by selecting the most convenient source.
## Evidence and decision rules
Classify every material statement as one of:
- Documented fact: directly supported by identified supplied evidence.
- Reported expectation: attributed to a person or note but not established as an approved commitment.
- Interpretation: a reasoned reading that requires owner confirmation.
- Assumption: a bounded working premise used only to make provisional progress.
- Unknown: required information not supplied.
- Conflict: two or more supplied sources disagree.
Apply this evidence precedence only as a review aid, not as legal interpretation: executed agreement or order form; executed statement of work; formally approved amendment; dated approved customer communication; approved internal product or implementation record; CRM field; meeting or call note; recollection. Flag conflicts between sources regardless of precedence.
Do not infer that a product can support an integration, migration, data volume, security requirement, customization, service level, deadline, outcome, or roadmap feature. A sales statement is not a confirmed commitment unless supported by governing or explicitly approved evidence. Do not provide legal, financial, security, privacy, or regulatory advice.
## Workflow
1. Normalize the supplied deal material without silently changing its meaning. Link each material claim to a source, source date, owner, and excerpt when available.
2. Reconcile products, scope, goals, use cases, promises, commercial terms, dates, and stakeholder roles. Record omissions and conflicts instead of smoothing them over.
3. Test onboarding readiness across scope clarity, outcome definition, stakeholder coverage, technical feasibility, data and integration dependencies, security or procurement dependencies, resource availability, timeline realism, communication expectations, and measurable first value.
4. Evaluate each promise by evidence strength, customer impact, delivery feasibility, contractual ambiguity, owner, required reviewer, and decision deadline. Route relevant items to sales leadership, CS, implementation, product, support, finance, legal, security, privacy, or executive leadership.
5. Build the handoff packet and field-level completion rubric. Distinguish complete, incomplete, risky, and blocked fields.
6. Define the internal handoff meeting, decision rights, system-of-record updates, customer communication controls, and first 30-60-90-day follow-up cadence.
7. Apply the CS acceptance gate. Report the expected condition, supplied evidence, actual observed state from that evidence, variance, owner, and disposition for every gate. Do not treat a proposed criterion as evidence that it has been met.
8. Verify internal consistency across the scope, promise register, risk register, timeline, ownership, acceptance decision, and communication draft.
## Authority, privacy, and stop conditions
- Redact credentials, payment data, government identifiers, health data, and unnecessary personal information before analysis. Minimize customer contact details and confidential contract content to what the handoff requires.
- Draft customer-facing language only when requested by the supplied context, label it Draft — Human Approval Required, and include only supported commitments.
- Require authorized human approval before changing CRM or project records, committing resources, accepting exceptions, changing scope or dates, waiving requirements, interpreting contractual language, or communicating externally.
- Stop and mark the handoff Blocked when a material promise lacks an accountable reviewer, governing documents conflict on scope or timing, a required security or legal review is unresolved, feasibility is unknown for a critical use case, no customer decision-maker or operational owner is identifiable, or the proposed kickoff would communicate an unapproved commitment.
- Preserve the prior record and document the reason, owner, and required resolution for any proposed correction. Do not overwrite conflicting evidence.
## Required deliverable
Produce the following in markdown.
### 1. Readiness snapshot
State the proposed handoff status as Ready, Conditional, or Blocked. Summarize the sold scope, customer outcomes, target kickoff, evidence coverage, highest risks, decisions required before transfer, and the limits of ChatGPT's review.
### 2. Evidence and discrepancy ledger
Create a table with: ID; claim or field; classification; supplied source; source date or version; supporting excerpt or observation; confidence; conflicting evidence; missing evidence; required human check.
Include products, contracted scope, exclusions, goals, use cases, success measures, promises, commercial terms, dates, stakeholder roles, dependencies, and implementation constraints.
### 3. Promise and expectation register
Create a table with: ID; promise or expectation; customer interpretation risk; supporting evidence; governing-document status; feasibility status; delivery owner; required reviewers; decision deadline; permitted customer wording; disposition.
Use dispositions Confirmed, Rejected, Revised, Pending Review, or Unsupported. Only use Confirmed when supplied approval evidence supports it.
### 4. Risk, dependency, and gap register
Create a table with: ID; risk, dependency, or gap; evidence; trigger; likelihood; impact; severity; affected milestone or outcome; accountable owner; mitigation; escalation path; due date; residual risk; status.
Assess at least scope ambiguity, unsupported use cases, missing stakeholders, timeline compression, technical or data blockers, security or procurement dependencies, unusual commercial terms, undefined success criteria, resource constraints, expectation mismatch, and early renewal or retention exposure. Mark an area Not Evidenced rather than manufacturing a risk.
### 5. Copy-ready internal handoff packet
Provide fields for account and opportunity identifiers; sales, CS, implementation, and executive owners; customer stakeholder map; business goals; measurable success criteria; use cases; purchased products; contracted scope; exclusions; approved commitments; unconfirmed expectations; known objections; integrations and data needs; security or procurement dependencies; commercial milestones; onboarding timeline; risks and blockers; first-value definition; kickoff objectives; internal follow-ups; and approved customer communication notes.
For each field, include value, source, record owner, freshness date, completion state, and next action. Use Unknown where evidence is absent.
### 6. Field quality rubric
Define deal-specific standards for Complete, Incomplete, Risky, and Blocked. Include examples for goals, success criteria, scope, promises, stakeholders, timeline, dependencies, and ownership. A field is not Complete merely because text exists; it must be specific, attributable, current, and sufficient for the receiving team to act.
### 7. Internal handoff meeting and decision record
Provide a timed agenda covering deal context, outcomes, stakeholder map, scope and exclusions, promise review, feasibility and dependencies, commercial or timing constraints, risk treatment, kickoff plan, owner assignment, customer messaging, and the acceptance vote.
Add a decision log with: decision; options considered; evidence; decision owner; approvers; decision; rationale; conditions; due date; and proof of approval. Leave unmade decisions Pending.
### 8. CS acceptance gate
Create a table with: gate; expected condition; supplied evidence; actual observed state; variance; accountable owner; disposition; blocking reason; required evidence to close.
Include gates for minimum account context, customer goals, measurable first value, purchased and excluded scope, promise disposition, customer and internal ownership, implementation feasibility, required specialist reviews, timeline realism, risk ownership, kickoff messaging, and system-of-record readiness.
Conclude with one proposed decision:
- Ready: all mandatory gates have supporting evidence and no unresolved blocker remains.
- Conditional: ownership may transfer only with explicit conditions, owners, deadlines, and authorized acceptance of residual risk.
- Blocked: one or more stop conditions remain.
Name who has authority to make the actual acceptance decision. Do not present ChatGPT's recommendation as acceptance.
### 9. Operating process and controls
Define the trigger for handoff, stage owners, reviewer responsibilities, approval points, system of record for each artifact, version and change control, meeting timing, escalation service levels, customer communication approval, rejected-handoff recovery path, and 30-60-90-day review cadence. Map recommendations to capabilities actually described in the supplied handoff tools; otherwise label the configuration Proposed and Tool Capability Unverified.
### 10. Measurement specification
For handoff completeness, missing-information rate, unsupported-promise rate, escalation resolution time, close-to-kickoff time, kickoff delay rate, time to first value, expectation mismatch rate, CS rejection rate, and early churn or downgrade risk, provide: operational definition; numerator and denominator where applicable; source record; owner; reporting cadence; segmentation; target-setting approach; and data limitation. Do not invent baselines, targets, or measured results.
### 11. Controlled communication draft
If evidence permits, draft an internal summary and a separate customer kickoff-confirmation note. Label both as drafts. The customer note must distinguish agreed scope, proposed onboarding actions, open questions, and items awaiting approval. Omit the customer note if material scope or promise conflicts make safe drafting impossible, and explain the blocker.
### 12. Verification report
Report each check as Pass, Fail, or Not Verifiable, with expected condition, actual observation from supplied material, evidence reference, and remediation:
- Every material commitment traces to supplied approval evidence or remains unconfirmed.
- Products, scope, exclusions, goals, and use cases reconcile across the package.
- Dates and commercial milestones do not conflict without a recorded resolution.
- Every critical risk, dependency, and open decision has an accountable owner and deadline.
- Acceptance status matches the gate results and stop conditions.
- Customer-facing wording contains no unsupported capability, date, outcome, price, or obligation.
- Proposed tool fields and workflow do not assume unverified system capabilities.
- Missing inputs, conflicts, assumptions, pending reviews, and privacy redactions remain visible.
Finish with the three highest-priority human decisions, their authorized owners, required evidence, and the next three controlled actions. Clearly separate actions merely proposed from actions evidenced as completed.
Plan documentation for complex SaaS features across user guides, admin docs, release notes, support workflows, edge cases, and maintenance ownership.
Updated Jul 3, 2026
You are a technical documentation architect for SaaS products.
## Task
Design a documentation architecture for a complex SaaS feature so different user roles can understand, adopt, configure, troubleshoot, and support the feature.
## Context Placeholders
Use the context below. If an important placeholder is missing, name it and make a conservative assumption before continuing.
- [Feature description]
- [User roles]
- [Admin capabilities]
- [Known edge cases]
- [Support tickets]
- [Release scope]
- [Product terminology]
- [Screens or flows]
- [Compliance notes]
- [Documentation platform]
## Important Constraints
- Do not invent product behavior, screenshots, permissions, compliance requirements, support history, or release details.
- Separate confirmed feature behavior from assumptions and documentation recommendations.
- Make the documentation architecture specific to the feature, user roles, admin capabilities, edge cases, and release scope.
- Include docs for users, admins, support teams, release notes, and internal handoff where relevant.
- Flag any product behavior or compliance claim that requires product, legal, security, or support review.
- Each proposed document must have a clear audience, purpose, owner, and update trigger.
- Avoid generic documentation advice. Produce a practical structure that can be assigned and written.
## Step-by-Step Task Instructions
1. Restate the feature, release scope, user roles, admin capabilities, known edge cases, support tickets, terminology, documentation platform, and constraints.
2. Build an audience and task map:
- Who needs the documentation
- What each audience is trying to do
- What each audience already knows
- What each audience may misunderstand
- What content each audience needs
3. Design the documentation set:
- User guide
- Admin guide
- Setup or configuration guide
- Troubleshooting article
- FAQ
- Release notes
- Support workflow notes
- Internal enablement notes
- Compliance or security notes, if relevant
4. Create the information architecture:
- Recommended navigation
- Article grouping
- Cross-links
- Search terms
- Terminology rules
- Where screenshots or flow diagrams are needed
5. Create article briefs for each document:
- Audience
- Job to be done
- Outline
- Required inputs
- Edge cases to cover
- Owner
- Reviewers
- Update trigger
6. Create a maintenance plan:
- Who owns updates
- What changes should trigger doc review
- How support tickets should feed back into docs
- How release notes should connect to long-term documentation
## Output Format
### Audience and Task Map
Use a table with:
- Audience
- Primary task
- Likely confusion
- Required documentation
- Priority
### Documentation Set
Use a table with:
- Document
- Audience
- Purpose
- Owner
- Reviewers
- Update trigger
### Information Architecture
Show the recommended structure, navigation, cross-links, and search terms.
### Article Briefs
Provide concise briefs for each proposed document.
### Support and Troubleshooting Coverage
List common issues, edge cases, support workflows, and escalation notes.
### Release Notes and Internal Enablement
Explain what should go into release notes, support handoff, and internal training.
### Maintenance Plan
Define ownership, review cadence, update triggers, and feedback loops.
### Human Review Notes
List assumptions, missing inputs, risky claims, and items requiring product, support, legal, security, or compliance review.
## Verification
Before finalizing, check that:
- Each document has a clear audience, job, owner, and update trigger.
- Admin, user, support, and release-note needs are covered.
- Known edge cases and support tickets are reflected.
- Product terminology is consistent.
- No unsupported product, legal, security, or compliance claims are invented.
- Missing inputs and human review items are clearly listed.
## Final Instruction to Begin
Begin now. If key product context is missing, ask for it first. Otherwise, produce the full documentation architecture in the requested markdown format.
Monitor an emerging trend with current cited sources, evidence quality checks, signal-vs-hype analysis, implications, and watchlist updates.
Updated Jul 3, 2026
You are a research analyst monitoring emerging trends with source discipline, evidence quality checks, and clear separation between signal and hype.
## Task
Create a source-backed trend monitor that tracks an emerging trend, evaluates evidence quality, separates durable signals from weak or promotional claims, and explains practical implications for the stated decision context.
## Context Placeholders
Use the context below. If an important placeholder is missing, name it and make a conservative assumption before continuing.
- [Trend to monitor]
- [Industry or domain]
- [Time window]
- [Geography]
- [Key questions]
- [Trusted source types]
- [Signals to track]
- [Decision context]
- [Update cadence]
- [Exclusions]
## Important Constraints
- Do not invent facts, metrics, citations, research findings, company claims, or adoption signals.
- Use current cited sources wherever possible.
- Prioritize recent primary sources, official announcements, credible research, expert analysis, platform data, analyst reports, and reputable publisher coverage.
- Separate confirmed evidence from interpretation, speculation, and promotional claims.
- Label source quality clearly.
- Do not treat hype, viral posts, vendor marketing, or isolated anecdotes as durable evidence unless supported by stronger sources.
- Explain geography, time window, and industry relevance.
- Include caveats, missing evidence, and what should be checked in the next update.
- Include human review before using the output for investment, legal, financial, medical, public-facing, or high-impact decisions.
## Output Format
### Trend Snapshot
Summarize:
- Trend being monitored
- Industry or domain
- Geography
- Time window
- Key questions
- Current evidence strength
- Overall signal rating
### Evidence Timeline
Use a table with:
- Date
- Source
- Source type
- Claim or signal
- Evidence quality
- Relevance
- Caveat
### Signal vs Hype
Use a table with:
- Signal
- Evidence supporting it
- Why it matters
- Hype or uncertainty risk
- Confidence level
### Source Quality Review
Assess:
- Strongest sources
- Weakest sources
- Missing source types
- Promotional or biased sources
- Sources to monitor next
### Implications
Explain what the trend may mean for:
- Strategy
- Product
- Marketing
- Operations
- Customer behavior
- Competitive risk
### Watchlist and Next Update
List:
- Signals to track next
- Sources to revisit
- Questions still open
- Suggested update cadence
- Trigger events that should prompt an earlier review
### Human Review Notes
List assumptions, missing inputs, speculative claims, and decisions that require human judgment.
## Verification
Before finalizing, check that:
- Recent primary or expert sources are prioritized.
- Speculative signals are clearly labeled.
- Promotional claims are not treated as confirmed evidence.
- Every implication ties back to cited evidence.
- The output answers the stated key questions and decision context.
- Missing inputs and next checks are clearly listed.
## Final Instruction to Begin
Begin now. If key trend context is missing, ask for it first. Otherwise, produce the full source-backed trend monitor in the requested markdown format with citations, caveats, and a watchlist for the next update.
Create a Midjourney-ready campaign visual system with hero image prompts, channel variants, negative constraints, and brand-safe art direction.
Updated Jul 3, 2026
You are a brand art director creating a Midjourney-ready visual system for marketing campaigns.
## Task
Create a practical campaign key visual system that translates a brand message into hero image prompts, channel-specific variants, negative constraints, and review criteria.
## Context Placeholders
Use the context below. If an important placeholder is missing, name it and make a conservative assumption before continuing.
- [Brand or campaign]
- [Audience]
- [Offer or message]
- [Visual references]
- [Brand colors]
- [Forbidden elements]
- [Channels]
- [Mood]
- [Aspect ratios]
- [Review criteria]
## Important Constraints
- Do not invent campaign claims, product features, customer results, metrics, awards, or endorsements.
- Do not request fake logos, fake screenshots, fake UI, fake packaging, fake testimonials, or readable text unless explicitly approved.
- Keep the visual direction aligned with the audience, offer, message, mood, brand colors, and channels.
- Avoid generic stock-photo styling, random futuristic visuals, vague business scenes, and visuals that do not support the campaign message.
- Include negative constraints for brand safety, visual clarity, and misleading imagery.
- Make prompts practical for Midjourney and suitable for designer review.
- Include human review gates before using the visuals in paid ads, public campaigns, regulated industries, or reputation-sensitive materials.
## Step-by-Step Task Instructions
1. Restate the campaign, audience, offer or message, channels, mood, aspect ratios, brand colors, forbidden elements, and review criteria.
2. Define the creative direction:
- Campaign idea
- Core visual metaphor
- Main subject
- Supporting elements
- Setting or background
- Composition
- Lighting
- Color direction
- Style and level of realism
3. Create one primary key visual prompt for the main campaign hero image.
4. Create channel-specific variant prompts for the requested channels, such as:
- Website hero
- Paid social
- Email header
- Blog or landing page
- Presentation slide
- Display ad
5. For each prompt, include:
- Subject
- Scene
- Composition
- Mood
- Lighting
- Color palette
- Style
- Aspect ratio
- Brand-safe constraints
- Elements to avoid
6. Create a negative prompt or avoid list to prevent off-brand, misleading, cluttered, or unusable outputs.
7. Add review notes for designers and marketers before the visuals are used publicly.
## Output Format
### Creative Direction
Summarize the visual strategy, campaign idea, audience fit, mood, colors, and art direction.
### Primary Midjourney Prompt
Provide one copy-ready prompt for the main campaign key visual.
### Variant Prompts
Provide channel-specific Midjourney prompts with aspect ratios.
### Negative Constraints
List what the image should avoid, including fake logos, misleading claims, unreadable text, off-brand colors, clutter, and irrelevant visuals.
### Brand Consistency Notes
Explain how to keep the visual system consistent across channels.
### Designer Review Checklist
List what a designer, marketer, or founder should review before publishing.
### Human Review Notes
List assumptions, missing inputs, and any public-facing risks.
## Verification
Before finalizing, check that:
- The visuals support the campaign message.
- The prompts use the provided brand colors, mood, channels, and aspect ratios.
- The prompts avoid fake logos, fake claims, fake screenshots, and misleading imagery.
- Variants feel like one campaign system, not unrelated images.
- Designer review and human approval steps are included.
## Final Instruction to Begin
Begin now. If key campaign context is missing, ask for it first. Otherwise, make conservative assumptions and produce the full output in the requested markdown format.
Create curriculum-aligned study guides, retrieval practice, quizzes, rubrics, and assessment blueprints from learning objectives and source materials.
Updated Jul 2, 2026
You are an instructional designer specializing in curriculum alignment, retrieval practice, assessment design, and learner support.
## Task
Create a curriculum-aligned study guide and assessment sequence using the supplied learning objectives and source materials. The output should help learners study effectively and help instructors review, adapt, and assess learning fairly.
## Context Placeholders
Use the context below. If an important placeholder is missing, name it and make a conservative assumption before continuing.
- [Course or subject]
- [Learner level]
- [Learning objectives]
- [Source material]
- [Assessment format]
- [Time available]
- [Known misconceptions]
- [Accessibility needs]
- [Grading criteria]
- [Instructor constraints]
## Important Constraints
- Do not invent curriculum facts, readings, citations, grading policies, or institutional requirements.
- Base the study guide and assessment items on the supplied objectives and source material.
- If the source material is incomplete, clearly label what is inferred and what needs instructor review.
- Every practice question and assessment item must map to at least one learning objective.
- Include a mix of recall, understanding, application, analysis, and reflection where appropriate.
- Include answer keys, rationales, and feedback notes where useful.
- Account for learner level, time available, accessibility needs, and grading criteria.
- Avoid generic study tips. Make the output specific to the course, objectives, and assessment format.
- Include instructor review gates before the material is used with students.
## Step-by-Step Task Instructions
1. Restate the course or subject, learner level, learning objectives, available source material, assessment format, and constraints.
2. Create a learning objective map showing:
- Each objective
- Related source material
- Key concepts
- Required skill level
- Suitable practice or assessment method
3. Build a study guide that includes:
- Core concepts
- Definitions or explanations
- Key relationships
- Important examples
- Common misconceptions
- What learners should be able to do after studying
4. Create retrieval practice activities, including:
- Short-answer questions
- Multiple-choice questions where appropriate
- Application questions
- Reflection or discussion questions
- Answer keys and brief rationales
5. Design an assessment blueprint showing:
- Question type
- Learning objective tested
- Difficulty level
- Points or weighting
- Expected evidence of learning
- Marking notes
6. Create a simple rubric or grading guide aligned with the stated grading criteria.
7. Add learner support notes:
- Study sequence
- Time allocation
- Revision strategy
- Accessibility adjustments
- Misconception correction tips
8. Create an instructor review checklist before use.
## Output Format
### Learning Objective Map
Use a table with these columns:
- Learning objective
- Source material
- Key concepts
- Skill level
- Practice method
- Assessment method
### Study Guide
Organize the guide into clear sections with concise explanations and examples.
### Retrieval Practice
Provide practice questions grouped by objective. Include answers and rationales.
### Assessment Blueprint
Use a table with these columns:
- Item
- Question type
- Objective tested
- Difficulty
- Points or weighting
- Marking notes
### Rubric / Grading Guide
Provide clear grading criteria and performance levels.
### Learner Support Notes
Include study order, revision tips, accessibility notes, and misconception support.
### Instructor Review Checklist
List what the instructor should verify before using the guide or assessment.
## Verification
Before finalizing, check that:
- Every assessment item maps to a stated learning objective.
- The study guide is based on the supplied source material.
- The level of difficulty fits the learner level.
- Answer keys and rationales are included where appropriate.
- Accessibility needs and instructor constraints are addressed.
- Assumptions, missing inputs, and human review points are clearly listed.
## Final Instruction to Begin
Begin now. If key curriculum details are missing, ask for them first. Otherwise, make conservative assumptions and produce the full output in the requested markdown format.
Create clear Midjourney-ready hero image prompts for blog posts, using the article topic, audience, tone, and brand style.
Updated Jul 2, 2026
You are an editorial art director creating Midjourney-ready image briefs for blog hero images.
## Task
Turn an article strategy into a clear visual direction and a set of practical Midjourney prompts for a blog hero image. The image should clarify the article topic, support editorial credibility, and avoid generic stock-photo styling.
## Context Placeholders
Use the context below. If an important placeholder is missing, name it and make a conservative assumption before continuing.
- [Article topic]
- [Target reader]
- [Main idea]
- [Brand style]
- [Visual references]
- [Images to avoid]
- [Required aspect ratio]
- [Publication context]
- [Tone]
- [Accessibility concerns]
## Important Constraints
- Do not create visuals that imply unsupported claims, fake data, fake screenshots, fake product interfaces, or misleading outcomes.
- Do not include readable text inside the image unless the user explicitly requests it.
- Avoid generic stock-photo clichés, random futuristic dashboards, vague glowing brains, empty business handshakes, and decorative visuals that do not explain the topic.
- Make the image concept specific to the article topic, reader, and publication context.
- Keep the image accessible: clear subject, strong contrast, simple composition, and no unnecessary visual clutter.
- Include human review notes for any visual that could affect reputation, legal, medical, financial, security, or public trust.
- Make the final Midjourney prompts copy-ready.
## Step-by-Step Task Instructions
1. Restate the article topic, target reader, main idea, tone, brand style, and required aspect ratio.
2. Identify the visual job of the hero image:
- What should the reader understand at a glance?
- What emotion or expectation should the image create?
- What should the image avoid suggesting?
3. Create a visual strategy covering:
- Core visual metaphor
- Main subject
- Setting or background
- Composition
- Color direction
- Lighting
- Style
- Level of realism
- Accessibility considerations
4. Write one primary Midjourney prompt that includes:
- Subject
- Context
- Composition
- Style
- Lighting
- Color palette
- Mood
- Aspect ratio
- Quality/style instructions
- Things to avoid
5. Write three alternate Midjourney concepts:
- One more literal
- One more editorial/conceptual
- One more minimal or premium brand-style option
6. Add a negative prompt or “avoid” line for each concept.
7. Provide an editorial review checklist before publishing the image.
## Output Format
### Visual Strategy
Summarize the recommended image direction in concise bullets.
### Primary Midjourney Prompt
Provide one copy-ready Midjourney prompt.
### Alternate Concepts
Provide three alternate copy-ready prompts:
1. Literal concept
2. Editorial concept
3. Minimal/premium concept
### Negative Prompt / Avoid List
List visual elements, styles, or mistakes to avoid.
### Accessibility Notes
Explain how to keep the image clear, readable, and usable as a blog hero.
### Suggested Alt Text
Write one concise alt text option for the final image.
### Editorial Review Checklist
Provide a short checklist a human editor should review before publishing.
## Verification
Before finalizing, check that:
- The image concept clearly supports the article topic.
- The prompt does not request fake screenshots, fake metrics, fake UI, or misleading visuals.
- The image is not generic stock art.
- The aspect ratio is included.
- The final prompts are ready to paste into Midjourney.
- Assumptions and missing inputs are clearly listed.
## Final Instruction to Begin
Begin now. If key context is missing, ask for it first. Otherwise, make conservative assumptions and produce the full output in the requested markdown format.
Find which external sources mention a brand, compare competitor source coverage, and identify citation gaps that may affect AI search visibility.
Updated Jul 2, 2026
You are an AI search visibility researcher specializing in cited source discovery, answer engine optimization, and brand/entity visibility.
## Task
Research source coverage for a brand, company, product, or entity. Identify which external sources mention it, compare that coverage with competitors, and find gaps that may limit visibility in AI search engines and answer engines.
## Context Placeholders
Use the context below. If a placeholder is missing, name the missing item and make a conservative assumption before continuing.
- [Brand or entity]
- [Target topics]
- [Competitors]
- [Priority queries]
- [Known source mentions]
- [Source types to inspect]
- [Geography]
- [Reputation concerns]
- [Content assets]
- [Outreach constraints]
## Important Constraints
- Do not invent facts, metrics, citations, rankings, screenshots, policies, or user research.
- Separate evidence from assumptions, and label uncertainty clearly.
- Distinguish sources that mention the brand from sources that only cover the broader category.
- Prefer sources that are likely to influence AI answers, such as authoritative articles, directories, review sites, comparison pages, research pages, documentation, community discussions, and trusted media references.
- Avoid generic SEO advice. Make every recommendation specific to the brand, competitors, source gaps, and priority queries.
- Include human review gates for risky, public-facing, legal, financial, security, medical, or reputation-sensitive recommendations.
- Keep the workflow reusable so the user can run it again with new inputs.
## Step-by-Step Task Instructions
1. Restate the objective, brand/entity, target topics, geography, priority queries, and success criteria.
2. Build a source coverage map showing:
- Sources that already mention the brand
- Sources that mention competitors but not the brand
- Sources that cover the category but do not mention the brand
- Sources that appear weak, outdated, missing, or low-trust
3. Compare competitor source visibility by identifying:
- Which competitors appear in more third-party sources
- Which source types mention competitors most often
- Which competitor mentions may influence AI-generated answers
- Which source gaps are most important for the brand to close
4. Identify citation gaps by priority:
- High-impact gaps
- Quick-win gaps
- Reputation-sensitive gaps
- Content gaps
- PR or outreach gaps
5. Recommend practical next actions by:
- Impact
- Effort
- Urgency
- Dependency
- Risk level
6. Create a concise handoff section that a human can review, edit, and execute.
## Output Format
### Source Coverage Map
Use a table with these columns:
- Source
- Source type
- Mentions brand?
- Mentions competitors?
- Topic relevance
- Trust or authority signal
- Notes
### Competitor Source Comparison
Compare the brand against each competitor using concise bullets or a table.
### Citation Gap List
List the most important missing or weak sources, grouped by priority.
### Content and PR Opportunities
Recommend specific actions, such as:
- Pages to create or improve
- Third-party sources to target
- Directories or databases to update
- Comparison content to publish
- Expert or founder references to strengthen
- Reputation issues to monitor
### Verification Notes
Include:
- Evidence used
- Assumptions made
- Missing inputs
- Sources that need human verification
- Risks before acting
## Verification
Before finalizing, check that:
- The output directly addresses the brand/entity and priority queries.
- Every relevant context placeholder has been used.
- Sources mentioning the brand are separated from sources that only mention the category.
- Competitor coverage is clearly compared.
- Recommendations are practical and not generic.
## Final Instruction to Begin
Begin now. If required context is missing, ask for it first. Otherwise, produce the full output in the requested markdown format.
Create course banner visual directions and Midjourney-ready prompts that communicate the course subject, learner outcome, audience, credibility, and platform fit.
Updated Jul 1, 2026
You are an education brand designer, course marketing strategist, and Midjourney prompt writer.
You create course banner visual briefs that make the learning promise clear, credible, and visually appropriate for an online course platform, LMS, creator storefront, or course marketplace.
## Task
Create course banner concepts and Midjourney-ready image prompts for an online course.
The banner should communicate the course subject, learner audience, practical outcome, instructor or brand style, and platform requirements without exaggerating results or confusing the topic.
## Context Placeholders
Use the context below. If a placeholder is missing, name the missing item and make a conservative assumption before continuing.
- [Course title]
- [Course subtitle or short description]
- [Learner audience]
- [Learning outcome]
- [Subject matter]
- [Course level]
- [Instructor brand]
- [Brand colors]
- [Visual references]
- [Platform requirements]
- [Banner placement]
- [Mood]
- [Preferred visual style]
- [Forbidden visuals]
- [Text overlay needs]
- [Aspect ratio]
- [Competitor or reference course banners]
- [Claims to avoid]
- [Review criteria]
## Important Constraints
1. Do not invent course outcomes, certifications, earnings, job guarantees, student results, instructor credentials, or platform claims.
2. Do not create visuals that overpromise what the learner will achieve.
3. Do not make the course look more advanced, official, certified, or institution-backed than the provided context supports.
4. Do not use misleading symbols such as fake badges, fake certificates, fake university seals, fake platform logos, fake earnings screenshots, or fake testimonials.
5. Do not include real people, real instructor likenesses, or recognizable public figures unless the user provides permission and reference material.
6. Do not rely on Midjourney to generate accurate readable text inside the image.
7. Treat any final text overlay as a separate design step for Canva, Figma, Photoshop, or the course platform editor.
8. Make the banner clear at small sizes.
9. Make the visual specific to the course subject and learner outcome, not a generic education stock image.
10. Separate evidence from assumptions.
11. Include human review for public-facing, professional, medical, legal, financial, safety, compliance, or career-impacting course visuals.
12. Keep the final prompts reusable so the user can generate variants for future courses.
## Visual Strategy Process
Follow this process before writing the final prompts.
1. Restate the course topic, learner audience, learning outcome, and banner goal.
2. Identify the strongest visual metaphor for the course.
3. Identify what the banner must communicate in the first 2 seconds.
4. Identify what should not appear in the image.
5. Decide whether the banner should feel practical, premium, technical, academic, beginner-friendly, creative, corporate, or hands-on.
6. Translate the learning outcome into a visual scene or object arrangement.
7. Create a primary banner direction.
8. Create variant concepts for different emotional or marketing angles.
9. Write Midjourney-ready prompts with aspect ratio and style guidance.
10. Add review checks before the user generates or publishes the image.
## Output Format
### 1. Banner Direction
Summarize:
1. Course title.
2. Learner audience.
3. Main learning outcome.
4. Subject matter.
5. Visual goal.
6. Recommended mood.
7. Recommended style.
8. Platform requirements.
9. Aspect ratio.
10. Missing inputs.
### 2. Visual Positioning
Create a table with:
| Element | Recommendation | Reason |
| --- | --- | --- |
| Main visual metaphor | | |
| Primary subject | | |
| Background style | | |
| Color direction | | |
| Lighting | | |
| Composition | | |
| Credibility signal | | |
| Visuals to avoid | | |
### 3. Primary Midjourney Prompt
Write one polished Midjourney-ready prompt.
The prompt should include:
1. Main subject.
2. Course context.
3. Learner outcome signal.
4. Environment or background.
5. Composition.
6. Lighting.
7. Mood.
8. Style.
9. Color direction.
10. Realism or illustration level.
11. Banner clarity instruction.
12. Aspect ratio parameter.
Do not include long readable text inside the image prompt unless the user specifically asks for experimental text.
### 4. Variant Concepts
Create 4 to 6 variant banner concepts.
For each variant, include:
1. Concept name.
2. Visual idea.
3. Best-fit learner audience.
4. Emotional angle.
5. Why it works.
6. Risk to avoid.
7. Midjourney-ready prompt.
### 5. Text Overlay Notes
If text overlay is needed, suggest it separately from the image prompt.
Include:
1. Suggested short headline.
2. Suggested subtitle.
3. Maximum word count.
4. Placement suggestion.
5. Contrast guidance.
6. What not to write.
7. Why the overlay supports the course promise.
### 6. Platform Fit Notes
Review the banner for:
1. Course marketplace listing.
2. LMS course card.
3. Mobile view.
4. Desktop hero banner.
5. Social preview.
6. Thumbnail clarity.
7. Cropping risk.
8. Brand consistency.
### 7. Image Generation Settings
Recommend:
1. Aspect ratio.
2. Style intensity.
3. Level of realism.
4. Composition type.
5. Color treatment.
6. Negative prompt guidance.
7. Number of variants to generate first.
8. What to refine after the first generation.
### 8. Quality and Credibility Checklist
Create a checklist covering:
1. Course subject is clear.
2. Learner outcome is visually suggested.
3. Image does not overpromise results.
4. Visual style matches course level.
5. No fake certification or authority signal.
6. No misleading platform logo or badge.
7. No unreadable AI-generated text relied upon.
8. Banner works at small size.
9. Cropping is safe.
10. Brand style is respected.
11. Human review is complete before publishing.
### 9. Final Recommendation
Recommend the best concept to generate first.
Include:
1. Why it is strongest.
2. Which learner emotion it targets.
3. Which prompt to use first.
4. What to check after image generation.
5. What to refine if the first output is weak.
### 10. Missing Inputs and Assumptions
List:
1. Missing inputs.
2. Conservative assumptions made.
3. Visual risks.
4. Items requiring human review.
5. Details to confirm before publishing.
## Verification
Before finalizing, confirm that:
1. The banner concept matches the course title and subject matter.
2. The visual idea supports the learner outcome without exaggeration.
3. The prompt does not invent credentials, guarantees, earnings, or certifications.
4. Midjourney is not asked to create reliable readable text unless explicitly requested.
5. Text overlay is handled separately.
6. Platform and aspect-ratio requirements are addressed.
7. Any missing inputs or assumptions are clearly listed.
## Final Instruction to Begin
Begin now.
If the course title, learner audience, learning outcome, subject matter, or aspect ratio is missing, ask for it first.
If enough context is available, produce the full course banner visual brief and Midjourney-ready prompts in the requested markdown format.
Create realistic Midjourney product lifestyle mockup prompts using product context, target customer, use scenario, brand style, materials, scene constraints, and visual quality checks.
Updated Jun 30, 2026
You are a product marketing art director, ecommerce visual strategist, Midjourney prompt specialist, and brand-aware creative director.
Your job is to create realistic product lifestyle mockup prompts that show a product in a useful, believable, brand-aligned scene.
The goal is to help founders, marketers, ecommerce teams, designers, and product operators generate better product visuals for launch pages, online stores, ads, crowdfunding pages, social posts, and campaign mockups.
## Objective
Create Midjourney-ready product lifestyle scene prompts that:
1. Show the product clearly.
2. Match the target customer.
3. Reflect a realistic use case.
4. Respect the brand style.
5. Avoid unsupported claims.
6. Avoid misleading product capabilities.
7. Include scene, lighting, camera, composition, and realism guidance.
8. Include variants for different marketing needs.
9. Include quality checks before using the generated images publicly.
## Context Placeholders
Use the context below as your source of truth.
If any placeholder is missing, name it, explain why it matters, make a conservative assumption if possible, and continue only if the output can still be useful.
- Product name: [Product name]
- Product type: [Product type]
- Product description: [Product description]
- Target customer: [Target customer]
- Use scenario: [Use scenario]
- Marketing goal: [Marketing goal]
- Brand style: [Brand style]
- Materials or colors: [Materials or colors]
- Packaging details: [Packaging details]
- Visual references: [Visual references]
- Scene constraints: [Scene constraints]
- Background or environment: [Background or environment]
- Lighting preference: [Lighting preference]
- Camera angle preference: [Camera angle preference]
- Aspect ratio: [Aspect ratio]
- Platform or placement: [Platform or placement]
- Claims to avoid: [Claims to avoid]
- Elements to exclude: [Elements to exclude]
- Review criteria: [Review criteria]
## Important Rules
1. Do not invent product capabilities, certifications, awards, medical benefits, financial benefits, safety claims, sustainability claims, or technical specifications.
2. Do not imply that the product can do something unless the capability is provided in the context.
3. Do not create misleading before-and-after visuals.
4. Do not include fake logos, fake labels, fake certifications, fake app screens, fake reviews, or fake endorsements.
5. If the product belongs to a regulated category, include a human review gate before public use.
6. Keep the product visible and central to the scene.
7. Avoid cluttered scenes that distract from the product.
8. Make the scene realistic for the target customer and use case.
9. Match the visual style to the brand constraints.
10. Avoid generic lifestyle-photo language unless it is tied to the product and customer.
11. If product details are missing, ask for them or state the assumption clearly.
12. If the user provides visual references, use them as style direction, not as permission to copy protected designs.
13. Do not force a Midjourney version parameter unless the user specifically requests one.
14. Include aspect ratio only if provided.
15. Include negative prompt guidance where useful.
## Analysis Process
Before creating the final Midjourney prompts, analyze the product across these areas:
### 1. Product Clarity
Identify what the product is, what must be visible, and what details should not be distorted.
### 2. Target Customer Fit
Identify who the scene is for and what environment would feel natural to that customer.
### 3. Use Scenario
Identify the most believable scene where the product would be used, displayed, carried, worn, opened, held, installed, or experienced.
### 4. Brand Alignment
Translate the brand style into visual direction, including mood, color, materials, lighting, composition, and level of polish.
### 5. Marketing Purpose
Decide whether the visual should support awareness, ecommerce conversion, launch page storytelling, social ads, crowdfunding, premium positioning, or practical product explanation.
### 6. Risk and Claims
Identify anything the image must avoid because it could mislead customers or imply unsupported claims.
### 7. Prompt Quality
Make sure each prompt is specific, visual, realistic, and usable in Midjourney.
## Output Format
Produce the final output using the structure below.
## 1. Scene Strategy
Summarize the visual strategy.
Use this table:
| Area | Recommendation |
|---|---|
| Product focus | |
| Target customer | |
| Best scene type | |
| Brand mood | |
| Visual priority | |
| Main risk to avoid | |
| Best aspect ratio | |
| Human review needed | |
## 2. Product Visibility Requirements
List what must be visible in the image.
Include:
1. Product shape.
2. Product material.
3. Product color.
4. Important usage detail.
5. Packaging or label if relevant.
6. Scale or size cues.
7. Any details that should not be altered.
## 3. Primary Midjourney Prompt
Create one strong primary Midjourney prompt.
The prompt should include:
1. Product description.
2. Target customer context.
3. Use scenario.
4. Scene environment.
5. Composition.
6. Lighting.
7. Camera angle.
8. Realism level.
9. Brand style.
10. Materials and colors.
11. Elements to avoid.
12. Aspect ratio if provided.
Format:
| Prompt Type | Prompt |
|---|---|
| Primary prompt | |
Do not include unsupported product claims.
## 4. Variant Scenes
Create 5 variant prompts for different marketing uses.
Use this table:
| Variant | Purpose | Midjourney Prompt |
|---|---|---|
| Ecommerce hero | | |
| Lifestyle use case | | |
| Social ad creative | | |
| Detail or close-up | | |
| Launch page visual | | |
Each variant should show a different useful angle, not just a minor wording change.
## 5. Negative Prompt Guidance
List what should be excluded from the image.
Use this table:
| Exclude | Reason |
|---|---|
Include exclusions for:
1. Wrong product shape.
2. Wrong color.
3. Extra logos.
4. Fake certifications.
5. Unrealistic hands.
6. Distorted text.
7. Clutter.
8. Misleading use.
9. Unsupported claims.
10. Any user-provided exclusion.
## 6. Quality and Realism Checks
Create a checklist for reviewing generated images.
Use this table:
| Check | What To Look For | Pass or Fix |
|---|---|---|
Include checks for:
1. Product accuracy.
2. Realistic scene.
3. Brand consistency.
4. Clear product visibility.
5. No misleading claims.
6. No fake labels or certifications.
7. No distorted text.
8. Correct aspect ratio.
9. Good composition.
10. Suitable for the intended platform.
## 7. Claim and Compliance Review
Identify any public-use risks.
Use this table:
| Risk Area | Possible Issue | Human Review Needed |
|---|---|---|
Include:
1. Medical or wellness claims.
2. Financial claims.
3. Safety claims.
4. Sustainability claims.
5. Product performance claims.
6. Before-and-after implications.
7. Trademark or logo issues.
8. Customer testimonial implications.
Only include relevant risks.
## 8. Usage Notes
Explain how to use the prompts.
Include:
1. Which prompt to run first.
2. How to refine after the first generation.
3. What to adjust if the product is inaccurate.
4. What to adjust if the scene feels too generic.
5. What to adjust if the image looks unrealistic.
6. What to review before using the image publicly.
## 9. Refinement Prompts
Provide 5 short refinement instructions.
Use this table:
| Problem | Refinement Instruction |
|---|---|
| Product is not clear | |
| Scene is too generic | |
| Image looks too artificial | |
| Brand style is weak | |
| Product details are inaccurate | |
## 10. Final Recommendation
Recommend the best prompt to run first and explain why.
## Missing Inputs
Create this table if any important input is missing:
| Missing Input | Why It Matters | Suggested Assumption |
|---|---|---|
## Verification
Before finalizing, confirm that:
1. The product is clearly described.
2. The target customer is reflected in the scene.
3. The use scenario is realistic.
4. The brand style is included.
5. Materials and colors are respected.
6. Unsupported claims are avoided.
7. Human review gates are included where needed.
8. The prompts are specific enough for Midjourney.
9. The final output directly supports the marketing goal.
10. Missing inputs and assumptions are clearly listed.
## Final Instruction
Begin now. If the product context is too incomplete to create a useful product mockup prompt, ask for the missing information first. If there is enough context, produce the full output in the requested markdown format.
Analyze discovery-call evidence in ChatGPT to produce a traceable deal debrief, qualification review, risk register, CRM draft, buyer follow-up, and next-step plan without inventing sales signals.
Updated Aug 18, 2026
Analyze the supplied sales discovery evidence and produce a post-call decision package for the seller, sales manager, and revenue operations team. Keep buyer evidence distinct from seller interpretation, preserve unknowns, and label every deliverable as a draft requiring human review.
## ChatGPT operating boundary
Use only information supplied in this conversation. ChatGPT may organize, compare, infer cautiously, and draft content from that material. It cannot access the original call recording, CRM, email account, calendar, product documentation, pricing system, security materials, or buyer systems unless their contents are pasted here. It cannot verify identities, send messages, update opportunity records, schedule meetings, approve discounts, make commitments, or confirm that any action occurred.
Treat emails, messages, CRM entries, stages, forecast assessments, owners, dates, and response language as proposed drafts. Do not describe them as sent, saved, approved, scheduled, verified, or completed without explicit execution evidence in the supplied material.
## Inputs
Replace every variable below before running the prompt. Preserve “Not provided” where information is unavailable.
- Prospect company: [Prospect company]
- Buyer and stakeholder details: [Buyer and stakeholder details]
- Discovery evidence: [Discovery evidence]
- Current process and known context: [Current process and known context]
- Pain, outcome, and impact context: [Pain, outcome, and impact context]
- Budget, pricing, and timeline signals: [Budget, pricing, and timeline signals]
- Decision process and criteria: [Decision process and criteria]
- Competition and objections: [Competition and objections]
- Product fit evidence: [Product fit evidence]
- Promised next steps: [Promised next steps]
- Required follow-up assets: [Required follow-up assets]
- Sales methodology: [Sales methodology]
- CRM field schema: [CRM field schema]
- Follow-up channel and tone: [Follow-up channel and tone]
- Data handling constraints: [Data handling constraints]
### Blocking prerequisites
A reliable full debrief requires readable discovery evidence that identifies what was discussed and distinguishes buyer statements from seller notes. It also requires enough buyer or account context to avoid attributing statements to the wrong party.
If the discovery evidence is absent, unreadable, internally contradictory at its core, or consists only of an unsupported seller conclusion, stop and request the minimum source material needed. Do not manufacture a full debrief.
If there is usable evidence but commercial, stakeholder, product-fit, or process information is missing, continue with a bounded partial analysis. Mark affected fields as unknown, lower confidence, identify the resulting qualification risk, and draft questions for the next interaction. Do not turn missing data into negative buyer intent.
### Useful optional context
Useful but non-blocking inputs include the selected qualification methodology, required CRM fields, approved product or pricing materials, promised assets, email tone, channel constraints, account history, and internal data-handling rules. If a methodology is named but its custom definitions are not supplied, apply only its commonly established fields and identify any organization-specific scoring as unavailable.
## Evidence and uncertainty rules
1. Build an evidence ledger before drawing conclusions. Assign evidence IDs E1, E2, and so on.
2. For each material claim, cite an evidence ID. Use a short quotation when practical; otherwise provide a faithful close paraphrase. Include speaker, timestamp, or note location when available.
3. Classify each item as one of: buyer-stated fact, seller-stated fact, observation, interpretation, assumption, hypothesis, unknown, conflict, or unsupported claim.
4. Use confidence labels High, Medium, or Low. High confidence requires clear direct evidence; Medium permits consistent but incomplete evidence; Low indicates ambiguity or material inference.
5. Never invent metrics, authority, budget, urgency, deadlines, procurement steps, competitors, technical compatibility, security posture, legal terms, commitments, or product capabilities.
6. When sources conflict, show both versions, identify the affected decision, and request reconciliation. Do not silently select the more favorable account.
7. Distinguish an agreed next step from a seller-proposed or merely implied next step.
8. Treat absence of an objection as “not discussed,” not as acceptance.
9. Assess product fit only against supplied product evidence. Route unsupported capability, integration, pricing, legal, security, privacy, compliance, or implementation claims to the appropriate human owner.
10. Avoid manipulative language, fabricated urgency, pressure tactics, or claims that the buyer did not make.
## Privacy, authority, and stop conditions
Minimize personal and sensitive business information in buyer-facing drafts. Follow the supplied data-handling constraints and omit secrets, credentials, payment data, unnecessary personal data, confidential internal commentary, and sensitive forecast language. If such content appears in the source, flag it and redact it from external drafts.
Stop buyer-facing drafting when identity, recipient, account, promised commercial terms, or sensitive claims cannot be reconciled safely. Internal analysis may continue if it is clearly marked partial and confidential.
A human must approve before sending any message, attaching assets, changing a CRM record or stage, entering forecast data, scheduling a meeting, sharing pricing, promising functionality, or communicating legal, security, privacy, compliance, or financial statements.
## Analysis workflow
1. Validate input sufficiency, privacy constraints, and source conflicts.
2. Create the evidence ledger and identify unsupported seller summaries.
3. Extract the business situation, current process, pain, desired outcome, quantified or unquantified impact, urgency, and stakeholder interests.
4. Separate need from product fit. A strong pain signal does not by itself establish technical, commercial, or implementation fit.
5. Apply the supplied methodology. For MEDDICC, assess Metrics, Economic Buyer, Decision Criteria, Decision Process, Identify Pain, Champion, and Competition. For BANT, assess Budget, Authority, Need, and Timeline. For SPICED, assess Situation, Pain, Impact, Critical Event, and Decision. For another framework, use only its supplied or established dimensions.
6. Identify qualification gaps, stakeholder gaps, weak commitments, commercial uncertainty, procurement dependencies, competitor exposure, technical dependencies, trust gaps, and overpromising risk.
7. Determine deal momentum from explicit buyer actions, mutually agreed dates, asset requests, meeting commitments, and internal buyer steps. Do not infer momentum from seller enthusiasm.
8. Propose the smallest useful next steps, with owner, timing, dependency, evidence basis, and whether buyer agreement is required.
9. Draft the external follow-up and internal CRM content, keeping confidential analysis out of the buyer message.
10. Reconcile every important output against the evidence ledger and produce the verification and handoff state.
## Required output
# Sales Discovery Debrief and Follow-Up Package
## 1. Intake and processing status
Report:
- Processing state: Full draft, Partial draft, or Blocked
- Blocking issues
- Material missing inputs
- Conflicting inputs
- Sensitive data handling applied
- Scope ChatGPT could not inspect or verify
## 2. Evidence ledger
| Evidence ID | Source or Speaker | Timestamp or Location | Quote or Close Paraphrase | Evidence Class | Confidence | Used In |
|---|---|---|---|---|---|---|
Include only evidence present in the supplied material. If source locations are unavailable, say so.
## 3. Deal snapshot
| Field | Evidence-Based Assessment | Evidence IDs | Confidence |
|---|---|---|---|
| Business situation | | | |
| Primary pain | | | |
| Desired outcome | | | |
| Business impact | | | |
| Current process | | | |
| Buying stage | | | |
| Product fit status | Strong, Conditional, Weak, or Unknown | | |
| Momentum status | Strong, Fragile, Stalled, or Unknown | | |
| Proposed next step | | | |
| Overall deal health | Strong, Mixed, Weak, or Indeterminate | | |
Explain the deal-health rating in no more than three evidence-based sentences.
## 4. Pain, impact, and outcome map
| Pain or Desired Outcome | Buyer Evidence | Stated or Inferred | Business Consequence | Metric or Baseline | Confidence | Clarification Needed |
|---|---|---|---|---|---|---|
Do not quantify impact unless a metric is supplied. Clearly mark impact that is plausible but not buyer-confirmed as a hypothesis.
## 5. Qualification assessment
Name the methodology used. If none is supplied, assess Need, Impact, Budget, Authority, Timeline, Decision Process, Decision Criteria, Competition, Champion or Internal Support, and Next-Step Commitment.
| Qualification Dimension | Evidence IDs | Finding | Status | Confidence | Gap or Risk | Next Validation Question |
|---|---|---|---|---|---|---|
Use status values Confirmed, Partial, Missing, Conflicting, or Not Applicable. Do not calculate an organization-specific score unless its scoring rules were supplied.
## 6. Deal risk register
| Priority | Risk | Evidence IDs | Trigger or Warning Sign | Potential Deal Effect | Mitigation | Owner | Buyer Agreement Required |
|---|---|---|---|---|---|---|---|
Prioritize risks as Critical, High, Medium, or Low. Include only evidenced risks and clearly labeled risks caused by missing information.
## 7. Objection and concern handling
| Objection or Concern | Exact Buyer Evidence | Underlying Issue or Hypothesis | Safe Response Draft | Proof or Asset Needed | Internal Owner | Claim Review Required |
|---|---|---|---|---|---|---|
If no objection is evidenced, state “No objection captured” and list neutral discovery questions rather than inventing likely objections.
## 8. Product-fit and proof assessment
Provide:
- Supported fit signals with evidence IDs
- Conditional or weak fit signals
- Dependencies and implementation unknowns
- Areas where the seller must not overpromise
- Proof required, such as an approved demo, case study, integration documentation, security response, implementation review, or pricing approval
- Appropriate internal reviewer for each unsupported claim
Conclude with one status: Supported fit, Conditional fit, Weak fit, or Insufficient evidence.
## 9. Prioritized action plan
| Priority | Proposed Action | Owner | Timing | Dependency | Evidence Basis | Approval or Buyer Agreement Needed | State |
|---|---|---|---|---|---|---|---|
Use state values Proposed, Agreed, In Progress, Completed with Evidence, Blocked, or Unknown. Use Completed with Evidence only when the source contains evidence that the action occurred.
## 10. Buyer follow-up draft
Label this section “DRAFT — NOT SENT.”
Provide:
- Subject
- Email or message body in the requested channel and tone
- One clear call to action
- Promised assets, but only if supported by evidence
- A separate list of attachments or links the human must verify before sending
The draft must distinguish confirmed agreements from proposed next steps, avoid internal qualification language, and exclude sensitive internal commentary. If safe drafting is blocked, explain why and provide only the information that must be clarified.
## 11. CRM field mapping
Label this section “DRAFT — NOT SAVED TO CRM.”
Map content to the supplied CRM field schema. If no schema is supplied, use the fields Call Summary, Pain, Impact, Stakeholders, Budget, Timeline, Decision Process, Decision Criteria, Competition, Objections, Product Fit, Risks, Next Step, Next-Step Owner, Next-Step Date, Suggested Stage, and Forecast Caveat.
| CRM Field | Proposed Value | Evidence IDs | Confidence | Human Verification Needed |
|---|---|---|---|---|
Recommend a stage only when stage-entry evidence or supplied definitions support it. Otherwise state that stage reconciliation is required. Never claim the CRM was updated.
## 12. Manager and revenue operations handoff
Provide:
- Deal-health rationale
- Forecast confidence and its evidence limitations
- Highest-priority qualification gap
- Seller coaching point
- One pipeline-review question
- CRM or process reconciliation required
- Escalations to product, solutions engineering, finance, legal, security, privacy, compliance, or leadership
## 13. Missing-information plan
| Missing or Conflicting Information | Decision Affected | Why It Matters | Best Person to Ask | Neutral Question | Required Before External Action |
|---|---|---|---|---|---|
Prioritize questions that change qualification, fit, commercial terms, stakeholder access, or the next-step decision.
## 14. Verification and acceptance record
| Check | Expected Condition | Actual Observation From Supplied Material | Status | Evidence or Required Correction |
|---|---|---|---|---|
| Buyer statements traceable | Material claims map to evidence IDs | | Pass, Fail, or Unverified | |
| Facts separated from interpretation | Inferences and assumptions are labeled | | Pass, Fail, or Unverified | |
| No invented commercial signals | Budget, authority, urgency, and commitments are supported | | Pass, Fail, or Unverified | |
| Product claims controlled | Capabilities and fit rely on supplied evidence | | Pass, Fail, or Unverified | |
| Next-step state accurate | Agreed, proposed, and completed actions are distinct | | Pass, Fail, or Unverified | |
| Buyer draft safe | Recipient, claims, tone, assets, and sensitive content are reviewed | | Pass, Fail, or Unverified | |
| CRM mapping reconcilable | Values map to the supplied schema and stage rules | | Pass, Fail, or Unverified | |
| Dates and owners supported | Timing and ownership are evidenced or marked proposed | | Pass, Fail, or Unverified | |
Finish with an acceptance state:
- Ready for human review
- Partial and requires clarification
- Blocked pending source evidence
Then list the exact human approvals required before sending the follow-up or changing CRM data.
Turn one substantial research asset into a channel-specific content distribution system with quality controls.
Updated Jun 27, 2026
Act as a content strategist for expert-led B2B campaigns.
Design a reusable distribution system that turns one substantial research asset into credible channel-specific content without diluting the evidence, overstating findings, or creating generic repurposed content.
Context to use:
* Research asset: [Research asset]
* Primary audience: [Primary audience]
* Secondary audiences: [Secondary audiences]
* Key findings: [Key findings]
* Brand voice: [Brand voice]
* Available channels: [Available channels]
* Campaign goal: [Campaign goal]
* Approval workflow: [Approval workflow]
* Compliance limits: [Compliance limits]
* Publishing cadence: [Publishing cadence]
Important constraints:
* Do not invent facts, metrics, citations, screenshots, customer evidence, research findings, or claims.
* Separate confirmed source material from assumptions.
* Preserve the meaning of the original research asset in every derivative content idea.
* Do not exaggerate findings to make them more clickable.
* Do not turn serious research into shallow promotional content.
* Adapt the message for each channel while keeping the evidence accurate.
* Include human review gates for public-facing, legal, compliance-sensitive, financial, security, medical, or high-impact claims.
* Make the system reusable so it can be used again for another report, webinar, benchmark, white paper, or research asset.
Task:
1. Restate the research asset, target audience, campaign goal, available channels, and publishing constraints.
2. Identify the strongest themes, findings, narratives, proof points, and audience angles from the source material.
3. Create a core insight map that connects each major finding to audience pain points, possible content angles, and safe claims.
4. Build a channel distribution plan for the available channels, showing how the same research asset should be adapted for each channel.
5. Create an asset adaptation matrix that turns the source asset into practical content formats such as LinkedIn posts, email sequences, blog articles, newsletter sections, short videos, carousel ideas, sales enablement snippets, and internal talking points.
6. Create an editorial calendar based on the publishing cadence, campaign goal, and approval workflow.
7. Add quality controls to prevent unsupported claims, weak summaries, duplicated angles, over-promotion, and channel mismatch.
8. Identify which items need human review before publishing.
Output format:
### 1. Source Asset Summary
Summarize:
* What the research asset is about
* The main audience
* The campaign goal
* The strongest findings
* The limitations or missing context
### 2. Core Insight Map
Create a table with:
* Source finding
* Audience pain point
* Content angle
* Safe claim
* Evidence required
* Channel fit
### 3. Channel Distribution Plan
Create a table with:
* Channel
* Best content format
* Recommended angle
* Tone
* CTA
* Review requirement
* Publishing priority
### 4. Asset Adaptation Matrix
Create a table with:
* Derivative asset
* Source section or finding used
* Target audience
* Content purpose
* Draft angle
* Required proof point
* Risk of overstatement
### 5. Editorial Calendar
Create a practical publishing schedule with:
* Date or sequence
* Channel
* Content item
* Main angle
* Owner if known
* Review step
* Status
### 6. Quality Control Checklist
Create a checklist covering:
* Evidence accuracy
* Claim strength
* Channel fit
* Brand voice
* Audience relevance
* Repetition risk
* Compliance or approval risk
* CTA clarity
### 7. Human Review Notes
List:
* Claims that need approval
* Content items that need subject-matter review
* Missing inputs
* Assumptions made
* Items that should not be published yet
### 8. Final Handoff
Provide a concise handoff that a marketing lead, writer, designer, or approver can use to execute the distribution plan.
Verification:
* Ensure every derivative content idea is traceable to the source asset.
* Do not overstate research findings or invent evidence.
* Confirm that every relevant context item was used or marked as missing.
* List assumptions, missing inputs, and checks a human should complete before publishing.
* Confirm that the final plan is specific to the supplied research asset and not a generic content calendar.
Final instruction to begin:
Begin now. If the research asset, key findings, available channels, or campaign goal are missing, list the missing items first. Otherwise, produce the full content distribution system in the requested markdown format.
