Business — a decision brief
Review this sales report and tell me what to do next.
INTENT: Choose the one sales action the commercial lead should take this week. CONTEXT: [paste the report] The lead has 20 minutes. The report covers the last quarter and uses closed-won revenue. INSTRUCTION: Extract the strongest trend, compare it with the stated target, and recommend one action. CONSTRAINTS: Do not invent causes. Quote the report for every number. Separate evidence from interpretation. OUTPUT: A five-sentence recommendation followed by an Evidence table with metric, value and source. VALIDATION: Check every number against the report and list any question the report cannot answer.
Why this works better
The Gaiish version adds Intent, Context, Instruction, Constraints, Output and Validation. It turns an open-ended opinion request into a decision brief with an evidence boundary and a checkable shape.
Writing — an audience-aware rewrite
Rewrite this announcement to sound more professional.
INTENT: Help existing customers understand the product change and what they need to do. CONTEXT: [paste announcement] Audience: non-technical customers who already use the product. The change takes effect on 1 October. INSTRUCTION: Rewrite the announcement in plain language and preserve every factual detail. CONSTRAINTS: Calm, direct tone. No jargon, hype or exclamation marks. No more than 180 words. RESULT: Subject line plus email body, with the customer action in a separate final paragraph. VALIDATION: Compare dates, product names and customer actions with the source and list any ambiguous sentence.
Why this works better
The rewrite adds Intent and Audience through Context, then makes tone and length concrete under Constraints. Result and Validation prevent a fluent rewrite from quietly changing a date or omitting the action.
Information technology — incident summary
Summarise this incident for leadership.
INTENT: Give the technology director enough evidence to decide whether the incident requires a customer communication. CONTEXT: [paste incident timeline and logs] The director is not an incident responder. Times are UTC; the service affected is the billing API. INSTRUCTION: Separate confirmed events, likely contributing factors and unresolved questions. CONSTRAINTS: Do not infer root cause from a log absence. Preserve timestamps. Avoid security-sensitive values and secrets. OUTPUT: A 150-word executive summary, then a timeline table and a Risks / Decisions needed section. VALIDATION: Check each event against the timeline, flag missing intervals and mark every inference as inference.
Why this works better
Intent names the leadership decision, Context supplies the reader and source, and Constraints state an important evidence and security boundary. Output and Validation turn a summary into something leadership can review.
Education — a source-based explanation
Explain this chapter to my students.
GOAL: Help students distinguish the chapter's central claim from its supporting examples. 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 better
BASIC adds a Goal, source Context, an Action and an assessable Output. The source-only constraint and validation make it easier for the educator to catch invented context.
Analysis — comparing alternatives
Compare these vendors and recommend one.
INTENT: Select the vendor that best fits a small team needing a reliable support platform this year. CONTEXT: [paste the three proposals] Team size: 6. Current system has no export automation. Decision owner: operations manager. INSTRUCTION: Extract comparable facts, score each proposal against the criteria, and state the trade-off behind the recommendation. CONSTRAINTS: Use only supplied proposal facts. Do not treat marketing adjectives as evidence. Weight reliability and export capability above optional features. OUTPUT: A criteria table, a weighted score with calculation notes, recommendation and two questions for the preferred vendor. VALIDATION: Check each score against the criteria and mark missing prices, terms or capabilities as unknown.
Why this works better
The structured version adds a decision Intent, operating Context, an explicit comparison Instruction, weighting Constraints, a reviewable Output and Validation for missing evidence.
Customer service — an accountable reply
Reply to this angry customer.
INTENT: Resolve the customer's documented issue and make the next step clear without promising an unapproved remedy. CONTEXT: [paste the customer message and case history] The agent may offer a refund only when the policy below allows it. Audience: the customer, who is frustrated. INSTRUCTION: Draft a reply that acknowledges the issue, states what is known, and gives the next action. CONSTRAINTS: Warm but direct. Do not blame the customer or claim an investigation is complete. Do not promise a refund unless the policy supports it. Under 160 words. OUTPUT: Email body with no subject line, followed by an internal note listing any approval needed. VALIDATION: Check every promise against the case history and policy, and flag missing facts before the reply is sent.
Why this works better
The Gaiish version supplies the case Context, the service Intent, a precise Instruction and safety Constraints. The Output separates the customer-facing reply from internal follow-up, while Validation catches unsupported promises.