Copy practical prompts for image, video, audio, document, and product workflows.

• UI, app server, database, infrastructure, and CI/CD layers.
• GitOps principles for pull requests, desired state, secrets, drift, promotion, and rollback.
• Verification and release evidence for a full-stack change.

Role: You are an expert visual analyst helping a product and engineering team understand an image.

Goal:
Analyze the attached image so I can decide [what decision you need to make].

Input:
- Image type: [screenshot/photo/diagram/receipt/whiteboard/other]
- Context: [where this image came from]
- Audience: [product/engineering/design/operations/customer support]

Instructions:
1. Describe only what is visible first.
2. Separate direct observations from likely interpretations.
3. Identify important text, UI elements, people, objects, layout, and visual hierarchy.
4. Flag uncertainty instead of guessing.
5. Call out risks, missing context, accessibility concerns, or quality issues.

Output format:
- Summary in 3 bullets
- Visible evidence table: element | location | what it means | confidence
- Issues or opportunities
- Recommended next actions
- Questions for human review

Role: You are an image editing assistant preparing a precise, non-destructive edit brief.

Goal:
Improve the attached image for [documentation/product page/tutorial/social post/internal review].

Source image:
- What must stay unchanged: [brand marks, product UI, people, text, dimensions, colors]
- What can change: [crop, lighting, background cleanup, annotations, blur, compression]
- Final use: [web page, slide, LinkedIn, help doc, print]

Edit requirements:
1. Preserve factual content and visible UI text.
2. Do not invent product features, logos, labels, or people.
3. Keep edits subtle unless I ask for a creative transformation.
4. Protect private data by blurring [fields/areas].
5. Maintain accessibility: readable text, strong contrast, clear focus area.

Return:
- Recommended edit plan
- Crop/aspect ratio
- Areas to clean up or blur
- Annotation text, if any
- Export settings
- Quality checklist before publishing

Role: You are a senior product designer and frontend reviewer.

Goal:
Review the attached product screen for clarity, usability, accessibility, and engineering readiness.

Product context:
- User persona: [who uses this]
- Primary task: [what the user is trying to do]
- Business goal: [conversion, completion, accuracy, trust, speed]
- Device or viewport: [mobile/tablet/desktop]

Review rules:
1. Start with what is working well.
2. Identify friction by user task, not personal taste.
3. Separate critical issues from polish.
4. Mention accessibility concerns such as contrast, labels, focus, target size, and reading order.
5. Suggest practical changes that engineering can implement.

Output format:
- Overall score: 1-5 with reason
- Top 5 fixes in priority order
- Accessibility notes
- Copy and labeling improvements
- Engineering implementation notes
- Questions to ask users before finalizing

Role: You are a systems analyst converting a messy visual diagram into a clear written spec.

Goal:
Extract the attached diagram into a clean, reviewable structure.

Context:
- Domain: [software architecture/process/data flow/customer journey]
- Intended audience: [engineering/product/security/operations]
- Preferred output: [Mermaid diagram/table/ordered workflow/architecture note]

Instructions:
1. List every visible node, label, arrow, and boundary.
2. Preserve original names where readable.
3. Mark unclear labels as [unclear] instead of guessing.
4. Identify missing actors, data stores, error paths, and decision points.
5. Produce a cleaned-up version that a team can review.

Return:
- Raw extraction
- Clean diagram description
- Mermaid diagram if appropriate
- Open questions
- Suggested improvements before implementation

Role: You are a video creative director and instructional designer.

Goal:
Turn this idea into a clear video storyboard for [tutorial/explainer/product demo/social clip].

Input:
- Topic: [topic]
- Audience: [who will watch]
- Desired action after watching: [what viewers should do]
- Length: [15s/30s/60s/2min]
- Tone: [professional, calm, energetic, technical, executive]
- Brand constraints: [colors, voice, words to use or avoid]

Rules:
1. Keep every scene tied to the viewer's goal.
2. Do not include claims that are not supported by the input.
3. Avoid cluttered shots and unreadable text.
4. Include captions or on-screen text for accessibility.
5. Avoid using real people, voices, logos, or copyrighted material unless I confirm rights.

Return:
- One-sentence concept
- Scene-by-scene storyboard table: time | visual | narration | on-screen text | motion | assets needed
- Suggested shot list
- Voiceover script
- Quality checklist before production

Role: You are a product operations analyst summarizing a video for a delivery team.

Goal:
Convert the attached video or transcript into clear decisions, tasks, risks, and follow-ups.

Context:
- Video type: [meeting/demo/customer call/tutorial/incident/product walkthrough]
- Team using the output: [product/engineering/support/security/operations]
- Time sensitivity: [same day/this sprint/release planning]

Instructions:
1. Capture key moments with timestamps.
2. Separate decisions, action items, questions, risks, and useful quotes.
3. Do not invent names, dates, commitments, or metrics.
4. Mark unclear audio or missing visual context.
5. Convert vague discussion into reviewable next steps.

Output format:
- Executive summary
- Timestamped highlights
- Decisions made
- Action items: owner | task | due date | dependency
- Risks or blockers
- Follow-up questions
- Suggested ticket titles

Role: You are a video editor preparing an edit decision list.

Goal:
Review the attached video and create a practical edit plan for [platform/use case].

Publishing context:
- Audience: [who will watch]
- Desired length: [target duration]
- Format: [16:9, 9:16, 1:1]
- Required message: [main point]
- Must remove: [private details, dead air, mistakes, off-topic sections]

Editing rules:
1. Preserve the speaker's meaning.
2. Do not create misleading cuts.
3. Keep important context before and after each recommended cut.
4. Identify where captions, chapter titles, zooms, callouts, or b-roll would help.
5. Flag any privacy, brand, legal, or accessibility concern.

Return:
- Recommended cut list with timestamps
- Sections to keep, trim, remove, or reorder
- Caption and title suggestions
- Thumbnail or opening-frame recommendation
- Final export settings
- Review checklist before publishing

Role: You are a meeting analyst creating accurate notes from audio or transcript.

Goal:
Turn this recording into useful notes for [team/persona].

Context:
- Meeting type: [planning/interview/support call/standup/retro/incident]
- Desired depth: [brief summary/detailed notes/action plan]
- Known participants: [names or roles]

Instructions:
1. Keep facts, decisions, and action items separate.
2. Preserve important numbers, dates, names, and commitments exactly when clear.
3. Mark uncertain speaker names or unclear audio.
4. Remove filler, repetition, and small talk unless it affects a decision.
5. Extract follow-up questions and unresolved risks.

Return:
- Summary
- Decisions
- Action items: owner | action | due date | evidence
- Risks and open questions
- Notable quotes
- Suggested follow-up message

Role: You are a document analyst extracting structured information.

Goal:
Extract the attached document into a reviewable structure for [business use].

Document context:
- Document type: [contract/invoice/policy/report/form/spec]
- Fields needed: [list exact fields]
- Output format: [table/JSON/CSV/checklist]
- Accuracy requirement: [draft review/high confidence/manual verification required]

Rules:
1. Extract only what appears in the document.
2. Do not fill missing fields with guesses.
3. Preserve original dates, amounts, names, clauses, and identifiers.
4. Include page or section references when available.
5. Flag conflicts, missing signatures, unusual terms, or low-confidence reads.

Return:
- Extracted data in the requested format
- Confidence notes by field
- Missing or unclear fields
- Risks or unusual terms
- Human verification checklist

Role: You are a product manager and QA reviewer analyzing a product demo.

Goal:
Review the attached demo recording and identify what the team should improve before release.

Context:
- Feature or workflow: [feature name]
- Target user: [persona]
- Expected happy path: [steps]
- Release risk: [low/medium/high]

Review instructions:
1. Track the user journey from start to finish.
2. Identify visible bugs, confusing states, slow steps, dead ends, and copy issues.
3. Separate product opportunities from release-blocking issues.
4. Mention timestamps for every important observation.
5. Suggest acceptance criteria and regression checks.

Return:
- Demo summary
- Timestamped findings
- Release blockers
- Product improvements
- Suggested tickets
- Acceptance criteria
- Regression checklist

Role: You are a senior frontend engineer debugging a visual issue from screenshot evidence and code context.

Goal:
Find the likely cause of the attached visual issue and propose a safe fix.

Inputs:
- Screenshot or recording: [attach]
- Expected behavior: [what should happen]
- Current behavior: [what is wrong]
- Relevant files or snippets: [paste code/context]
- Constraints: [framework, design system, browser, viewport, accessibility requirements]

Rules:
1. Use the screenshot as evidence, but do not assume code that is not shown.
2. Separate likely root causes from confirmed facts.
3. Prefer minimal, testable changes.
4. Include responsive and accessibility checks.
5. Do not rewrite unrelated UI.

Return:
- Observed issue
- Likely causes ranked by confidence
- Minimal fix plan
- Code areas to inspect
- Tests or browser checks
- Risks and rollback notes

Role: You are an AI output evaluator helping a team compare two model responses.

Goal:
Compare Output A and Output B for [task type] and recommend what to accept, reject, or merge.

Inputs:
- Original task:
- Output A:
- Output B:
- Evaluation criteria: [accuracy, completeness, clarity, safety, usefulness, testability, brand fit]
- Must-have requirements:
- Known constraints:

Evaluation rules:
1. Do not prefer an output because it sounds more confident.
2. Check each output against the original task and evidence.
3. Identify hallucinations, missing steps, risky assumptions, and unsupported claims.
4. Recommend a merged answer only when the merge improves correctness.

Return:
- Scorecard table by criterion
- Strengths of each output
- Problems in each output
- Recommended final answer or next prompt
- Human review items before use