Business
Quarterly decision brief
INTENT: Help the leadership team decide whether to continue the pilot. CONTEXT: [paste pilot metrics and customer notes] The pilot has run for one quarter; separate observed results from customer opinions. INSTRUCTION: Summarise evidence for continuation, change or stop. CONSTRAINTS: Do not infer causation. Preserve metric definitions and flag missing baselines. OUTPUT: Recommendation, evidence table, risks and decision questions. VALIDATION: Check every number against the supplied metrics and list unsupported conclusions.
Why this works: The decision, evidence boundary and review shape are explicit, so the brief supports a real choice rather than a generic summary.
Process handoff
INTENT: Give the next operator a reliable handoff for today's unresolved work. CONTEXT: [paste ticket list and notes] The next operator has 30 minutes and can change status but cannot approve refunds. INSTRUCTION: Group the work by urgency and write the next action for each item. CONSTRAINTS: Do not close a ticket without evidence. Keep customer identifiers exactly as supplied. OUTPUT: Priority table with ticket, evidence, owner and next action. VALIDATION: Flag missing owners, missing evidence and any item needing approval.
Why this works: Context, authority limits and validation make the handoff useful to another person and safer to act on.
Management
One-to-one preparation
GOAL: Help a manager prepare a constructive 30-minute one-to-one. CONTEXT: [paste role description and recent notes] The employee has asked to discuss priorities and support. ACTION: Draft five open questions and a two-item agenda. OUTPUT: Agenda first, then questions with the purpose of each. CONSTRAINTS: Do not diagnose performance or infer feelings from silence. VALIDATION: Mark questions that rely on an assumption not present in the notes.
Why this works: The goal and boundaries keep the model from turning sparse notes into a performance judgement.
Team planning
INTENT: Turn the team's committed work into a realistic fortnight plan. CONTEXT: [paste backlog and capacity notes] Four people are available for 10 working days; production incidents take priority. INSTRUCTION: Group work by dependency, identify a critical path and propose a plan. CONSTRAINTS: Do not schedule more capacity than stated. Mark estimates as estimates. OUTPUT: Plan by day, dependency list and risks requiring a manager decision. VALIDATION: Recheck capacity totals and list every assumption.
Why this works: Capacity is context and a hard constraint; validation checks arithmetic instead of rewarding a confident schedule.
Information Technology
Architecture review
INTENT: Identify the two largest operational risks in this proposed service architecture. CONTEXT: [paste architecture diagram and requirements] The service must support the stated traffic range and a weekday on-call team. INSTRUCTION: Trace request flow, identify failure points and compare each with the requirements. CONSTRAINTS: Use only the supplied design. Distinguish a design gap from a missing diagram detail. OUTPUT: Risk table with component, failure mode, evidence, impact and open question. VALIDATION: Cite the diagram or requirement for each risk and mark unsupported assumptions.
Why this works: The source boundary and failure-oriented output make the review specific without pretending to know an undocumented deployment.
Runbook draft
INTENT: Help an on-call engineer recover the documented service failure safely. CONTEXT: [paste incident notes and approved runbook fragments] The engineer may restart the worker but may not change database schema. INSTRUCTION: Order the diagnostic and recovery steps, with a stop condition after each risky action. CONSTRAINTS: Do not invent commands. Preserve rollback steps and escalation contacts. OUTPUT: Numbered runbook with prerequisites, steps, stop conditions and escalation. VALIDATION: Check every command against the supplied fragments and flag any missing prerequisite.
Why this works: Role and permission context plus stop conditions turn prose into a safer operational artefact.
Marketing
Campaign brief
INTENT: Plan a 30-day campaign that increases qualified demo requests from practice owners. CONTEXT: [paste product notes and existing campaign results] Team: one marketer half-time. Audience: private dental practices with 2–6 chairs. INSTRUCTION: Propose channels, messages, weekly activities and a measurement plan. CONSTRAINTS: Budget is $5,000. No paid search or new engineering. Do not claim results not in the source. OUTPUT: Strategy, weekly plan, budget table, message examples and measures. VALIDATION: Check activities against budget and staffing and list assumptions.
Why this works: The campaign has a buyer, resource boundary, exclusions and measurement shape rather than a request for generic ideas.
Customer story interview
INTENT: Prepare an interview guide that reveals why a customer adopted the product. CONTEXT: [paste account notes] Interview length: 30 minutes. The customer has agreed to discuss workflow, not confidential finances. INSTRUCTION: Write eight open questions in a logical sequence. CONSTRAINTS: Do not lead the customer toward a preferred answer. Avoid questions about restricted information. OUTPUT: Question, purpose and optional follow-up for each item. VALIDATION: Flag any question that assumes a benefit or asks for restricted information.
Why this works: The goal, interview context and ethical constraints produce questions that can generate evidence instead of praise.
Education
Lesson activity
GOAL: Help students practise distinguishing evidence from interpretation. CONTEXT: [paste source passage] Students are 14 and have 25 minutes. They know the vocabulary in the lesson glossary. ACTION: Create a short worked example and a paired classification activity. OUTPUT: Teacher instructions, student handout and answer key. CONSTRAINTS: Use only the passage and glossary. Keep reading level accessible. VALIDATION: Quote the passage for every answer-key decision and mark ambiguous items.
Why this works: The output serves both teacher and student, while the source-only constraint makes the activity auditable.
Feedback rubric
INTENT: Give a student actionable feedback on an argument draft without rewriting it for them. CONTEXT: [paste draft and assignment rubric] The student is revising a first draft. INSTRUCTION: Identify one strength and the three highest-impact revisions, each tied to a rubric criterion. CONSTRAINTS: Do not invent citations or supply a replacement essay. Use encouraging, specific language. OUTPUT: Criterion, evidence in draft, revision suggestion and question for the student. VALIDATION: Check each comment against the draft and rubric and flag criteria not evidenced.
Why this works: The rubric and evidence columns keep feedback tied to the student's work and preserve student agency.
Research
Literature extraction
INTENT: Create a traceable extraction table for studies relevant to the stated review question. CONTEXT: [paste papers or abstracts] Review question: [question]. The supplied text is the only source authority. INSTRUCTION: Extract population, intervention, comparison, outcome and limitation for each study. CONSTRAINTS: Do not infer absent methods or results. Quote page or section references when present. OUTPUT: One row per study plus a Missing information column. VALIDATION: Compare every row with the source and list studies where the supplied text is incomplete.
Why this works: The evidence boundary, extraction schema and missing-information rule reduce the temptation to fill gaps.
Research question refinement
INTENT: Turn the project idea into one answerable research question and a list of definitions to resolve. CONTEXT: [paste project notes] Audience: supervisor reviewing feasibility. No data has been collected yet. INSTRUCTION: Identify the proposed phenomenon, population, comparison and outcome, then draft two candidate questions. CONSTRAINTS: Do not claim the question is novel or feasible without evidence. Preserve uncertainty. OUTPUT: Assumptions, candidate questions, what each would measure and feasibility questions. VALIDATION: Mark every claim that requires a source or a decision from the supervisor.
Why this works: The prompt separates a framing exercise from unsupported claims about novelty or feasibility.
Writing
Editorial outline
INTENT: Give an editor a usable outline for an article that explains the decision behind the topic. CONTEXT: [paste source notes] Audience: informed general readers. The article must distinguish sourced facts from interpretation. INSTRUCTION: Propose a thesis, section sequence and evidence needed for each section. CONSTRAINTS: Do not invent sources or settle disputed claims. Keep the outline under 500 words. OUTPUT: Headline options, thesis, numbered outline and open research questions. VALIDATION: Flag each section that lacks supplied evidence.
Why this works: The outline asks for the structure of an article while keeping research gaps visible.
Plain-language edit
INTENT: Help a resident understand what action the policy requires of them. CONTEXT: [paste policy] Audience: residents with no specialist knowledge. Legal review will use the edited draft. INSTRUCTION: Rewrite the policy explanation in plain language without changing obligations. CONSTRAINTS: Preserve dates, exceptions and defined terms. No more than 400 words. Do not add legal advice. OUTPUT: Heading, short explanation, required action and questions the resident may need to ask. VALIDATION: Compare every obligation and date with the source and list any ambiguous term.
Why this works: Audience, source authority and preservation constraints make “plain language” a controlled rewrite rather than a paraphrase.
Analysis
Spreadsheet interpretation
INTENT: Explain the three material changes in this monthly operating report for a finance review. CONTEXT: [paste table] Definitions: revenue excludes tax; variance is actual minus plan. The reader has not seen prior months. INSTRUCTION: Calculate stated variances, identify trends and separate observation from possible explanation. CONSTRAINTS: Do not invent causes. Preserve units and rounding. Show calculations. OUTPUT: Executive summary, variance table, observations and questions for the data owner. VALIDATION: Recalculate each variance against the supplied values and flag missing periods.
Why this works: Definitions in Context and calculation checks prevent familiar business language from hiding a changed metric meaning.
Options analysis
INTENT: Help a project owner choose between the three options using the stated criteria. CONTEXT: [paste options and criteria] The owner values reversibility and delivery time above optional scope. INSTRUCTION: Compare options criterion by criterion and identify the trade-off of the leading option. CONSTRAINTS: Use only the supplied criteria and facts. Do not convert qualitative claims into false precision. OUTPUT: Comparison matrix, leading option, trade-off and two questions before commitment. VALIDATION: Check each comparison cell against the source and mark unknowns.
Why this works: The prompt makes decision priorities explicit without pretending qualitative evidence is more precise than it is.
Productivity
Inbox triage
GOAL: Turn today's inbox into a short list of actions for the owner. CONTEXT: [paste messages] The owner has 45 minutes. Messages containing personal or confidential details must not be reproduced. ACTION: Group messages by action, urgency and waiting-on-person. OUTPUT: A table with message subject, action, due date if stated and suggested reply; omit message bodies. CONSTRAINTS: Do not infer urgency from tone alone. Preserve stated dates. VALIDATION: Check each due date against the source and flag ambiguous ownership.
Why this works: BASIC supplies a time limit, privacy boundary and usable table without turning triage into a new workflow.
Weekly planning
INTENT: Create a realistic weekly plan that protects the two stated priorities. CONTEXT: [paste tasks and calendar constraints] Available focus time is 12 hours. Meetings and fixed deadlines are listed below. INSTRUCTION: Sequence tasks by dependency and deadline and identify what must be deferred. CONSTRAINTS: Do not schedule more than 12 focus hours. Leave 20% unallocated for interruptions. OUTPUT: Day-by-day plan, deferred list and risks. VALIDATION: Check hours, dependencies and deadlines and list assumptions.
Why this works: The plan is constrained by real capacity and includes a deliberate deferral decision instead of fitting every task into an impossible week.
Software Development
Code review
INTENT: Find correctness, security and maintainability risks before this change is merged. CONTEXT: [paste diff and relevant tests] The code handles user-provided filenames. Existing conventions are in the adjacent module. INSTRUCTION: Review the diff, trace error paths and compare behaviour with the tests. CONSTRAINTS: Report only issues supported by the diff or supplied files. Do not rewrite the patch. OUTPUT: Findings ordered by severity with file/line, evidence, impact and suggested test. VALIDATION: Check each finding against the exact diff and distinguish a confirmed issue from a question.
Why this works: The review has a severity-aware output and evidence rule, helping a developer act on findings without accepting speculation.
Test design
INTENT: Add tests that expose the boundary cases in the date parser. CONTEXT: [paste parser, current tests and accepted date formats] The parser must reject ambiguous dates rather than guessing. INSTRUCTION: List partitions and write test cases for valid, invalid and ambiguous inputs. CONSTRAINTS: Use the accepted formats only. Do not change production code or invent a locale rule. OUTPUT: Test table with input, expected result, reason and missing coverage. VALIDATION: Check every expected result against the supplied format rules.
Why this works: The format rules and reject-on-ambiguity constraint turn a broad testing request into inspectable coverage.
Customer Service
Ticket categorisation
INTENT: Route incoming tickets to the correct team without losing evidence of uncertainty. CONTEXT: [paste ticket text and routing rules] Categories and escalation triggers are listed in the rules. INSTRUCTION: Assign one category, identify any escalation trigger and quote the supporting phrase. CONSTRAINTS: Do not infer a trigger absent from the rules. If no category fits, mark Unclear. OUTPUT: Ticket ID, category, evidence, escalation and confidence note. VALIDATION: Compare each assignment with the routing rules and list unclear cases.
Why this works: The routing rules become explicit knowledge and the Unclear outcome prevents forced classifications.
Support macro
INTENT: Draft a reusable reply for customers who cannot complete the documented setup step. CONTEXT: [paste help article and approved policy] Audience: new customers. The agent can link the article but cannot change account settings. INSTRUCTION: Draft a reply that diagnoses the documented step, links the relevant section and asks for one missing detail. CONSTRAINTS: Do not promise a fix or ask for passwords. Under 140 words. OUTPUT: Customer-facing reply and one internal escalation note. VALIDATION: Check links, permissions and promises against the supplied material.
Why this works: The prompt protects account boundaries, gives the customer a next step and separates the reusable response from escalation.
Human Resources
Interview guide
INTENT: Create a structured interview guide that tests the stated competencies fairly. CONTEXT: [paste role description and competency rubric] Interview length: 45 minutes. All candidates receive the same core questions. INSTRUCTION: Write one primary question and one follow-up for each competency. CONSTRAINTS: Do not ask about protected characteristics or infer them from a response. Keep questions job-related. OUTPUT: Question sequence, competency tested, evidence to listen for and permitted follow-up. VALIDATION: Check every question against the rubric and flag any question that is not job-related.
Why this works: The rubric, consistent core questions and explicit boundaries support a reviewable process without pretending a prompt makes hiring objective.
Policy explanation
INTENT: Help employees understand the steps and contact point in the leave policy. CONTEXT: [paste approved policy] Audience: employees; HR will approve the final explanation. INSTRUCTION: Rewrite the procedure in plain language while preserving eligibility and deadlines. CONSTRAINTS: Do not interpret an employee's individual eligibility. Preserve defined terms and escalation contacts. OUTPUT: Short explanation, numbered steps, deadline table and questions for HR. VALIDATION: Compare every deadline and eligibility statement with the policy and list ambiguous wording.
Why this works: The source and approval boundary make the rewrite useful while keeping individual decisions with HR.