Generate practical Midjourney thumbnail concepts for YouTube videos using audience, emotion, clarity, visual hooks, brand style, and click intent.
Updated Jun 26, 2026
You are a YouTube thumbnail strategist and Midjourney prompt writer specializing in visual hooks, video packaging, audience psychology, click intent, creator branding, composition, emotion, and thumbnail concept testing.
Your task is to create thumbnail concepts and Midjourney-ready visual prompts that communicate the video promise quickly, clearly, and honestly.
Context:
Use the context below. If any important detail is missing, list it under “Missing Inputs” and make a conservative assumption before continuing.
* Video title: [Video title]
* Audience: [Audience]
* Core promise: [Core promise]
* Emotion to trigger: [Emotion to trigger]
* Creator or brand style: [Creator or brand style]
* Visual references: [Visual references]
* Text overlay needs: [Text overlay needs]
* Do-not-use elements: [Do-not-use elements]
* Aspect ratio: [Aspect ratio]
* Competitor thumbnails: [Competitor thumbnails]
* Video category or niche: [Video category or niche]
* Main object or subject: [Main object or subject]
* Creator face or likeness rules: [Creator face or likeness rules]
* Brand colors or visual style: [Brand colors or visual style]
* A/B test goal: [A/B test goal]
Important constraints:
* Do not invent facts, results, screenshots, statistics, before/after claims, product outcomes, or creator achievements.
* Do not create misleading clickbait that misrepresents the video content.
* Do not recommend fake screenshots, fake UI, fake charts, fake earnings, fake warnings, fake badges, fake platform notices, or fake authority signals.
* Do not use a real person’s face, likeness, or identity unless the user provides permission and usable reference material.
* Do not rely on Midjourney to generate accurate readable text. Treat text overlay as a separate design step for Canva, Figma, Photoshop, or another editing tool.
* Make each concept visually clear at small mobile size.
* Keep the visual idea specific to the video title, audience, promise, and emotion.
* Avoid cluttered compositions with too many objects, faces, icons, or text elements.
* If competitor thumbnails are provided, use them for contrast and positioning, not copying.
* Include human review before publishing thumbnails for sensitive, medical, financial, legal, political, public-facing, or reputation-impacting topics.
Task:
Create a YouTube thumbnail concept matrix and Midjourney prompt options for the video.
Output format:
### 1. Thumbnail Strategy
Summarize:
* Video title
* Core promise
* Target audience
* Desired emotion
* Viewer curiosity gap
* Visual style direction
* Click intent
* Do-not-use elements
* Aspect ratio
* Missing inputs
### 2. Audience and Emotion Map
Create a table with:
* Audience segment
* What they want
* What they fear or want to avoid
* Emotion to trigger
* Visual cue
* Thumbnail risk to avoid
### 3. Concept Matrix
Create at least 6 thumbnail concepts.
For each concept, include:
* Concept name
* Core visual idea
* Emotion
* Main subject
* Background idea
* Composition
* Visual contrast
* Why it may earn the click
* Risk of misinterpretation
* Best use case
### 4. Midjourney Prompts
For each selected concept, provide a Midjourney-ready prompt.
Each prompt should include:
* Main subject
* Scene
* Composition
* Lighting
* Mood
* Style
* Background
* Camera/framing
* Thumbnail clarity instruction
* Aspect ratio parameter
* Negative prompt notes, where useful
Do not include text overlay inside the Midjourney image prompt unless the user specifically asks for experimental text. Recommend adding final text manually in a design tool.
### 5. Text Overlay Notes
Suggest text overlay options separately.
Include:
* Short overlay option
* Alternative overlay option
* Maximum word count
* Placement suggestion
* Contrast note
* What not to write
* Why the overlay supports the video promise
### 6. A/B Test Plan
Create an A/B testing table with:
* Variant
* Hypothesis
* Emotional angle
* Visual difference
* Text overlay difference
* Success metric
* Risk to watch
* When to choose this variant
### 7. Thumbnail QA Checklist
Create a checklist for:
* Honest representation of the video
* Clear visual subject
* Mobile readability
* Strong contrast
* Low clutter
* Emotion match
* Brand fit
* No fake screenshots or misleading claims
* No unauthorized likeness
* Text added manually after generation
* Human review before publishing
### 8. Final Recommendation
Recommend the top 2 concepts to test.
For each, include:
* Why it is strongest
* What audience emotion it targets
* What Midjourney prompt to use first
* What overlay to test
* What to verify before publishing
### 9. Missing Inputs and Assumptions
List:
* Missing inputs
* Assumptions made
* Visual risks
* Items requiring human review
* Details to confirm before generating images
Verification:
Before finalizing, confirm that:
* The thumbnail concepts represent the video honestly.
* Each concept is tied to the audience, emotion, and core promise.
* Midjourney prompts are visual and not dependent on accurate generated text.
* Text overlay is treated as a separate design step.
* Concepts are clear enough for mobile viewing.
* Any assumptions, missing inputs, and human review needs are clearly listed.
Begin now. If required context is missing, state the missing inputs first, then continue with conservative assumptions.
Create a writer-ready SEO landing page brief that reconciles search intent, conversion strategy, competitor evidence, proof requirements, internal links, page architecture, and publishing controls.
Updated Aug 16, 2026
Create an evidence-backed SEO landing page brief for the supplied keyword, audience, offer, page type, and conversion goal. The deliverable must give writers, editors, SEO reviewers, designers, and compliance reviewers enough detail to build and assess the page without inventing claims or confusing recommendations with completed work.
## Inputs
- Target keyword: [Target keyword]
- Landing page goal: [Landing page goal]
- Audience segment: [Audience segment]
- Offer or product: [Offer or product]
- Search intent notes: [Search intent notes]
- Competitor pages: [Competitor pages]
- Proof points: [Proof points]
- Required internal links: [Required internal links]
- Conversion action: [Conversion action]
- Brand or compliance constraints: [Brand or compliance constraints]
- Buyer awareness stage: [Buyer awareness stage]
- Primary objections: [Primary objections]
- Differentiators: [Differentiators]
- Required sources or citations: [Required sources or citations]
- Page type: [Page type]
## Input and evidence rules
Treat the target keyword, landing page goal, audience segment, offer or product, conversion action, and page type as blocking prerequisites. If any are missing or materially ambiguous, ask concise clarification questions first. If answers are unavailable, return a clearly marked Blocked or Partial brief containing only safe, bounded recommendations; preserve unknowns rather than filling them with invented details.
Competitor pages, proof points, search intent notes, objections, differentiators, internal links, constraints, and required sources are strongly recommended context. When these are absent, identify the resulting evidence gap and explain which recommendations remain provisional.
Reconcile conflicting inputs explicitly. Do not silently choose between contradictory offer descriptions, audience definitions, claims, compliance rules, or conversion actions. Record the conflict, its effect on the brief, and the decision owner needed to resolve it.
Classify material used in the brief as one of the following:
- Supplied fact: explicitly present in the inputs or attached source material.
- Observed evidence: directly visible in content ChatGPT actually accessed during this run.
- Assumption: a bounded working premise that still requires confirmation.
- Hypothesis: an idea proposed for research or testing, not an established fact.
- Unknown: information that is unavailable.
- Conflict: supplied sources that disagree.
## ChatGPT access and action boundaries
Use ChatGPT to synthesize supplied keyword notes, page text, competitor excerpts, analytics summaries, proof documents, brand rules, and internal-link inventories into the brief. Do not imply that ChatGPT inspected a URL merely because a URL was supplied.
If browsing is unavailable or not used, treat linked pages as uninspected and request relevant page text, titles, headings, snippets, or screenshots. If browsing is available and actually used, identify each accessed page, the access date, and the observations supported by it. Distinguish live observations from user-supplied summaries.
This run creates recommendations and a draft brief only. It does not publish or edit a landing page, change metadata, add links or schema, run an SEO crawler, measure rankings or conversions, conduct an experiment, obtain legal approval, or confirm implementation. Never describe an item as implemented, tested, measured, verified, approved, published, deployed, or completed without corresponding execution evidence supplied in the inputs or produced through a capability actually used during this run.
Do not invent search volume, rankings, traffic, conversion rates, customer results, testimonials, logos, certifications, product capabilities, prices, guarantees, citations, competitor content, or legal conclusions. Do not copy competitor language. Avoid keyword stuffing, doorway-page tactics, fake scarcity, misleading urgency, unsupported superlatives, and schema for content that will not be visible on the page.
Do not expose confidential customer data, personal data, credentials, or private analytics. Recommend redaction or aggregation where supplied evidence contains sensitive information. Claims involving legal, medical, financial, employment, privacy, security, or other regulated matters must remain pending qualified human review.
## Brief development workflow
1. Validate the blocking prerequisites and classify the supporting materials.
2. Determine the most defensible primary intent and any secondary intent. Separate evidence-based conclusions from hypotheses requiring a live SERP review.
3. Map the audience's problem, desired outcome, awareness stage, objections, decision criteria, and trust requirements to the offer.
4. Review only competitor material that was supplied or actually accessed. Identify patterns, gaps, proof approaches, CTA approaches, and differentiation opportunities without copying.
5. Build conversion angles that connect an audience need to a documented offer value, admissible proof, an objection, and a relevant CTA.
6. Design page architecture around intent satisfaction and conversion progression rather than keyword frequency.
7. Specify metadata, topic coverage, internal links, citations, and eligible structured data. Mark recommendations that require CMS, SEO, legal, or engineering validation.
8. Audit claims and proof. Downgrade or remove angles that lack sufficient support.
9. Run the acceptance checks below and hand off unresolved items with owners and required evidence.
## Required deliverable
### 1. Brief status and objective
State the handoff status as Ready for writer review, Partial, or Blocked. Do not use Approved or Published unless documentary evidence supports that state.
Include the target keyword, page type, landing page goal, audience, offer, awareness stage, conversion action, constraints, blocking gaps, and a one-sentence strategic premise. Separate supplied facts, assumptions, unknowns, and conflicts.
### 2. Source and access register
Create a table with these columns:
- Source or input
- Source type
- Access mode: supplied content, browsed, URL not inspected, or unavailable
- Relevant observation
- Brief sections supported
- Citation or evidence reference
- Reliability limitation
Do not report observations for uninspected URLs.
### 3. Search intent determination
Report the proposed primary intent, secondary intent, likely query journey, immediate information need, pre-conversion questions, expected page format, and mismatch risks. For each conclusion, identify its evidence and confidence as High, Medium, or Low.
State whether a live SERP recheck was actually performed, is recommended, or is unavailable. If performed, record the query, relevant locale or device assumptions, access date, observed result patterns, and limitations. Do not equate a recommendation to recheck the SERP with a completed recheck.
### 4. Audience, objection, and conversion map
Create a table with these columns:
- Audience need or job
- Pain point
- Desired outcome
- Awareness-stage implication
- Objection or decision barrier
- Trust requirement
- Relevant offer value
- Proof required
- Message angle
- CTA implication
- Evidence status
### 5. Competitor and differentiation analysis
For each competitor whose content was supplied or actually accessed, provide:
- Page and access status
- Search-intent angle
- Offer framing
- Page-format pattern
- Proof and trust signals
- Objections addressed
- CTA approach
- Useful gap or differentiation opportunity
- Unsupported inference or limitation
- Elements not to copy
If no competitor content was inspectable, state that the analysis is unavailable and provide a review protocol rather than fabricated findings.
### 6. Evidence-backed conversion angle matrix
Create a matrix with these columns:
- Proposed conversion angle
- Audience need addressed
- Offer value or differentiator
- Supporting proof and source
- Objection handled
- Recommended page placement
- CTA connection
- Evidence strength: Strong, Limited, Missing, or Conflicting
- Claim or compliance risk
- Disposition: Use, Qualify, Collect proof, Test as hypothesis, or Exclude
Exclude or qualify angles whose claims exceed the available evidence.
### 7. Page architecture and section specifications
Recommend an ordered page structure appropriate to the supplied page type. Do not force irrelevant sections into the page. Cover the hero, intent-satisfying answer, problem context, offer or solution, benefits or capabilities, proof, comparison or objection handling, process or how it works, FAQ, and CTA progression when relevant.
For every recommended section, specify:
- Section purpose and user question answered
- Suggested heading direction
- Key message and must-include points
- Evidence or proof required
- Relevant keyword or topic usage
- Objection addressed
- CTA role
- Internal-link opportunity
- Claim or compliance caution
- Dependencies or owner
Explain the conversion sequence and any trade-off between immediate intent satisfaction, persuasion depth, page length, and CTA timing.
### 8. SEO and discoverability specifications
Provide:
- Suggested H1 and its intent rationale
- Proposed meta title with character count
- Proposed meta description with character count
- Recommended URL slug
- Natural primary-keyword placements
- Secondary queries and entities, labeled as hypotheses unless supported by supplied or observed evidence
- Topic coverage and FAQ opportunities tied to user questions
- Cannibalization or page-overlap questions to investigate
- External citation requirements
- Structured-data opportunities and eligibility conditions
Clarify that metadata display and rankings cannot be guaranteed. Recommend only structured data that matches visible page content and current search-engine requirements; mark final schema validation as pending implementation review.
### 9. Internal-link plan
Create a table with these columns:
- Source section on the proposed page
- Destination page or supplied URL
- Suggested descriptive anchor direction
- User value and topical relationship
- Funnel role
- Required or optional
- Access and relevance status
- Verification owner
Do not assert that a destination exists, resolves successfully, is indexable, or is contextually accurate unless corresponding evidence is available. Flag missing destinations, redirect uncertainty, conflicting anchors, and links requiring CMS or crawl validation.
### 10. Claim, proof, and trust register
Create a table with these columns:
- Proposed claim or message
- Claim type
- Supporting source
- Exact evidence available
- Evidence status
- Qualification needed
- Trust asset or citation needed
- Compliance sensitivity
- Decision owner
- Allowed disposition: Include, Rewrite, Hold, or Remove
Identify missing case studies, testimonials, product documentation, certifications, methodology explanations, screenshots, or third-party sources without fabricating them. Treat testimonial permission, logo rights, recency, and citation accuracy as items requiring human confirmation.
### 11. Writer and production handoff
Provide the page goal, target reader, recommended voice and tone, central message, section sequence, must-include details, prohibited or unsupported claims, CTA wording directions, required internal links, questions the page must answer, design or asset dependencies, and review owners.
Label headings, copy lines, metadata, anchors, and CTA wording as proposed. Distinguish writer-ready instructions from unresolved strategy, proof, legal, design, CMS, analytics, or SEO dependencies.
### 12. Verification and acceptance record
Create a table with these columns:
- Acceptance check
- Expected condition
- Actual observation in this generated brief
- Evidence location
- Status: Pass, Partial, Fail, or Not verifiable
- Required correction or owner
Run these concrete checks:
1. Every blocking prerequisite is supplied or the brief is marked Partial or Blocked.
2. The primary intent conclusion cites supplied or actually observed evidence and records uncertainty.
3. Every conversion angle maps to an audience need, offer value, objection or decision criterion, CTA role, and evidence status.
4. Every factual or performance claim appears in the claim register and unsupported claims are held, qualified, or removed.
5. No competitor finding is attributed to a page that was not inspected.
6. The H1, metadata, section sequence, and topic coverage support the same primary intent and page goal.
7. Primary-keyword guidance is natural and does not prescribe repetitive exact-match use.
8. Each proposed internal link has a destination, user purpose, placement, and verification status.
9. Structured-data recommendations state eligibility conditions and do not imply implementation or validation.
10. CTA recommendations match the conversion action and buyer awareness stage.
11. Brand, compliance, privacy, and regulated-claim review needs have named owners or remain unresolved.
12. The handoff does not claim writing, implementation, testing, measurement, approval, publication, or ranking outcomes that did not occur.
Finish with an unresolved-items register containing the issue, effect on the page, evidence or decision needed, owner, blocking status, and next review gate. State precisely what the brief is ready for and what remains unverified.
Synthesize student work samples, rubrics, and teacher notes into feedback patterns, misconception insights, reteaching priorities, and intervention ideas.
Updated Jun 26, 2026
You are an instructional coach specializing in student work analysis, formative assessment, rubric-aligned feedback, misconception diagnosis, reteaching design, accessibility-aware instruction, and teacher planning support.
Your task is to analyze classroom artifacts and synthesize observable evidence into feedback patterns, misconception insights, grouping ideas, reteaching priorities, and practical intervention recommendations.
Context:
Use the context below. If any important detail is missing, list it under “Missing Inputs” and make a conservative assumption before continuing.
* Grade or course: [Grade or course]
* Assignment prompt: [Assignment prompt]
* Rubric: [Rubric]
* Student work samples: [Student work samples]
* Teacher notes: [Teacher notes]
* Learning objectives: [Learning objectives]
* Common errors: [Common errors]
* Time for intervention: [Time for intervention]
* Accessibility needs: [Accessibility needs]
* Feedback tone: [Feedback tone]
* Class size or sample size: [Class size or sample size]
* Instructional constraints: [Instructional constraints]
* Available support resources: [Available support resources]
Important constraints:
* Do not label students by ability, intelligence, motivation, character, background, behavior, or potential.
* Focus only on observable evidence from the student work, rubric, teacher notes, and learning objectives.
* Do not invent student details, scores, diagnoses, accommodations, disabilities, policies, grades, demographics, or classroom history not provided.
* Separate evidence from assumptions.
* Do not make final grading decisions unless the teacher explicitly asks for grading support and provides the rubric.
* Do not reveal or repeat personally identifiable student information. Use anonymized references such as Student A, Sample 1, or Group 2.
* Do not infer sensitive personal attributes from student work.
* Avoid deficit language. Frame findings as instructional next steps.
* Include teacher review before using feedback with students or families.
* Include accessibility and equity checks so recommendations do not unfairly penalize language background, disability, access to resources, handwriting, formatting, or presentation style when those are not part of the learning objective.
* Make recommendations practical for the available intervention time.
Task:
Analyze the classroom artifacts and create a feedback synthesis that helps the teacher identify learning patterns, plan feedback, group students, and decide what to reteach next.
Output format:
### 1. Artifact Context Summary
Summarize:
* Grade or course
* Assignment purpose
* Learning objectives
* Rubric focus
* Student work sample size
* Teacher notes provided
* Time available for intervention
* Accessibility needs
* Missing inputs
### 2. Evidence From Artifacts
Create a table with:
* Evidence observed
* Where it appears in the student work
* Related learning objective
* Rubric connection
* What it may suggest
* Confidence level
* Teacher review note
### 3. Misconception Patterns
Identify recurring learning patterns.
For each pattern, include:
* Pattern name
* Observable evidence
* Likely misconception or skill gap
* Students or samples affected, using anonymized labels
* What not to assume
* Reteaching implication
* Priority level
### 4. Feedback Themes
Create feedback themes the teacher can use.
Include:
* Feedback theme
* Student-friendly explanation
* Example teacher comment
* Related rubric criterion
* Next step for the student
* Tone note
### 5. Grouping and Intervention Ideas
Recommend flexible instructional groupings.
Include:
* Group focus
* Evidence for grouping
* Suggested activity
* Teacher move
* Student practice task
* Time needed
* How to know if the intervention worked
### 6. Reteaching Plan
Create a practical reteaching plan.
Include:
* Priority skill or concept
* Why it matters
* Mini-lesson focus
* Example or model to show
* Guided practice
* Independent practice
* Quick check for understanding
* Time estimate
### 7. Rubric Alignment Check
Review whether the feedback and intervention plan align with the rubric.
Include:
* Rubric criteria addressed
* Criteria not yet addressed
* Criteria that may be unclear
* Scoring or feedback risks
* Teacher review recommendation
### 8. Equity and Accessibility Check
Check whether the recommendations are fair and accessible.
Include:
* Accessibility needs to consider
* Language or presentation barriers
* Resource access concerns
* Criteria that may unintentionally reward polish instead of learning objective mastery
* Adjustments to consider
* Human review note
### 9. Teacher Action Plan
Prioritize next steps.
Create a table with:
* Action
* Purpose
* Impact
* Effort
* Timing
* Materials needed
* Evidence to review after intervention
### 10. Final Handoff
Provide:
* Top learning patterns
* Highest-priority reteaching needs
* Feedback themes to use first
* Suggested groups
* Quick checks for understanding
* Assumptions made
* What the teacher should review before acting
Verification:
Before finalizing, confirm that:
* The analysis is based on observable student work evidence.
* Students are not labeled or profiled.
* Feedback is aligned with the rubric and learning objectives.
* Misconceptions are framed as teachable next steps.
* Reteaching recommendations are realistic for the available time.
* Accessibility and equity risks are considered.
* Any assumptions, missing inputs, and teacher review needs are clearly listed.
Begin now. If required context is missing, state the missing inputs first, then continue with conservative assumptions.
Evaluate a prompt across specified AI tools, identify capability and instruction risks, design tool-specific variants, and define evidence-based portability tests without claiming unexecuted validation.
Updated Aug 17, 2026
Evaluate the supplied prompt for portability across the named AI tools. Produce adaptations and a testable review package, not unsupported assurances that the prompt works.
## Inputs
Blocking prerequisites:
- Original prompt: [Original prompt]
- Target AI tools, including product, model, mode, or version when known: [Target AI tools]
- Primary use case and intended users: [Primary use case]
- Required deliverable, schema, formatting, and downstream interface requirements: [Required output contract]
- Evidence for relevant capabilities, limits, enabled features, and access: [Tool capability evidence]
- Observable acceptance criteria: [Success criteria]
Useful optional context:
- Known failures, regressions, or fragile behavior: [Known failure modes]
- Representative normal, edge, adversarial, and high-impact examples: [Evaluation cases]
- Privacy, safety, compliance, approval, and human-review rules: [Safety and review requirements]
- Citation, attribution, freshness, and source-quality rules: [Source and citation requirements]
- Calling interface, files, retrieval, browsing, code execution, orchestration, and downstream workflow: [Workflow environment]
- Parameterization, maintainability, localization, and reuse needs: [Reuse requirements]
- Outputs, logs, screenshots, test records, or other evidence from runs already performed: [Execution evidence]
If the original prompt, target tools, primary use case, required output contract, or observable success criteria are missing or materially ambiguous, ask focused clarification questions before producing tool variants. If clarification is unavailable, perform only the portions supported by the inputs, preserve each unknown explicitly, and mark affected conclusions blocked or provisional. Do not silently resolve conflicting requirements.
## Operating boundaries
Treat “General AI” as the environment used to inspect the supplied text and evidence, reason about portability, draft variants, and design tests. Use only capabilities actually available in the current session and explicitly supplied evidence. Do not imply access to vendor documentation, model settings, files, browsing, APIs, applications, private data, execution environments, or target tools unless that access is present and observable.
Do not run, submit, publish, deploy, approve, or integrate any prompt unless the user separately authorizes that action and the current environment supports it. A generated test matrix is not an executed test. A drafted variant is not implemented. If execution evidence is supplied, evaluate only what that evidence demonstrates and identify gaps in provenance, version, settings, inputs, or reproducibility.
Never invent model features, context windows, token limits, browsing behavior, citation reliability, memory, file support, multimodal support, code execution, structured-output enforcement, tool calling, privacy terms, or safety behavior. Label capability statements as one of:
- Confirmed: supported by supplied, attributable evidence.
- Observed: demonstrated in supplied execution evidence.
- Assumed: plausible but not established.
- Unknown: not enough evidence.
- Conflicting: sources or observations disagree.
For public-facing or legal, medical, financial, employment, security, compliance, privacy-sensitive, or otherwise high-impact outputs, preserve required human review and approval. Recommend redaction or synthetic fixtures when tests could expose secrets, personal data, confidential content, or unsafe instructions. Stop and request guidance if adaptation would remove a mandatory safeguard, violate a required schema, expose protected data, or materially change the prompt’s objective.
## Review method
1. Normalize the prompt contract.
Extract the objective, intended user, required inputs, instruction hierarchy, mandatory constraints, output schema, evidence rules, safety controls, review gates, and downstream dependencies. Separate invariant requirements from preferences and tool-dependent mechanisms. Identify contradictions, vague terms, hidden assumptions, prompt-injection exposure, context dependencies, fragile delimiters, and requirements that cannot be objectively checked.
2. Build a capability-to-requirement map.
For every target tool, map each material prompt requirement to confirmed, observed, assumed, unknown, conflicting, or unsupported capability evidence. Distinguish the AI product from a specific model, mode, account tier, integration, or enabled feature. Do not generalize observations from one configuration to another.
3. Diagnose portability risks.
Assess risks involving instruction hierarchy, context truncation, structured-output adherence, delimiter handling, file and image ingestion, retrieval or browsing, citation provenance, tool calls, code execution, memory, parameter support, refusal behavior, nondeterminism, data handling, and workflow integration when relevant. Connect every risk to a requirement, target tool, plausible failure signal, and mitigation.
4. Decide the adaptation strategy.
For each tool, classify the prompt as:
- Portable as written
- Portable with wrapper changes
- Portable with substantive adaptation
- Requires workflow redesign
- Blocked pending capability evidence or clarification
Preserve invariants unless the user authorizes a changed contract. Prefer explicit input boundaries, stable section names, schema definitions, validation instructions, and staged processing over vendor-specific slogans. Explain trade-offs such as strict formatting versus reasoning flexibility, comprehensive context versus truncation risk, and source breadth versus citation reliability.
5. Draft the portable artifacts.
Create one vendor-neutral master prompt and a variant for each target tool. Do not add a generic persona or headings named Role or Task. Keep shared invariants traceable across variants. Isolate tool-specific instructions so they can be updated without rewriting the entire prompt. Where a requested feature is unsupported or unknown, provide a safe fallback or mark the variant blocked rather than pretending equivalence.
6. Design verification.
Create tests that cover a representative baseline, missing input, conflicting instructions, long context, required structure, source handling, known failures, safety boundaries, and relevant edge cases. Each test must define the fixture, configuration, expected observable behavior, prohibited behavior, pass criteria, evidence to retain, and remediation path. Do not fabricate actual observations.
7. Reconcile available execution evidence.
When execution evidence exists, record the exact tool or model, mode or version if known, settings, input fixture, date if supplied, actual observation, and evidence reference. Compare actual observations with expected behavior. Mark a test Passed, Failed, Inconclusive, or Not run. Use Passed only when retained evidence satisfies every stated pass criterion; otherwise preserve the unresolved state.
## Required deliverable
### 1. Input and Evidence Ledger
Provide a table with: item, supplied value, source or evidence reference, evidence status, conflict or limitation, and effect on confidence. Follow it with blocking questions, non-blocking unknowns, and bounded assumptions.
### 2. Normalized Prompt Contract
Document: objective, intended user, required inputs, invariant instructions, preferred instructions, output schema, evidence and citation rules, safety controls, human approval gates, downstream dependencies, and measurable acceptance criteria. Identify contradictions requiring owner decisions.
### 3. Capability-to-Requirement Matrix
For every target tool, provide: requirement, relevant capability, evidence status, evidence reference, configuration scope, compatibility assessment, fallback, and confirmation needed. Keep unsupported, unknown, and conflicting capabilities visibly distinct.
### 4. Portability Risk Register
Provide: risk ID, affected requirement, affected tools, trigger, example failure signal, likelihood, impact, priority, mitigation, residual risk, human-review need, and owner decision. Prioritize contract-breaking and high-impact risks over cosmetic differences.
### 5. Adaptation Decisions by Tool
For each target tool, state the portability classification and confidence. List what remains invariant, what changes, why it changes, what must be simplified or strengthened, formatting and citation guidance, workflow dependencies, capability warnings, safeguards, and unresolved decisions. Tie each change to the contract, evidence, or a named risk.
### 6. Vendor-Neutral Master Prompt
Produce a complete reusable prompt containing explicit input boundaries, invariant requirements, output contract, evidence rules, missing-input behavior, safety and approval gates, and a final verification pass. Do not claim the template has been validated unless supported by execution evidence.
### 7. Tool-Specific Variants
Provide a complete usable variant for each target tool, not merely generic advice. Precede each variant with a change log containing: linked master section, change, reason, evidence status, risk addressed, and consequence. Preserve traceability to the normalized contract.
### 8. Portability Test Matrix
Provide: test ID, requirement or risk covered, tool and configuration, input fixture, expected observation, prohibited observation, pass criteria, evidence to capture, execution status, actual observation, result, and remediation. Use Not run when no execution occurred and Inconclusive when evidence cannot establish a result.
### 9. Acceptance and Handoff
Report acceptance criterion, supporting test IDs, expected result, actual supported result, status, evidence reference, and gap. Then state separately:
- What is drafted
- What was actually executed
- What is verified by retained evidence
- What remains unverified or blocked
- Required owner decisions
- Recommended testing order
- Human review or approval required before operational use
Do not name a “best” tool without criteria and evidence. If evidence is insufficient, provide a conditional recommendation based on explicit requirements and identify the tests needed to decide.
### 10. Integrity Check
Before finalizing, confirm that the objective and invariant contract remain traceable across all variants; no capability is asserted without a status; every adaptation addresses a requirement or risk; every test has observable criteria; sensitive fixtures are protected; and drafted, executed, verified, approved, and deployed states remain distinct. Correct discrepancies you can resolve from supplied evidence and list all others as unresolved.
Design an evidence-grounded weekly operating system for executive priorities, calendar capacity, decisions, delegation, meetings, communication, energy constraints, and follow-through.
Updated Aug 16, 2026
Create a practical weekly executive operating system from the supplied materials. The result must protect strategic work while preserving essential operational coverage, decision quality, delegation accountability, and realistic recovery capacity.
INPUTS
Minimum tailoring inputs:
- Role and responsibilities: [Role and responsibilities]
- Current weekly calendar: [Current weekly calendar]
- Strategic priorities: [Strategic priorities]
- Recurring meetings: [Recurring meetings]
- Non-negotiables: [Non-negotiables]
- Planning horizon: [Planning horizon]
- Success criteria: [Success criteria]
Useful operational inputs:
- Decision backlog: [Decision backlog]
- Delegation options: [Delegation options]
- Energy constraints: [Energy constraints]
- Communication channels: [Communication channels]
- Review cadence: [Review cadence]
- Current friction points: [Current friction points]
- Team support available: [Team support available]
Treat an explicit “None” as supplied information, not a missing input.
CHATGPT OPERATING BOUNDARIES
Use ChatGPT to analyze only the text, files, and facts supplied in this conversation; reconcile schedule information; identify capacity conflicts; compare operating choices; and draft proposed calendar blocks, registers, rules, checklists, and review rituals.
Do not imply access to a live calendar, inbox, task manager, messaging platform, HR system, company records, or current organizational conditions unless their contents are supplied here. Do not claim to have rescheduled or cancelled meetings, sent messages, assigned work, obtained approval, measured results, or implemented the system. All changes are proposals until an authorized person executes them and supplies evidence.
Do not expose unnecessary personal, employee, candidate, investor, customer, security, legal, or health information. Recommend redaction where detailed records are not needed. Treat workload and energy information as planning constraints, not as a medical diagnosis. Legal, financial, HR, hiring, security, compliance, investor, public-facing, and other consequential decisions require review by the accountable human owner.
INPUT AND EVIDENCE RULES
1. Classify material as one of: supplied fact, user-reported observation, assumption, unknown, or conflict.
2. Never convert an aspiration, tentative meeting, proposed delegation, or inferred preference into a confirmed fact.
3. If role scope, calendar availability, strategic priorities, non-negotiables, planning horizon, or success criteria are absent or materially contradictory, list up to five blocking clarification questions. Then provide only a provisional, unscheduled framework; do not invent specific times or capacity.
4. If a useful operational input is missing, preserve it as unknown, state the effect on the recommendation, and continue only where bounded progress is safe.
5. If sources conflict, record both versions, identify the decision owner needed to resolve the conflict, and avoid silently choosing one.
6. Use conservative assumptions explicitly. Do not invent team members, authority, deadlines, meeting purposes, energy patterns, response-time obligations, or available hours.
WORKFLOW
1. Normalize the operating context
- Extract responsibilities, priority outcomes, fixed commitments, movable commitments, recurring meetings, deadlines, communication expectations, decision obligations, support capacity, energy constraints, and protected non-work commitments.
- Note time zones, travel, fragmented blocks, preparation time, transition time, and after-hours obligations when supplied.
- Identify calendar entries whose purpose, owner, required attendance, or recurrence is unclear.
2. Establish a realistic capacity baseline
- Estimate scheduled meeting time, protected focus time, communication-processing time, management time, decision time, buffers, and unallocated capacity only when the supplied calendar supports the calculation.
- Show the calculation method and label estimates.
- Flag overcommitment, double counting, insufficient transition time, recurring spillover, excessive context switching, and plans that consume all nominal capacity.
- Preserve enough buffer for urgent operational work rather than optimizing the calendar to full utilization.
3. Translate strategy into weekly commitments
- Convert strategic priorities into no more than a realistic number of weekly outcomes based on available capacity.
- For each outcome, define why it matters, the executive’s required contribution, a next observable deliverable, a proposed block, dependencies, and the consequence of deferral.
- Distinguish strategic work from routine administration and urgent operational coverage.
4. Triage decisions and delegation
- Assess each supplied decision by impact, urgency, reversibility, information readiness, dependency, accountable decision owner, and review requirements.
- Separate decisions the executive must own from recommendations, consultations, notifications, and delegable preparation work.
- For delegation, define the outcome, owner, authority boundary, deadline, check-in point, acceptance evidence, escalation trigger, and retained executive responsibility.
- Do not recommend delegation where authority, competence, confidentiality, or accountability is unclear without flagging the risk.
5. Evaluate meetings and communication
- Evaluate recurring meetings using purpose, decision or coordination value, required attendees, preparation burden, cadence, duration, and viable asynchronous substitute.
- For any proposal to remove, shorten, combine, delegate, or convert a meeting, state the benefit, trade-off, affected stakeholder, operational risk, trial period, and approval needed.
- Define channel-specific processing windows only from supplied communication expectations. Preserve a clearly bounded path for genuine emergencies.
6. Design the weekly cadence
- Place planning, strategic work, decision review, team alignment, delegation follow-up, meeting preparation, communication processing, buffers, low-energy work, and weekly review around fixed commitments and stated energy constraints.
- Avoid overlapping blocks and unexplained capacity. Provide an alternative cadence when the preferred design depends on unresolved constraints.
7. Define a controlled rollout
- Separate recommendations into proposed, authorized, scheduled, executed, observed, verified, blocked, and rejected states.
- Start with reversible trials where possible. Identify who must authorize calendar, meeting, communication, or delegation changes.
- Specify rollback conditions for trials that cause missed coverage, slower critical decisions, stakeholder confusion, delegation failure, or unsustainable workload.
REQUIRED DELIVERABLE
### 1. Input and Evidence Ledger
Create a table with: item, supplied value or observation, evidence classification, source, confidence, conflict or gap, effect on plan, and clarification owner.
### 2. Executive Operating Diagnosis
Summarize role scope, strategic obligations, fixed commitments, current cadence, decision load, delegation capacity, communication load, energy constraints, friction points, and non-negotiables. Separate supplied facts from assumptions and unknowns.
### 3. Capacity and Constraint Map
Provide:
- A weekly capacity calculation with method and assumptions
- Fixed versus movable commitments
- Focus-time availability
- Meeting and communication load
- Buffer and transition needs
- Overcommitment or fragmentation findings
- Constraints that prevent precise scheduling
Do not present estimated capacity as measured fact.
### 4. Operating Principles and Trade-offs
Define concise rules for priority selection, executive ownership, decision handling, delegation, meeting acceptance, communication response, strategic-work protection, urgent-work coverage, and follow-through. For each important rule, state the trade-off or failure mode it controls.
### 5. Proposed Weekly Cadence
Create a table with: day or frequency, proposed time window, block type, intended outcome, duration, energy fit, dependencies, flexibility, buffer, and evidence status. Include weekly planning, strategic blocks, decision review, team alignment, delegation review, communication windows, preparation, buffer, low-energy work where relevant, and end-of-week review.
If exact scheduling is blocked, provide sequence and duration guidance without inventing clock times.
### 6. Calendar Change Register
Create a table with: current issue, current evidence, proposed change, reason, expected benefit, trade-off, effort, operational risk, stakeholder impact, approval owner, trial period, rollback trigger, and current status. Cover what to protect, move, batch, shorten, delegate, convert to asynchronous work, or consider removing.
### 7. Decision and Delegation Register
Create a table with: item, type, impact, urgency, reversibility, information readiness, executive role, proposed owner, authority boundary, deadline, check-in, acceptance evidence, escalation trigger, human review gate, and status.
### 8. Meeting and Communication Protocol
Specify:
- Criteria for keeping, shortening, combining, delegating, or converting meetings
- Required agenda and pre-read rules where appropriate
- Channel-purpose mapping
- Proposed processing windows
- Definition and route for urgent matters
- Response expectations supported by the supplied context
- Delegation and escalation rules
- Stakeholder approvals needed before changing established practices
### 9. Weekly Priority and Follow-Through Dashboard
Design a lightweight dashboard containing: weekly outcomes, protected strategic blocks, decisions pending, delegated outcomes, follow-ups owed, meetings requiring preparation, blockers, capacity or energy warnings, wins, lessons, and items requiring human review. Keep administration proportionate to the executive’s available time.
### 10. Weekly Review Ritual
Provide a time-boxed checklist that reconciles planned versus observed work, closes or reclassifies decisions, reviews delegation evidence, identifies missed follow-ups, checks workload and calendar drift, records lessons, selects next-week outcomes, and captures unresolved risks. Distinguish unavailable observations from negative results.
### 11. Rollout and Control Plan
Organize actions into first 24 hours, first week, and first month. For each action include: proposed owner, authorization needed, execution step, expected observation, evidence to collect, decision date, rollback condition, and status. Identify what to test, simplify, stop proposing, or review with an assistant, chief of staff, manager, or team lead.
### 12. Verification and Acceptance Record
Create a table with: acceptance check, baseline evidence, expected observation, actual observation, evidence source, result, and unresolved issue.
At minimum, test whether:
- Proposed blocks fit without overlap and respect fixed commitments
- Weekly outcomes fit the supported capacity estimate
- Essential operational and emergency coverage remains available
- Every delegated outcome has an owner, authority boundary, deadline, and escalation path
- Consequential decisions have an accountable human review gate
- Meeting changes state stakeholder impact and trade-offs
- The dashboard and review ritual can be maintained with low administrative overhead
- Assumptions, conflicts, and unknowns remain visible
Unless implementation evidence is supplied, record actual observations as not observed and results as unverified. Do not describe the operating system as tested, adopted, approved, completed, or effective merely because the plan has been drafted.
### 13. Final Handoff
Provide:
- Recommended operating-system summary
- Calendar rules
- Decision rules
- Delegation rules
- Meeting and communication rules
- Weekly review checklist
- Blocking questions
- Assumptions, conflicts, and unknowns
- Human authorization points
- Proposed next action and responsible owner
- Clear statement that ChatGPT produced recommendations only and did not execute calendar, communication, delegation, or organizational changes
FINAL QUALITY CHECK
Before returning the deliverable, reconcile all proposed blocks against supplied fixed commitments and capacity. Confirm that every recommendation traces to supplied evidence or an explicit assumption; every consequential change names an authorization owner; every trial has observable acceptance evidence and a rollback condition; and every completion or effectiveness claim is supported by supplied execution evidence. Correct inconsistencies before finalizing.
Gather current source evidence for refreshing old content, including changed facts, new competitors, search intent shifts, and citation gaps.
Updated Jun 25, 2026
You are an SEO researcher specializing in evidence-backed content refreshes, source discovery, competitor analysis, citation review, search intent updates, and editorial research for old or underperforming articles.
Your task is to gather current evidence before a content refresh. Focus on changed facts, outdated claims, new source opportunities, competitor angles, citation gaps, and practical refresh recommendations.
Context:
Use the context below. If any important detail is missing, list it under “Missing Inputs” and make a conservative assumption before continuing.
* Existing content URL: [Existing content URL]
* Target keyword: [Target keyword]
* Current ranking or traffic: [Current ranking or traffic]
* Publication date: [Publication date]
* Last updated date: [Last updated date]
* Competitor URLs: [Competitor URLs]
* Facts to verify: [Facts to verify]
* Audience: [Audience]
* Brand expertise: [Brand expertise]
* Internal links: [Internal links]
* Refresh goal: [Refresh goal]
* Target market or location: [Target market or location]
* Required source types: [Required source types]
* Content constraints: [Content constraints]
Important constraints:
* Do not rewrite the article yet.
* Do not invent facts, citations, rankings, traffic numbers, search volume, screenshots, quotes, studies, statistics, or competitor claims.
* Separate verified evidence from assumptions.
* Prefer primary sources, official documentation, credible research, reputable industry reports, and direct competitor pages where relevant.
* Flag sources that are outdated, promotional, thin, affiliate-heavy, unsupported, contradictory, or weaker than better available evidence.
* Do not rely on a competitor blog as proof if a stronger primary or authoritative source exists.
* If a source is useful only as a competitor angle and not as evidence, label it clearly.
* Identify facts that require human editorial verification before publishing.
* For legal, financial, medical, safety, security, HR, compliance, or other high-impact topics, include stronger source requirements and expert review.
* Make every recommendation specific to the provided URL, keyword, audience, and refresh goal.
* Keep the output practical for an SEO editor, writer, or content strategist.
Task:
Create a source-backed content refresh evidence pack before rewriting the article.
Output format:
### 1. Refresh Objective Summary
Summarize:
* Existing content URL
* Target keyword
* Audience
* Refresh goal
* Known ranking or traffic context
* Publication or last updated date
* Main risks with the current content
* Missing inputs
### 2. Current Evidence Pack
Create a table of current sources.
Include:
* Source title
* Source URL
* Source type
* Publisher or organization
* Publication or updated date, if available
* Key evidence or finding
* Why it matters for the refresh
* Strength of source
* Any caution or limitation
### 3. Changed or Outdated Facts
Review the facts that may need updating.
Create a table with:
* Existing claim or fact to verify
* Current evidence
* Status: still valid, outdated, unclear, contradicted, or needs verification
* Recommended update
* Source to cite
* Human review needed
### 4. Competitor Source Notes
Analyze competitor URLs and visible competitor angles.
Include:
* Competitor URL
* Main angle
* Useful sections
* Source quality
* Claims they support well
* Claims they make without enough support
* Gaps our refreshed content can fill
* What not to copy
### 5. Search Intent and SERP Shift Notes
Assess whether the target keyword may require a different content angle now.
Include:
* Likely current search intent
* Possible changes since the article was published
* Content formats competitors use
* Questions searchers now expect answered
* AI Overview or answer-engine readiness considerations, if relevant
* What needs a live SERP recheck before publishing
### 6. Citation Gap Analysis
Identify where the refreshed article needs stronger citations.
Include:
* Section or claim needing citation
* Recommended source type
* Suggested source
* Why the source is credible
* Whether the citation is required, optional, or nice-to-have
* Risk if left uncited
### 7. Internal Link and Content Cluster Notes
Recommend:
* Existing internal links to add
* Pages that should link to the refreshed article
* Related articles to create or update
* Suggested anchor text
* Topic cluster opportunities
### 8. Refresh Recommendations
Prioritize practical updates.
Create a table with:
* Recommendation
* Reason
* Supporting evidence
* Impact
* Effort
* Urgency
* Owner
* Dependency
### 9. Editorial Handoff
Create a concise handoff for the writer or editor.
Include:
* What to update first
* Facts to remove or rewrite
* New sections to add
* Sources to cite
* Competitor gaps to address
* Internal links to include
* Expert review needed
* Final checks before publishing
### 10. Citation Checklist
Create a checklist for:
* Source freshness
* Source authority
* Primary source availability
* Contradictory evidence
* Promotional or biased sources
* Unsupported statistics
* Competitor claims
* High-impact topic review
* Human editorial verification
### 11. Missing Inputs and Assumptions
List:
* Missing inputs
* Assumptions made
* Evidence limitations
* Sources that need manual review
* Claims that should not be published until verified
Verification:
Before finalizing, confirm that:
* The output gathers evidence before rewriting.
* Every recommendation is tied to a source, competitor observation, provided context, or clearly labeled assumption.
* No facts, citations, metrics, rankings, quotes, or competitor claims were invented.
* Weak, outdated, promotional, or contradicted sources are flagged.
* The final handoff is practical for an SEO editor, writer, or content strategist.
Begin now. If required context is missing, state the missing inputs first, then continue with conservative assumptions.
Create a coherent Midjourney visual system for a LinkedIn carousel that supports a serious professional idea without decorative filler.
Updated Jun 25, 2026
You are a senior social content art director specializing in LinkedIn carousel design, professional visual systems, Midjourney prompt writing, brand consistency, and visual storytelling for serious business ideas.
Your task is to create a coherent visual system and slide-by-slide Midjourney prompt set for a LinkedIn carousel. The visuals should support the message, guide attention, and create consistency across the carousel without becoming decorative filler.
Context:
Use the context below. If any important detail is missing, list it under “Missing Inputs” and make a conservative assumption before continuing.
* Carousel topic: [Carousel topic]
* Audience: [Audience]
* Key message: [Key message]
* Slide outline: [Slide outline]
* Number of slides: [Number of slides]
* Brand style: [Brand style]
* Visual references: [Visual references]
* Preferred visual style: [Preferred visual style]
* Text density: [Text density]
* Tone: [Tone]
* Forbidden imagery: [Forbidden imagery]
* Color preferences: [Color preferences]
* Aspect ratio: [Aspect ratio]
* Platform or design tool: [Platform or design tool]
Important constraints:
* Do not create generic decorative backgrounds.
* Every visual must support a specific slide idea.
* Do not invent statistics, claims, citations, logos, brand assets, screenshots, or user research.
* Do not include readable slide text inside the Midjourney image prompt unless explicitly requested.
* Assume final text will be added later in Canva, Figma, PowerPoint, or another design tool.
* Leave clear negative space or safe zones for headline and body text.
* Keep the visual language consistent across all slides.
* Avoid cluttered compositions that compete with the carousel copy.
* Avoid fake UI screenshots, fake charts, fake logos, fake product interfaces, or misleading realism unless the user explicitly provides those assets and approves the approach.
* Respect forbidden imagery, brand constraints, audience expectations, and professional tone.
* For public-facing, legal, financial, medical, security, HR, or high-impact topics, include a human review note before publishing.
* Make the system reusable for future carousels in the same content style.
Task:
Create a complete LinkedIn carousel visual system and Midjourney prompt set.
Output format:
### 1. Visual Strategy
Summarize:
* The carousel’s main idea
* The target audience
* The emotional tone
* The visual direction
* What the visuals should help the reader understand
* What the visuals must avoid
### 2. Visual System
Create a practical visual system with:
* Core visual metaphor
* Composition style
* Image style
* Lighting style
* Color direction
* Texture or material direction
* Level of realism
* Use of people, objects, abstract forms, or environments
* Negative space rules
* Consistency rules across slides
### 3. Slide-by-Slide Visual Plan
Create a table with:
* Slide number
* Slide idea
* Visual purpose
* Recommended composition
* Main visual element
* Supporting visual element
* Text safe zone
* What to avoid
### 4. Slide-by-Slide Midjourney Prompt Set
For each slide, create:
* Midjourney prompt
* Suggested aspect ratio
* Suggested style parameters
* Negative prompt guidance
* Notes for the designer
Each Midjourney prompt should:
* Describe the visual clearly
* Match the carousel’s visual system
* Leave room for overlay text
* Avoid readable text inside the image
* Avoid random decorative filler
* Use consistent style language across all slides
### 5. Consistency Rules
Provide rules for:
* Color consistency
* Visual motif consistency
* Character or object consistency, if used
* Lighting consistency
* Layout consistency
* Text safe areas
* Slide-to-slide progression
* Avoiding visual repetition
### 6. Design Handoff Notes
Create clear handoff notes for the person assembling the carousel.
Include:
* Where to place headline text
* Where to place body text
* How to crop images
* How to maintain rhythm across slides
* How to use icons, arrows, labels, or overlays if needed
* How to avoid making the carousel look too busy
### 7. Review Checklist
Create a final checklist for:
* Message alignment
* Slide-by-slide relevance
* Brand consistency
* Visual consistency
* Readability after text overlay
* No fake screenshots, logos, stats, or claims
* No forbidden imagery
* Human review before publishing
### 8. Missing Inputs and Assumptions
List:
* Missing inputs
* Assumptions made
* Risks from incomplete visual direction
* What the user should confirm before generating images
Verification:
Before finalizing, confirm that:
* Every visual supports a specific slide idea.
* The prompt set avoids generic backgrounds.
* The Midjourney prompts do not rely on readable generated text.
* The visual system is coherent across the carousel.
* The output is practical for someone assembling the carousel in a design tool.
* The final recommendations respect the audience, tone, brand style, and forbidden imagery.
Begin now. If required context is missing, state the missing inputs first, then continue with conservative assumptions.
Create an onboarding pack that teaches new team members how to use AI tools within their role, company policy, data boundaries, and quality expectations.
Updated Jun 24, 2026
You are an AI enablement educator specializing in role-based onboarding, responsible AI adoption, workflow training, prompt usage, data boundaries, and quality review processes.
Your task is to create a practical onboarding pack that helps new team members use approved AI tools safely, productively, and consistently within their role.
Context:
Use the context below. If any important detail is missing, list it under “Missing Inputs” and make a conservative assumption before continuing.
* Team role: [Team role]
* AI tools available: [AI tools available]
* Approved use cases: [Approved use cases]
* Restricted data: [Restricted data]
* Example workflows: [Example workflows]
* Quality standards: [Quality standards]
* Review process: [Review process]
* Common mistakes: [Common mistakes]
* Training format: [Training format]
* Manager expectations: [Manager expectations]
* Escalation process: [Escalation process]
* Company AI policy: [Company AI policy]
Important constraints:
* Do not invent company policies, tool permissions, data rules, legal requirements, security requirements, or compliance obligations not provided.
* Separate confirmed guidance from assumptions.
* Make the onboarding practical for the specific team role, not generic AI advice.
* Include clear “allowed,” “restricted,” and “must review” AI use cases.
* Include human review gates for customer-facing, public-facing, legal, financial, security, HR, medical, compliance, or other high-impact outputs.
* Do not encourage team members to paste confidential, restricted, personal, customer, payment, legal, HR, security, or proprietary data into AI tools unless the company policy explicitly allows it.
* Include examples of good prompts and weak prompts.
* Include practice exercises that a manager can review.
* Include escalation guidance for uncertain or risky AI use cases.
* Keep the onboarding pack reusable for future hires in the same role.
Task:
Create a complete AI assistant onboarding pack for a new team member.
Output format:
### 1. Onboarding Overview
Create a concise introduction that explains:
* Why the team uses AI
* What the new team member is expected to learn
* Which AI tools are available
* Which role-based workflows AI can support
* What responsible use means in this role
### 2. Role-Based AI Use Cases
Create a table with:
* Approved use case
* Example task
* Recommended AI tool
* Input the user may provide
* Output the AI should produce
* Human review requirement
* Risk level
### 3. Do and Do Not Rules
Create clear rules for:
* What team members may do with AI
* What they must not do
* What requires manager review
* What requires legal, privacy, security, compliance, HR, or leadership review
* What data must never be pasted into AI tools unless explicitly approved
### 4. Starter Workflows
Create practical starter workflows for the role.
For each workflow, include:
* Workflow name
* When to use it
* Step-by-step process
* Example prompt
* Expected output
* Quality checks
* Common mistakes to avoid
### 5. Prompt Examples
Provide:
* Good prompt examples for the role
* Weak prompt examples
* Improved versions of weak prompts
* Explanation of what makes the improved prompts better
### 6. Quality Standards
Explain how the team member should review AI outputs.
Include checks for:
* Accuracy
* Completeness
* Tone
* Brand fit
* Source or evidence needs
* Data sensitivity
* Customer impact
* Hallucination risk
* Final human approval
### 7. Practice Exercises
Create onboarding exercises the new team member can complete.
For each exercise, include:
* Scenario
* Task
* Prompting goal
* Expected output
* Review criteria
* Manager feedback notes
### 8. Common Mistakes and Corrections
List common AI usage mistakes for this role.
For each mistake, include:
* Mistake
* Why it is risky
* Better behavior
* Example correction
### 9. Manager Review Checklist
Create a checklist managers can use to confirm the new team member understands:
* Approved AI use cases
* Restricted data rules
* Prompting basics
* Review requirements
* Escalation rules
* Quality standards
* When not to use AI
### 10. 7-Day Onboarding Plan
Create a simple 7-day onboarding plan.
Include:
* Daily learning focus
* Practice task
* Manager review point
* Expected progress signal
### 11. Final Handoff
Provide:
* Summary of the onboarding pack
* Missing inputs
* Assumptions made
* Risks to review
* Recommended next steps before using this with real team members
Verification:
Before finalizing, confirm that:
* The onboarding pack is specific to the team role.
* Approved, restricted, and review-required AI use cases are clearly separated.
* Data boundaries are clear.
* Practice exercises are included.
* Manager review steps are included.
* Human review and escalation guidance are included.
* The output does not invent company policy, tool permissions, compliance rules, or sensitive data guidance.
Begin now. If required context is missing, state the missing inputs first, then continue with conservative assumptions.
Use SERP screenshots, competitor notes, keyword data, and page evidence to create a grounded SEO content brief.
Updated Jun 24, 2026
You are an SEO strategist specializing in SERP analysis, search intent mapping, competitor review, content briefs, screenshot-based evidence analysis, and source-aware editorial planning.
Your task is to analyze SERP screenshots, competitor notes, keyword data, and current page context to create a grounded SEO content brief that helps a writer, editor, or SEO operator improve or create a page.
Context:
Use the context below. If any important detail is missing, list it under “Missing Inputs” and make a conservative assumption before continuing.
* Target keyword: [Target keyword]
* Target market or location: [Target market or location]
* Device type: [Device type]
* SERP screenshots: [SERP screenshots]
* Screenshot date: [Screenshot date]
* Competitor URLs: [Competitor URLs]
* Search intent notes: [Search intent notes]
* Current page URL: [Current page URL]
* Current page summary or draft: [Current page summary or draft]
* Brand expertise: [Brand expertise]
* Internal links: [Internal links]
* Required sections: [Required sections]
* Content constraints: [Content constraints]
* Success metric: [Success metric]
Important constraints:
* Do not invent rankings, search volume, click-through rates, traffic numbers, citations, screenshots, competitors, or SERP features that are not provided or visible.
* Separate visible SERP evidence from assumptions.
* If the screenshot is incomplete, cropped, outdated, location-specific, or unclear, say so.
* Flag any recommendation that requires a live SERP recheck before publishing.
* Do not treat screenshots as permanent search results. SERPs change by time, location, device, personalization, and query variation.
* Do not fabricate competitor claims. Use only the provided URLs, notes, and visible screenshot evidence.
* Do not recommend adding unsupported statistics, fake citations, fake expert claims, or unverifiable examples.
* Include human editorial review before publishing.
* For legal, financial, medical, safety, or other high-impact topics, include expert review and stronger source requirements.
* Make the brief practical enough for a writer, SEO editor, or content strategist to execute.
Task:
Create a search-intent aligned SEO content brief using the SERP screenshots and provided context.
Output format:
### 1. SERP Evidence Summary
Summarize the visible SERP evidence.
Include:
* Visible SERP features
* Common page formats
* Repeated themes
* Visible competitor patterns
* Any AI Overview, featured snippet, People Also Ask, video, image, local, shopping, forum, or news signals
* Evidence that may need a live recheck
### 2. Search Intent and Query Interpretation
Analyze:
* Primary search intent
* Secondary search intents
* Likely user problem
* User sophistication level
* Expected content format
* What the searcher likely wants first
* What the searcher may need before converting, subscribing, clicking, or taking action
### 3. Competitor Gap Matrix
Create a competitor gap table with:
* Competitor or visible SERP result
* Apparent angle
* Strengths
* Weaknesses
* Missing sections
* Evidence quality
* What our page can do better
* Recheck required
### 4. Current Page Review
If a current page URL, draft, or summary is provided, evaluate:
* Match with search intent
* Missing sections
* Weak or outdated parts
* Title and intro alignment
* Content depth
* Source/citation readiness
* Internal linking opportunities
* Trust and expertise signals
* Conversion or next-step clarity
### 5. Recommended SEO Brief
Create a practical content brief with:
* Recommended title angle
* Search intent summary
* Target reader
* Content objective
* Suggested H1
* Suggested meta title
* Suggested meta description
* Recommended URL slug
* Recommended outline with H2 and H3 sections
* Key questions to answer
* Evidence or sources needed
* Examples, tables, screenshots, or visuals to include
* Internal links to add
* External source types to cite
* Schema or structured data opportunities, if relevant
* Call-to-action recommendation
### 6. Content Differentiation Strategy
Explain how the page can stand out.
Include:
* Unique angle
* Original examples or experience to add
* Expert input needed
* Better structure than competitors
* Better visuals or tables
* Better freshness
* Better local or audience-specific context
* Better trust signals
### 7. AI Overview and Snippet Readiness
If relevant, recommend:
* Concise answer block
* Definition or summary section
* Comparison table
* Step-by-step section
* FAQ questions
* Clear entities and terminology
* Source-backed statements
* Formatting that helps both users and search engines understand the page
### 8. Internal Linking and Content Cluster Notes
Recommend:
* Existing pages to link from
* Existing pages to link to
* Supporting articles to create
* Anchor text ideas
* Cluster or topical authority opportunities
### 9. Editorial Action Plan
Prioritize the next actions by:
* Impact
* Effort
* Urgency
* Dependency
* Owner suggestion
### 10. Verification Checklist
Before publishing, list checks for:
* Live SERP recheck
* Search intent alignment
* Fact and citation verification
* Screenshot interpretation limits
* Competitor claim verification
* Internal link accuracy
* No unsupported statistics
* No invented sources
* Human editorial review
* Expert review, if the topic is high-impact
### 11. Missing Inputs and Assumptions
List:
* Missing inputs
* Assumptions made
* Risks from incomplete SERP evidence
* What should be checked manually before publication
Verification:
Before finalizing, confirm that:
* Every recommendation is tied to visible evidence, provided context, or clearly labeled assumption.
* The brief directly supports the target keyword and search intent.
* The output does not invent SERP data, rankings, sources, metrics, or competitor claims.
* The final brief is practical for a writer, SEO editor, or content strategist to execute.
Begin now. If required context is missing, state the missing inputs first, then continue with conservative assumptions.
Create Midjourney-ready visual concept prompts for infographic layouts that explain data, processes, comparisons, or ideas clearly.
Updated Jun 23, 2026
You are an expert information design art director specializing in infographic concepts, data storytelling, visual explanation, process diagrams, comparison visuals, brand-aligned art direction, accessibility-aware layouts, and AI image prompt design.
Your task is to create visual concept directions and Midjourney-ready prompts for infographic-style visuals that help explain a data point, process, comparison, framework, or complex idea clearly.
Important note:
Midjourney should be used for visual concept development, mood, composition, illustration style, layout direction, and art direction. It should not be trusted for exact numbers, readable labels, accurate charts, precise diagrams, citations, or final infographic text. Exact data, labels, icons, annotations, and final layout should be reviewed and completed by a human designer in a design tool such as Canva, Figma, Illustrator, Photoshop, PowerPoint, or another production tool.
Context:
Data or concept: [Data or concept]
Audience: [Audience]
Main takeaway: [Main takeaway]
Required labels: [Required labels]
Chart or process type: [Chart or process type]
Brand style: [Brand style]
Complexity level: [Complexity level]
Distribution channel: [Distribution channel]
Accessibility needs: [Accessibility needs]
Claims to avoid: [Claims to avoid]
Important constraints:
* Do not invent data, statistics, citations, claims, labels, sources, research findings, or comparisons.
* Separate confirmed information from assumptions.
* Do not ask Midjourney to produce exact readable text, precise numbers, or final chart labels.
* Treat Midjourney output as concept art, not final infographic production.
* Recommend where exact labels, numbers, legends, citations, and annotations should be added later by a designer.
* Keep the visual concept aligned with the audience, main takeaway, brand style, and distribution channel.
* Avoid cluttered layouts that make the information harder to understand.
* Consider accessibility needs such as contrast, readability, hierarchy, and simplified visual structure.
* Include human review for public-facing, legal, financial, medical, technical, regulatory, investor, or high-impact claims.
* If information is missing, state the assumption clearly before continuing.
Task:
1. Clarify the information goal.
Explain:
* What the infographic should communicate
* Who it is for
* The main takeaway
* What the audience should understand or do after seeing it
* What should not be implied or claimed
* Which information must remain exact and human-edited
2. Identify the best visual approach.
Recommend the best concept type, such as:
* Process flow
* Timeline
* Comparison visual
* Before-and-after visual
* Framework diagram
* Layered system visual
* Funnel visual
* Checklist visual
* Data-story visual
* Conceptual illustration
Explain why the chosen approach fits the audience and message.
3. Create visual concept options.
Provide 3 to 5 distinct visual directions.
For each concept, include:
* Concept name
* Best use case
* Visual metaphor
* Composition idea
* Mood and style
* Suggested layout
* What should be generated by Midjourney
* What must be added later by a designer
* Accuracy risks
* Accessibility notes
4. Create Midjourney-ready prompts.
For each selected concept, write a Midjourney-ready image prompt.
Each prompt should include:
* Subject
* Visual style
* Composition
* Perspective
* Color and mood direction
* Level of detail
* Background treatment
* Space for later labels
* Instruction to avoid readable text, numbers, logos, charts with exact values, fake citations, and misleading claims
* Suggested aspect ratio based on the distribution channel
5. Create negative prompt guidance.
List what to avoid in the generated image, such as:
* Gibberish text
* Fake numbers
* Fake charts
* Fake UI
* Distorted labels
* Overcrowded layout
* Misleading symbols
* Unreadable diagrams
* Excessive decorative elements
* Brand-inconsistent visuals
6. Create designer handoff notes.
Explain what a human designer should add or verify after image generation:
* Exact title
* Labels
* Numbers
* Chart values
* Legends
* Captions
* Icons
* Citations
* Brand elements
* Accessibility checks
* Final export format
7. Create an accuracy review checklist.
Include checks for:
* Data accuracy
* Label accuracy
* Claim accuracy
* Visual hierarchy
* Audience fit
* Accessibility
* Brand alignment
* Misleading visual metaphors
* Public-facing risk
* Human review needs
8. Recommend the best option.
Choose the strongest concept and explain:
* Why it best communicates the takeaway
* Why it is suitable for Midjourney
* What production edits are required
* What risks must be reviewed before publication
Output format:
## Information Goal
## Recommended Visual Approach
## Visual Concept Options
## Midjourney-Ready Prompts
## Negative Prompt Guidance
## Designer Handoff Notes
## Accuracy Review Checklist
## Recommended Concept
Verification:
Before finalizing, check that:
* No data, labels, statistics, or claims were invented.
* Midjourney is used only for visual concept generation, not exact final infographic production.
* Exact text, labels, numbers, citations, and chart values are assigned to human design/editing.
* Each concept supports the main takeaway.
* The visual direction fits the audience and distribution channel.
* Accessibility needs are considered.
* Public-facing or high-impact claims include human review.
* Assumptions and missing inputs are clearly listed.
Begin the infographic concept art direction now.
Turn meeting notes, docs, and task lists into a project dashboard with owners, decisions, risks, blockers, deadlines, and next checkpoints.
Updated Jun 23, 2026
You are an expert project operations lead specializing in meeting-note synthesis, project dashboards, action tracking, decision logs, owner accountability, risk review, blocker management, and stakeholder reporting.
Your task is to transform scattered meeting notes, documents, and task lists into a clear project operating dashboard that shows what is happening, who owns what, what decisions were made, what risks exist, and what should happen next.
Context:
Meeting notes: [Meeting notes]
Project goal: [Project goal]
Current tasks: [Current tasks]
Owners: [Owners]
Deadlines: [Deadlines]
Decisions made: [Decisions made]
Open questions: [Open questions]
Risks or blockers: [Risks or blockers]
Stakeholder expectations: [Stakeholder expectations]
Reporting cadence: [Reporting cadence]
Important constraints:
* Do not invent owners, deadlines, decisions, commitments, risks, or project facts that are not present in the supplied context.
* Separate confirmed information from assumptions.
* If an owner, deadline, decision, or dependency is unclear, mark it as “Needs confirmation.”
* Make every action item traceable to the supplied meeting notes, docs, or task list.
* Do not turn vague discussion points into confirmed commitments unless the notes support it.
* Highlight unresolved questions and missing inputs.
* Prioritize practical follow-up actions that a project manager, founder, operator, or team lead can execute.
* Include human review for public-facing, legal, financial, security, customer-impacting, or high-risk project decisions.
* Keep the dashboard concise enough to use in a weekly project review.
* If required context is missing, state the assumption clearly before continuing.
Task:
1. Summarize the project snapshot.
Explain:
* Project goal
* Current status
* Main workstreams
* Key stakeholders
* Most important recent updates
* Main risks or blockers
* Next reporting checkpoint
2. Extract action items.
Create an action register from the supplied context.
For each action item, include:
* Action item
* Owner
* Source note or evidence
* Deadline
* Priority
* Dependency
* Status
* Next step
* Confirmation needed, if applicable
3. Build a decision log.
Identify decisions that were made or appear to be pending.
For each decision, include:
* Decision
* Decision status: confirmed, proposed, pending, or unclear
* Owner or decision-maker
* Source note or evidence
* Impact
* Follow-up needed
* Date or checkpoint for review
4. Identify open questions.
List questions that must be answered before the project can move forward.
For each open question, include:
* Question
* Why it matters
* Who should answer it
* Related workstream
* Deadline or urgency
* Risk if unanswered
5. Review risks and blockers.
Create a risk and blocker tracker.
For each item, include:
* Risk or blocker
* Category
* Severity: low, medium, high, or critical
* Likelihood
* Affected workstream
* Owner
* Mitigation or next action
* Escalation needed
* Deadline for resolution
6. Create a stakeholder update.
Write a concise stakeholder-ready update that includes:
* What moved forward
* What is delayed
* What decisions were made
* What needs attention
* What help is needed
* What will happen before the next checkpoint
7. Create the project dashboard.
Build a dashboard with:
* Project status
* Workstreams
* Key milestones
* Action items
* Decisions
* Open questions
* Risks and blockers
* Owner follow-up
* Next checkpoint agenda
8. Create the next checkpoint agenda.
Recommend a practical agenda for the next project review.
Include:
* Topics to review
* Decisions needed
* Blockers to resolve
* Owners who need to report back
* Updates to confirm
* Risks to monitor
* Expected outputs from the meeting
9. Provide final recommendations.
Summarize:
* Most important next action
* Most urgent blocker
* Highest-risk assumption
* Owners needing follow-up
* Decisions needing confirmation
* What should be reviewed at the next checkpoint
Output format:
## Project Snapshot
## Action Register
## Decision Log
## Open Questions
## Risk and Blocker Tracker
## Stakeholder Update
## Project Dashboard
## Next Checkpoint Agenda
## Final Recommendations
Verification:
Before finalizing, check that:
* Every owner, deadline, decision, and commitment is traceable to the supplied context.
* Unclear items are marked as “Needs confirmation.”
* No project facts are invented.
* Action items are specific and executable.
* Risks and blockers are clearly separated.
* The stakeholder update is concise and accurate.
* The next checkpoint agenda produces decisions, not just discussion.
* Assumptions and missing inputs are listed clearly.
Begin the workspace meeting notes to project dashboard conversion now.
Produce decision-linked KPI requirements, calculation-ready metric definitions, source assessments, executable data quality test specifications, dashboard recommendations, and an evidence-based build-readiness decision.
Updated Aug 17, 2026
Develop a KPI dashboard requirements package and data quality audit from the information and evidence supplied below.
Inputs
Blocking prerequisites:
- Business goal: [Business goal]
- Dashboard audience: [Dashboard audience]
- Decisions the dashboard should support: [Decisions the dashboard should support]
- Possible KPIs: [Possible KPIs]
- Data sources: [Data sources]
- Stakeholder questions: [Stakeholder questions]
Useful supporting context:
- Current reports: [Current reports]
- Known data quality issues: [Known data quality issues]
- Update frequency: [Update frequency]
- Tools available: [Tools available]
- Definitions or formulas: [Definitions or formulas]
- Definition of done: [Definition of done]
ChatGPT operating boundaries
Use ChatGPT to inspect and synthesize only the text, tables, schemas, query results, report extracts, data dictionaries, screenshots, or files actually made available in the chat through enabled capabilities. State which materials were inspected. Do not imply that ChatGPT connected to a database, queried a BI platform, profiled a full dataset, validated a production dashboard, or changed any system unless direct execution evidence is supplied in the conversation.
You may propose metric logic, SQL or pseudocode, validation queries, dashboard requirements, test specifications, and visualization designs. Label these as proposed and unexecuted. Do not claim that a test passed or failed from a proposed query alone. Treat supplied query results or profiling outputs as execution evidence only when their source, scope, and run context are identifiable.
Do not publish, approve, deploy, edit, or certify a dashboard. Final metric approval, source-of-truth designation, access authorization, financial reconciliation, privacy review, and production release remain human responsibilities.
Input triage and missing-information rules
1. Check the blocking prerequisites before developing the package.
2. Request clarification before proceeding when the business goal, audience, supported decisions, KPI candidates, source inventory, or stakeholder questions are absent or mutually incompatible.
3. If partial progress is safe, continue with a bounded draft. Mark unresolved items as Unknown, Conflict, or Approval required; explain the consequence; and do not invent formulas, thresholds, targets, owners, benchmarks, source fields, or stakeholder priorities.
4. When definitions conflict, preserve each definition, identify its source, explain the reporting impact, and name the decision owner needed to resolve it.
5. If only metadata or sample rows are supplied, limit conclusions to that scope. Do not generalize sample observations to the complete dataset.
Evidence discipline
Classify material statements using these labels where relevant:
- Supplied fact: explicitly stated in the inputs or source material.
- Inspected observation: directly visible in supplied evidence; cite the artifact, table, field, report, or result.
- Execution evidence: result from an identified query or test that was actually run and supplied.
- Assumption: a bounded premise used to continue.
- Hypothesis: a possible explanation requiring a test.
- Unknown: information not available.
- Conflict: incompatible definitions or evidence.
- Recommendation: proposed design or action.
Keep proposed checks separate from executed checks. Never convert absence of evidence into evidence that data is complete, accurate, timely, unique, or reconciled.
Workflow
1. Establish the decision contract.
- Restate the business goal, intended audience, review cadence, decisions, and actions the dashboard must support.
- Map each stakeholder question to a decision and anticipated action.
- Define measurable dashboard success criteria from the supplied definition of done.
- Exclude metrics and content that do not influence a stated decision.
- Record open questions that could change scope or interpretation.
2. Review and prioritize KPI candidates.
Classify each candidate as Core KPI, Supporting metric, Diagnostic metric, Vanity metric, Not recommended, or Pending definition. For each candidate, document:
- stakeholder and decision served;
- management action it could trigger;
- rationale for the classification;
- placement on the main view, drill-down, supporting report, or exclusion list;
- risk of misinterpretation or gaming;
- definition status and approval owner.
Reject or defer a KPI when it lacks a decision link, stable definition, feasible source, appropriate grain, or responsible owner. Do not prefer visual appeal over decision utility.
3. Build the metric dictionary.
For every recommended KPI, specify:
- canonical metric name and aliases;
- business definition;
- formula or calculation steps;
- numerator and denominator, including zero-denominator behavior;
- unit, currency, sign convention, and rounding;
- event date or accounting date used;
- reporting grain and aggregation behavior, including whether the metric is additive, semi-additive, or non-additive;
- source system, tables or entities, required fields, and system of record status;
- join keys, expected join cardinality, deduplication rule, and late-arriving data treatment;
- filters, exclusions, cohort rules, status rules, and cancellation or refund treatment;
- dimensions and permitted segments;
- comparison period, baseline, target, or benchmark only when supplied;
- time zone, fiscal calendar, and period-closing rules;
- refresh cadence, latency tolerance, and restatement policy;
- metric owner, approver, and access restrictions;
- known caveats, unresolved conflicts, and human review requirements.
If calculation logic is missing, provide a definition template and list the exact decisions needed to complete it rather than fabricating a formula.
4. Audit source fitness.
For each source, assess the supplied evidence for:
- system and business owner;
- entities, fields, grain, date coverage, and history retention;
- extraction method and access requirements;
- freshness and refresh behavior;
- completeness, validity, uniqueness, consistency, and referential integrity;
- join keys and cardinality risks such as many-to-many inflation;
- slowly changing dimensions, mutable historical values, and snapshot availability;
- time-zone, currency, tax, unit, and fiscal-calendar handling;
- manual entry, backfill, deletion, schema-change, and source-system migration risks;
- privacy classification and whether personal, confidential, regulated, or financial data is involved;
- KPI coverage and fitness conclusion.
Rate each source as Supported by evidence, Partially supported, Unsupported, or Unknown. Include the evidence reference and confidence rationale. Do not assign a favorable rating solely because a source exists.
5. Specify data quality and reconciliation controls.
Design controls relevant to the proposed metrics, including missing required values, duplicates, invalid formats or domains, impossible values, outliers, broken joins, unexpected cardinality, inconsistent definitions, stale loads, time-zone shifts, currency or unit mismatches, manual-entry errors, historical gaps, schema drift, and source changes.
For each control, provide:
- control identifier and related KPI;
- failure mode and business consequence;
- fields, grain, scope, and comparison period;
- proposed SQL, pseudocode, or reproducible test procedure when feasible;
- threshold and its provenance; if not supplied, mark Threshold awaiting owner approval and optionally offer a clearly labeled candidate for discussion;
- expected observation;
- actual observation only when execution evidence is supplied;
- evidence reference and run timestamp if supplied;
- owner, severity, escalation route, and remediation action;
- retest requirement and status: Proposed, Executed-pass, Executed-fail, Blocked, or Not run.
Include reconciliation controls where applicable, such as dashboard totals versus ledger, billing platform, CRM, warehouse, or an approved existing report. Define acceptable variance only from supplied policy; otherwise leave it pending approval.
6. Design the dashboard information architecture.
Recommend a practical structure for the available BI tool and team capacity:
- executive decision summary;
- core KPI scorecards with period comparison and freshness status;
- trend analysis;
- approved segment breakdowns;
- diagnostic drivers and drill paths;
- data quality, reconciliation, and refresh indicators;
- metric definitions, assumptions, caveats, and last-updated details.
For each section, state the user question, metric, grain, default filters, visualization, interaction, drill-down, and reason for inclusion. Address misleading axes, truncated scales, dual-axis confusion, inappropriate aggregation, excessive precision, inaccessible color use, small-sample disclosure, and comparisons across incomplete periods.
7. Create implementation requirements and traceability.
Translate the design into requirements with:
- requirement identifier;
- stakeholder need and supported decision;
- metric or control dependency;
- source and required fields;
- transformation or semantic-layer requirement;
- visualization or interaction requirement;
- priority and rationale;
- accountable owner and approver;
- dependency, privacy or access constraint, and failure impact;
- acceptance criterion and required evidence;
- status: Ready, Blocked, Pending clarification, or Pending approval.
Maintain traceability from stakeholder decision to KPI, metric definition, source, quality control, dashboard component, and acceptance criterion. Flag every broken link.
8. Determine build readiness.
Choose exactly one status:
- Ready to build: every core KPI has an approved calculation-ready definition, identified source and fields, acceptable source evidence, approved access, specified controls, resolved critical conflicts, and testable acceptance criteria.
- Ready for prototype only: enough information exists for a non-production prototype, but definitions, evidence, access, controls, or approvals remain incomplete.
- Ready after minor fixes: bounded issues have owners and do not threaten core metric validity once corrected and retested.
- Not ready: unresolved issues could materially change KPI values, expose protected data, break reconciliation, or mislead decisions.
Provide criterion-by-criterion evidence for the selected status. A proposed test is not proof of readiness. If no profiling or reconciliation results were supplied, explicitly state that data quality remains unverified and limit the readiness claim accordingly.
Safety and stop conditions
- Do not request or reproduce passwords, API keys, connection strings, or unnecessary personal data.
- Prefer schemas, aggregated extracts, masked samples, and field-level profiling over row-level sensitive records.
- Stop and request human review if the design may expose personal or regulated data, permit re-identification, conflict with access policy, or use sensitive attributes for segmentation without authorization.
- Require finance or accounting owner approval for revenue, margin, cash, tax, or investor metrics and reconciliation.
- Require legal, privacy, compliance, or regulatory review when applicable.
- Do not recommend production release when a critical KPI definition, source lineage, reconciliation, access approval, or severe data quality issue is unresolved.
- Preserve current approved reports and definitions until authorized replacements are validated; recommend versioning and rollback to the last approved dashboard or metric definition for implementation handoff.
Required output
## 1. Scope and Materials Inspected
List supplied materials actually inspected, unavailable evidence, scope limitations, assumptions, unknowns, and conflicts.
## 2. Dashboard Decision Contract
Summarize goal, audience, cadence, decisions, actions, exclusions, success criteria, and blocking questions.
## 3. Stakeholder Decision Matrix
Provide a table with Stakeholder, Decision, Question, Required evidence, Review cadence, Trigger condition, Likely action, and Confirmation status.
## 4. KPI Prioritization Register
Provide a table with KPI, Classification, Decision link, Actionability, Main view or drill-down placement, Definition status, Misinterpretation risk, Owner, and Recommendation.
## 5. Metric Dictionary
Provide the complete calculation and governance fields defined in the workflow. Use TBD only with a named resolution question and owner.
## 6. Source Fitness and Lineage Matrix
Provide source-level assessments, evidence references, KPI coverage, join and grain risks, privacy constraints, confidence, and fitness status.
## 7. Data Quality and Reconciliation Control Register
Separate proposed controls from supplied execution results. Include expected versus actual observations, evidence, severity, owner, response, retest requirement, and status.
## 8. Dashboard Information Architecture
Describe sections, user questions, metrics, filters, visuals, interactions, drill paths, caveats, freshness indicators, and accessibility considerations.
## 9. Requirements and Traceability Matrix
Connect every requirement from stakeholder decision through KPI, source, control, dashboard component, acceptance criterion, evidence requirement, owner, and handoff status.
## 10. Readiness Decision
State one allowed readiness status, criterion-level evidence, blockers, approvals, residual risks, and the conditions required to advance.
## 11. Verification and Acceptance Checklist
For each acceptance check, include Check, Expected result, Actual result, Evidence, Owner, and State. Use Not run or Blocked when no execution evidence exists. At minimum verify:
- every core KPI has a stakeholder decision and action;
- definitions specify grain, formula, filters, time handling, and ownership;
- source grain and joins cannot silently duplicate or omit values;
- core metrics reconcile to an approved reference where required;
- refresh timing meets the stated decision cadence;
- visuals use valid aggregation and comparison periods;
- privacy and access requirements are approved;
- critical controls have executed evidence before production acceptance.
## 12. Handoff Plan
Prioritize clarification, definition approval, access work, remediation, test execution, prototype work, stakeholder review, and production approval. Name owners where supplied and preserve unknown owners as unassigned.
Final integrity check
Before returning the package:
- ensure no unsupported benchmark, formula, threshold, owner, result, or approval is presented as fact;
- ensure observations identify their supplied evidence and scope;
- ensure proposed, executed, blocked, unverified, approved, and completed states remain distinct;
- ensure dashboard recommendations do not outrun source fitness or data quality evidence;
- ensure the readiness decision agrees with the unresolved blockers and acceptance checklist;
- ensure consequential financial, privacy, compliance, executive, investor, or customer-facing reporting is assigned human review.
