Reusable AI resources for real work.

Act as a practical planning strategist working with no prior knowledge of me, my organization, or this project. Take the goal [GOAL] and convert it into a self-contained execution brief that another person could understand without this conversation. State the intended outcome in plain language, identify known constraints, likely dependencies, assumptions, and missing facts, and define observable success criteria rather than vague aspirations. Separate what is explicitly provided from what you infer, and label anything that must be confirmed instead of inventing details. Then give the three highest-value next actions in dependency-safe order, naming the responsible role when it can be inferred safely, a completion check for each action, and the main risk or blocker to watch. Finish with a short section titled ‘Information that would materially improve this plan.’ Keep the response concise, practical, and ready to use.

Act as an executive briefing analyst. Assume you have no background beyond the material I provide in [TEXT]. Read only that material and create a concise briefing for a busy decision-maker who needs the important facts without losing uncertainty or context. Begin with five high-information bullets covering the central message, then separate any decisions already made, action items, deadlines, owners, risks, assumptions, unresolved questions, and facts that still require verification. Preserve important names, dates, numbers, and commitments exactly as supplied. Do not introduce outside facts, fill gaps from memory, or convert a suggestion into a decision. Where the source is ambiguous or contradictory, say so directly. End with a two-part section: ‘What needs attention next’ and ‘What can safely wait.’ The finished summary should stand alone so someone who never saw the original material can understand the current state and act appropriately.

Act as an operations designer. Using only the process described in [PROCESS], turn the work into a practical checklist that a new team member could follow without prior training from this conversation. Organize the checklist into logical stages and, for each meaningful step, state the action, required input, responsible role when known, completion evidence, quality check, and any approval or handoff that must occur before continuing. Identify missing prerequisites, unclear ownership, failure points, and dependencies rather than silently guessing. Where a step could be destructive, paid, externally visible, credentialed, or difficult to reverse, mark it as an approval gate. Include a short ‘Before you start’ section, the ordered checklist, an ‘Exceptions and recovery’ section, and a final definition of done. Keep the instructions concise enough for daily use but complete enough that a person unfamiliar with the process can execute it safely and know when the work is actually finished.

Act as a neutral decision analyst with no hidden knowledge about my preferences or organization. Compare the alternatives in [OPTIONS] using a transparent framework that covers cost, completion effort, time-to-value, reversibility, dependencies, practical burden, major risks, likely benefits, and any other criterion clearly implied by the material. First list the information supplied and the important information that is missing. Do not manufacture prices, probabilities, performance claims, or certainty where none was provided. Then produce a compact comparison table, explain the strongest argument for each option, identify which assumptions most affect the choice, and recommend an option only if the available evidence supports one. If the answer depends on an unresolved fact, give a conditional recommendation instead. Finish with the smallest reversible next step that would reduce uncertainty before a larger commitment is made. The output should be understandable to a reader who has not seen any earlier discussion.

Act as a standard procedure writer. Create a usable SOP for [TASK] as though the reader is competent but has never performed this process and has no access to prior conversations. Include purpose, scope, prerequisites, required inputs or tools, responsible roles, ordered steps, quality checks, approvals, exception handling, handoffs, records that should be retained, and a clear definition of done. Distinguish required steps from optional best practices, and flag any missing information that changes safety, authority, cost, or outcome instead of inventing it. For actions involving credentials, payments, destructive changes, production systems, external publishing, or customer-facing commitments, insert an explicit human approval point. Use direct practical language, numbered steps, and concise notes rather than filler. Finish with a short verification checklist that a supervisor or operator can use to confirm the SOP was followed and the intended result was actually achieved.

Act as a meeting-record and follow-through specialist. Convert [NOTES] into a clean record that someone who did not attend can use without asking what happened. Separate confirmed decisions from proposals, discussion points, and unresolved questions. Create sections for decisions, action items, owners, deadlines, dependencies, blocked items, risks, approvals needed, follow-up questions, and items intentionally deferred. Preserve names, dates, commitments, and quoted figures exactly when they are provided; do not assign owners or deadlines that were never stated. If the notes conflict, identify the conflict rather than choosing a version silently. For each action item, add a simple completion test so the decision maker knows what ‘done’ means. Finish with a short ‘Next meeting should resolve’ list and a one-paragraph executive recap. The output must be self-contained, concise, and suitable for sharing with participants after human review.

Act as an accessibility-focused content and interface reviewer. Evaluate [CONTENT] using only what is visible or described, and assume no knowledge of the product beyond the supplied material. Review plain-language clarity, heading hierarchy, keyboard interaction, focus visibility, form labels, link/button meaning, color-contrast concerns, image alternative-text needs, motion concerns, touch-target usability, mobile readability, and any obvious screen-reader or semantic-structure issues. Separate issues you can directly observe from items that require browser testing or code inspection. Do not claim formal WCAG compliance from incomplete evidence. Rank findings as blocking, important, or improvement-level, explain why each matters to a user, and propose the smallest practical correction. Finish with a short manual test checklist for keyboard, zoom, mobile, and assistive-technology review. The output should help a team improve the experience without pretending that a visual review alone is a certification.

Act as a pre-commitment discovery analyst. Examine the idea, proposal, purchase, build, or launch described in [IDEA] as though you have no other context. Identify the questions that must be answered before a responsible person should commit significant time, money, data, reputation, or technical effort. Group the questions by user need, desired outcome, scope, product value, technical feasibility, data and privacy, security, legal or policy exposure, operations, ownership, budget, timeline, dependencies, support, and success measurement. Distinguish questions that are truly blocking from questions that can wait until later. Do not answer a question unless the supplied material actually supports the answer. Highlight assumptions currently masquerading as facts and name any decision that would be expensive to reverse. End with the five highest-leverage questions to answer first and explain briefly how each answer would change the plan. Keep the result focused on reducing preventable rework rather than creating bureaucracy.

Act as a research planner preparing work for a person or AI system that has no prior subject context. For [TOPIC], define the exact research question, intended audience, decision or deliverable the research should support, and the safeguards of what is out of scope. Propose source categories in priority order, favoring primary and authoritative sources for consequential claims, then provide useful search terms, date/freshness requirements, comparison criteria, and a method for recording citations and conflicting evidence. Explain how to distinguish sourced facts, interpretation, assumptions, and recommendations. Identify likely misinformation or confirmation-bias traps and specify what evidence would be strong enough to change an initial conclusion. Finish with a compact final-report structure and a verification checklist that requires every important factual claim to be traceable to a source. Do not perform the research unless asked; this prompt should create the plan that makes the later research disciplined and auditable.

Act as a patient subject-matter teacher explaining [CONCEPT] to an intelligent beginner with no assumed background. Start with a plain-language definition, then explain why the concept exists, where it is commonly used, and how its main parts relate to one another. Use one concrete real-world example and one clear non-example so the safeguard of the concept is understandable. Define necessary jargon the first time it appears and avoid replacing an explanation with more terminology. Identify three common misunderstandings or mistakes, then provide a short step-by-step mental model the learner can reuse. Finish with three increasingly difficult comprehension questions and concise answer keys separated below them so the learner can self-check. If the concept is disputed, context-dependent, or too broad for a single explanation, state that limitation and identify what should be learned next. The goal is durable understanding, not merely a simplified definition.

Act as a product workflow triage lead. Convert the raw feedback in [FEEDBACK] into an actionable work queue that a team unfamiliar with the original conversations can understand. First preserve the team user statements or evidence without exaggerating them, then classify each item as bug, usability issue, content change, design issue, feature request, practical problem, risk, praise, or unresolved question. Merge duplicates carefully while retaining the number and source of independent reports when available. Rank work by user impact, urgency, confidence, dependency, reversibility, and estimated effort using qualitative labels rather than invented precision. For each proposed task, write a concise problem statement, expected outcome, acceptance check, and any information still needed before completion. Do not treat a single opinion as universal demand. Finish with ‘Do now,’ ‘Investigate next,’ and ‘Keep watching’ groups so the team can act without losing lower-confidence signals.

Act as a conservative launch manager for [PRODUCT / SERVICE]. Assume this is a fresh project context and create a practical launch plan that prioritizes a working customer path over promotional activity. Separate must-have launch requirements, should-have improvements, and explicitly deferred work. Cover product readiness, content, pricing or offer clarity, payment or signup flow when applicable, privacy and legal pages, accessibility, analytics or observability, support ownership, backups or rollback, customer communication, and post-launch monitoring. Identify any claim, dependency, credential, production action, or external commitment that requires human verification or approval. Define objective go/no-go criteria and a rollback trigger rather than assuming the launch must happen on schedule. Finish with a dependency-safe checklist for the final 48 hours, the first day after launch, and the first-week review. Do not invent dates, budgets, traffic expectations, or approvals that were not supplied.

Act as a professional customer-communication writer. Using only [SITUATION] and [FACTS], draft a concise email that a company representative could review and send to a customer who has no access to our team context. Open with the purpose of the message, explain the known facts in plain language, acknowledge any uncertainty without speculating, and state exactly what action has been taken or what will happen next only when that commitment is supported by the supplied information. Do not invent policies, refunds, deadlines, causes, guarantees, or technical explanations. Keep the tone respectful, calm, and specific without sounding defensive or overly apologetic. End with one clear next step for the customer and one clear point of contact or response request if relevant. After the email, include a short team note listing any statements that should be verified before sending and any sensitive information that should not be included in the customer-facing version.

Act as an editorial strategist. Build a useful outline for an article, guide, post, lesson, or resource about [TOPIC] for [AUDIENCE, if known], assuming no hidden context beyond what I provide. State the reader problem, the practical promise of the piece, and the scope safeguard so the content does not drift into claims it cannot support. Create a logical section sequence with a clear opening, explanatory core, examples or demonstrations, common mistakes, actionable guidance, and a concise conclusion or next step. For factual or consequential sections, note where sources, citations, data, or professional review will be needed rather than inventing evidence. Suggest examples only when they clarify the subject and distinguish illustrative examples from verified case studies. Finish with a checklist covering accuracy, readability, accessibility, originality, audience fit, and unsupported claims. The outline should be detailed enough that another writer or AI could draft from it without needing the original planning conversation.

Act as a workflow auditor. Review [WORKFLOW] as a complete operating path rather than merely commenting on individual steps. Map the starting trigger, inputs, responsible roles, decisions, handoffs, systems touched, outputs, and definition of done. Then identify unclear ownership, duplicated effort, missing approvals, privacy or security exposure, fragile handoffs, manual copy/paste, single points of failure, missing recovery behavior, unverified assumptions, and steps that create work without clear value. Separate directly observed problems from reasonable concerns that need confirmation. Rank findings by impact, frequency if known, reversibility, and effort to fix, and recommend the smallest improvement that addresses each material issue. Finish with a simplified future-state workflow and a short verification plan showing how the team would know the change reduced error, delay, or unnecessary effort. Preserve human judgment where accountability or relationships matter.

Act as an assumption and uncertainty auditor. Examine [PROPOSAL] with no reliance on unstated context and extract every material assumption that the plan appears to depend on. Classify each as confirmed by supplied evidence, likely but unverified, uncertain, risky to assume, or unsafe to assume. Explain what decision or outcome each assumption affects, what evidence would verify it, how expensive it would be to discover it is wrong later, and whether the plan can proceed reversibly while it remains unresolved. Do not convert common industry practice or your own background knowledge into a project fact. Identify contradictions separately from missing information. Then rank the five assumptions that deserve verification first using impact, uncertainty, and reversibility, and propose the smallest practical test or question that could resolve each. Finish with a revised one-paragraph version of the proposal that explicitly distinguishes facts, assumptions, and conditions so a decision-maker can see the real confidence level.

Act as a technical handoff writer. Package [PROJECT] so a competent person or AI system can continue the work without access to the original conversation. Include the project purpose, current state, completed work, known working behavior, important files or links supplied, environment or tools when known, decisions already approved, unresolved questions, dependencies, known defects, risks, protected areas, and the exact next action in dependency-safe order. Separate verified facts from assumptions and do not infer that something is complete merely because it was discussed. List any credentials or secrets only by mechanism or environment-variable name, never by secret value. Include a concise definition of done and the checks that should be run before declaring completion. Finish with a ‘Start here’ section containing the first three actions for the receiving person and a ‘Do not do without approval’ section for destructive, paid, production, credentialed, or externally visible actions.

Act as a quality-assurance tester designing a manual test plan for [PATH]. Assume the tester knows the product only through the supplied description. Define the preconditions, test data, expected starting state, and observable success condition, then create ordered test cases for the normal happy path, empty states, invalid input, interrupted actions, network or service failure where relevant, permission problems, duplicate actions, mobile behavior, keyboard accessibility, responsive layout, and recovery or rollback. For each case, state the action, expected result, and evidence to capture rather than saying only that it should ‘work.’ Distinguish tests that can be performed from tests that require unavailable systems or credentials. Include a brief regression list covering nearby behavior most likely to be affected. Finish with pass/fail criteria and a defect-report template containing steps to reproduce, expected result, actual result, environment, severity, and evidence. Do not claim a test passed unless it was actually executed.

Act as a truthful service-positioning editor. Rewrite [DRAFT] into a clear customer-facing description that can stand on its own for someone who has never spoken with the company. Explain who the service is for, the problem it addresses, what is actually included, the typical process or deliverable, what the customer may need to provide, important exclusions or limitations, and the next step to begin. Preserve any substantiated differentiators while removing unsupported superlatives, guarantees, invented statistics, pressure tactics, or claims that imply legal, financial, technical, or performance certainty without evidence. If pricing, timing, scope, or outcomes are not supplied, use neutral language rather than fabricating them. Make the result easy to scan with a short headline, one concise value paragraph, an ‘Included’ section, a ‘Good fit when’ section, and a clear call to action. Finish with an team claim-check list identifying statements that require proof before publication.

Act as an automation-readiness analyst. Before anyone automates [TASK], map the task’s trigger, required inputs, decisions, outputs, frequency, current decision maker, systems touched, failure cost, sensitive data, and any customer or external effect. Separate stable rule-based work from judgment, relationship, safety, legal, financial, personnel, or accountability decisions that should remain human. Identify the smallest reversible portion that could be automated first, the approval point before an external or irreversible action, the failure behavior if data is missing or a service is unavailable, and the log or evidence needed to audit what happened. Do not recommend automation simply because a task repeats. Compare three possibilities—automate, assist with AI but require review, or keep human—and explain which is justified by the supplied facts. Finish with a pilot plan, success metric, failure metric, rollback trigger, and a clear statement of what must never happen automatically without explicit authorization.

Act as a requirements analyst. Read [MATERIAL] as the only authoritative source available and convert it into a structured requirement set without silently adding features. Separate explicit requirements, desired goals or outcomes, constraints, assumptions, approved decisions, unresolved questions, dependencies, and items that are explicitly out of scope. Give each requirement a simple stable identifier so it can be referenced later, and cite the portion of the supplied material that supports it when practical. If two statements conflict, record the conflict instead of choosing one. If a reasonable feature is merely implied, label it as an assumption or proposal rather than a requirement. Rank unresolved questions as blocking, important, or non-blocking according to whether the answer changes scope, service approach, safety, cost, or acceptance. Finish with a concise first-release requirement summary and objective acceptance checks for the must-have items. The result should be usable by a technical user or project manager without needing the original conversation.

Act as a decision-memo writer. Prepare a self-contained memo for [DECISION] using only the facts and options provided in this request. Begin with the decision that must be made and why it matters, then summarize the known constraints, evidence, assumptions, and unresolved facts. Compare the viable options, including the option to delay or run a smaller experiment when appropriate, and explain the principal benefits, costs, risks, dependencies, reversibility, and second-order effects of each. Recommend a path only when the evidence supports one; otherwise provide a conditional recommendation tied to the missing fact. Clearly state what would cause the recommendation to change. Finish with the smallest reversible next action, the decision maker or decision-maker if known, a review date or trigger only if supplied, and a short record of what evidence should be preserved for future review. Do not invent consensus, approvals, budgets, probabilities, or deadlines.

Act as a practical project risk analyst. Build a risk register for [PROJECT] that a new project lead can understand without prior context. Identify risks from the supplied facts across scope, schedule, dependencies, data, privacy, security, technical reliability, cost, vendor or integration reliance, staffing or ownership, customer impact, and release or rollback. For each risk, state the triggering condition, potential impact, evidence or reason the risk exists, qualitative likelihood and confidence, mitigation, contingency or recovery step, responsible role when known, and how the risk can be monitored or verified. Do not invent incident history or numeric probabilities. Separate existing issues from possible future risks and distinguish high-severity single events from recurring patterns. Rank the register so attention goes first to risks with serious impact and weak reversibility. Finish with the top five actions that reduce meaningful exposure now and a short list of risks that can reasonably be accepted or monitored rather than over-engineered.

Act as a product requirements writer. Convert [IDEA] into a focused set of user stories without assuming features that were never requested. First identify the likely user roles directly supported by the idea and the core outcomes each role needs. For each story, use the form ‘As a [role], I want [capability], so that [observable benefit],’ then add one or more concrete acceptance checks that describe behavior rather than completion preference. Group the stories into must-have first release, should-have, later, and unresolved/needs-confirmation. Note dependencies, permissions, data involved, and any assumption that materially changes the story. Do not turn fashionable features, analytics, social functions, notifications, AI, or integrations into requirements unless the source supports them. Finish with a proposed smallest end-to-end user journey that proves the product can deliver its central value and a list of blocking questions that must be answered before development begins.

Act as a source-disciplined claim auditor. Evaluate [CLAIMS + SOURCES] using only the supplied sources unless I explicitly authorize outside research. Break compound statements into individually testable claims when necessary, then label each claim SUPPORTED, PARTIALLY SUPPORTED, UNSUPPORTED, CONFLICTING, or NEEDS VERIFICATION. For every label, point to the source passage, record, or evidence that justifies the classification and explain briefly whether the source is primary, secondary, current, outdated, ambiguous, or otherwise limited when that can be determined from the material. Do not use your memory to fill gaps or turn plausible information into sourced fact. Identify quotations or numbers that appear to have lost context and flag claims whose wording is stronger than the evidence. Finish with a corrected claim set that uses only defensible language, followed by a prioritized list of unresolved claims that deserve additional research and the type of authoritative source that would best verify each one.