Convert your prompt

Summarize this report for me, keep it short.

## I — Instructions
You are an executive briefing writer. Your task: summarize the report below for a
decision-maker who has 2 minutes. Rules: no information that is not in the report;
lead with the single most consequential finding.

## S — Source
Use only the report pasted below. Do not assume anything about the company, market,
or time period beyond what the report states.

[PASTE REPORT]

## A — Automation
Work in these steps:
1. List the report's claims and findings.
2. Rank them by consequence to a decision-maker.
3. Draft the summary from the top-ranked items.
Before answering, verify: every sentence in your summary traces to a specific passage
in S; the length limit in V is met. If verification fails, revise once, then report
the failure in N.

## T — Tech stack
Do not use outside knowledge or browsing. Do not fabricate figures the report
does not contain.

## V — Variables
- Length: max 150 words for the summary itself
- Tone: neutral, declarative
- Audience: senior executive, non-specialist
- Fallback: if any constraint cannot be met, say which and why. Ask at most 1
  clarifying question, and only if the task is impossible without it.

## O — Outcome
Structure your entire response in ISATVON format:
- **I** — the task as you understood it (1 sentence)
- **S** — the sources/context you actually used
- **A** — how you verified the result
- **V** — constraints honored; any broken, with reason
- **O** — the deliverable itself: a bold one-line key finding, then one paragraph (max 150 words total)
- **N** — assumptions made, confidence (high/medium/low), anything skipped

## N — Notification
In your N section, always state: every assumption you made, your confidence level and
why, and anything requested that you could not deliver.

Write a marketing email for our new project management app.

## I — Instructions
You are a direct-response copywriter. Your task: write one launch email for our project
management app. Rules: one idea per email; no buzzwords ("revolutionary", "game-changing",
"seamless"); the reader's problem comes before the product.

## S — Source
Product facts (use only these): the app is called [NAME]; it auto-builds project timelines
from a task list; free tier up to 5 users; launches [DATE]. Audience: team leads at
companies of 10–200 people who currently plan in spreadsheets.
Do not assume features, pricing, or integrations beyond the above.

## A — Automation
Work in these steps:
1. State the reader's spreadsheet pain in their words.
2. Present the one feature (auto-timelines) as the resolution.
3. Close with a single CTA to the free tier.
Before answering, verify: every product claim appears in S; the subject line is under
50 characters; there is exactly one CTA. If verification fails, revise once, then report
the failure in N.

## T — Tech stack
Do not browse. Do not invent statistics, testimonials, or customer names.

## V — Variables
- Length: subject ≤ 50 characters; body 120–170 words
- Tone: plain, confident, second person
- Audience: busy team leads, skim readers
- Format: short paragraphs, no bullet lists in the email body
- Fallback: if any constraint cannot be met, say which and why. Ask at most 1
  clarifying question, and only if the task is impossible without it.

## O — Outcome
Structure your entire response in ISATVON format:
- **I** — the task as you understood it (1 sentence)
- **S** — the sources/context you actually used
- **A** — how you verified the result
- **V** — constraints honored; any broken, with reason
- **O** — the deliverable itself: SUBJECT: line, then the email body, then CTA button text
- **N** — assumptions made, confidence (high/medium/low), anything skipped

## N — Notification
In your N section, always state: every assumption you made, your confidence level and
why, and anything requested that you could not deliver.

Can you review this code and tell me if it's good?

## I — Instructions
You are a senior engineer reviewing a pull request. Your task: review the diff below for
defects only. Rules: cite the exact line for every finding; no style or naming comments
unless they cause a bug; severity on every finding.

## S — Source
Use only the diff pasted below and the stated context: [LANGUAGE/FRAMEWORK, e.g. "Python
3.12, FastAPI service handling payments"]. Do not assume tests, callers, or infrastructure
you cannot see — if a defect depends on unseen code, mark it "needs caller check".

[PASTE DIFF]

## A — Automation
Work in these steps:
1. Trace each changed function's inputs to outputs, noting unhandled paths.
2. Check boundaries: null/empty inputs, error handling, concurrency, injection.
3. Rank findings by severity.
Before answering, verify: every finding names a line number that exists in the diff and
describes a concrete failure scenario, not a preference. Drop any finding that fails this.

## T — Tech stack
Do not run code or browse. Reason from the diff alone; say so when the diff is
insufficient to confirm a defect.

## V — Variables
- Severity scale: critical / major / minor
- Max findings: 10, most severe first
- Tone: direct, no praise padding
- Fallback: if the diff is too incomplete to review a section, say which lines and why.
  Ask at most 1 clarifying question.

## O — Outcome
Structure your entire response in ISATVON format:
- **I** — the task as you understood it (1 sentence)
- **S** — the sources/context you actually used
- **A** — how you verified the result
- **V** — constraints honored; any broken, with reason
- **O** — the deliverable itself: a findings list — `severity | file:line | defect | failure scenario` — or "no defects found"
- **N** — assumptions made, confidence (high/medium/low), anything skipped

## N — Notification
In your N section, always state: every assumption you made, your confidence level and
why, and anything requested that you could not deliver.

Tell me about the current state of small modular reactors.

## I — Instructions
You are an energy-sector analyst. Your task: produce a research brief on the current state
of small modular reactors (SMRs). Rules: distinguish operating plants from announced
projects; every figure gets a source; no vendor marketing language.

## S — Source
Ground the brief in verifiable, dated developments. Prioritize regulator announcements
(NRC, IAEA), operator statements, and financial filings over press releases. Do not
assume a project is on schedule without a dated source saying so.

## A — Automation
Work in these steps:
1. Establish what is actually operating today, with dates.
2. List the major projects in licensing or construction, with status and expected dates.
3. Summarize the main obstacles (cost, licensing, supply chain).
Before answering, verify: every project named has a status and a date; no figure lacks a
source; operating vs announced are never mixed in one claim. If verification fails,
revise once, then report the failure in N.

## T — Tech stack
Use web/search grounding if available; cite each source with its date. If browsing is
unavailable, state your knowledge cutoff explicitly in N and mark every claim as
"as of [cutoff]". Never fabricate citations.

## V — Variables
- Length: max 500 words
- Tone: neutral analyst, no advocacy for or against nuclear
- Audience: policy staffer, technically literate but not a nuclear engineer
- Fallback: if any constraint cannot be met, say which and why. Ask at most 1
  clarifying question.

## O — Outcome
Structure your entire response in ISATVON format:
- **I** — the task as you understood it (1 sentence)
- **S** — the sources/context you actually used
- **A** — how you verified the result
- **V** — constraints honored; any broken, with reason
- **O** — the deliverable itself: three headed sections — Operating today / In the pipeline / Obstacles — then a 2-sentence outlook
- **N** — assumptions made, confidence (high/medium/low), anything skipped

## N — Notification
In your N section, always state: every assumption you made, your confidence level and
why, anything requested you could not deliver, and your knowledge cutoff if you could
not browse.

What are the best project management tools right now?

## I — Instructions
You are a software procurement researcher. Your task: compare current project management
tools for a specific buyer (defined in S). Rules: "best" means best fit for that buyer,
not most popular; every price and feature claim needs a cited source.

## S — Source
Buyer profile: a 40-person consultancy, budget ≤ $15/user/month, must have Gantt views
and guest client access. Search scope: vendor pricing pages, credible review sites, and
sources from the last 12 months only. Do not assume pricing from memory — pricing changes;
verify it.

## A — Automation
Work in these steps:
1. Shortlist tools that plausibly meet the buyer's three requirements.
2. Verify each requirement per tool against a current cited source.
3. Eliminate tools failing any requirement; rank the rest by fit.
Before answering, verify: every cell in your comparison has a citation; no source is
older than 12 months; eliminated tools are listed with the failed requirement. If
verification fails, revise once, then report the failure in N.

## T — Tech stack
Use live web search — this task is invalid without it. Cite every source inline with
its date. Never cite a page you did not retrieve.

## V — Variables
- Compare at most 5 finalists
- Tone: neutral, no affiliate-style enthusiasm
- Audience: operations lead making a purchase decision
- Fallback: if a requirement can't be verified for a tool, mark it "unverified" rather
  than guessing. Ask at most 1 clarifying question.

## O — Outcome
Structure your entire response in ISATVON format:
- **I** — the task as you understood it (1 sentence)
- **S** — the sources/context you actually used
- **A** — how you verified the result
- **V** — constraints honored; any broken, with reason
- **O** — the deliverable itself: a comparison table (tool | price | Gantt | guest access | source+date), then a one-paragraph recommendation, then the eliminated list
- **N** — assumptions made, confidence (high/medium/low), anything skipped

## N — Notification
In your N section, always state: every assumption you made, your confidence level and
why, and any requirement you could not verify from current sources.

Refactor this function, it's too long.

## I — Instructions
You are a senior engineer refactoring production code. Your task: split the function
below into smaller functions without changing behavior. Rules: no behavior change, no
new dependencies, no renaming of the public entry point; keep the file's existing style.

## S — Source
The function and its file context are in the editor selection / attached file:
[FILE PATH]. Its callers are in [CALLER FILES, if known — otherwise: "unknown; treat the
signature as frozen"]. Do not assume test coverage exists.

## A — Automation
Work in these steps:
1. Identify the function's distinct responsibilities.
2. Extract each into a private helper with a single purpose.
3. Keep the original function as a thin orchestrator with the same signature.
Before answering, verify: the public signature is byte-identical; every code path in the
original exists in the refactor (including error paths); no helper is called from only
a comment. If the project has tests for this file, state the command to run them.

## T — Tech stack
Language/framework: [e.g. "TypeScript 5, no new npm packages"]. Use workspace context if
available to check callers; do not invent APIs that aren't in the project.

## V — Variables
- Max helpers: 5 — more means the split is wrong, say so instead
- Comments: only where the original had them or a non-obvious constraint needs stating
- Fallback: if behavior-preserving extraction isn't possible for some path (e.g. tangled
  state), leave that path inline and explain in N. Ask at most 1 clarifying question.

## O — Outcome
Structure your entire response in ISATVON format:
- **I** — the task as you understood it (1 sentence)
- **S** — the sources/context you actually used
- **A** — how you verified the result
- **V** — constraints honored; any broken, with reason
- **O** — the deliverable itself: the full refactored code block, then the test command to verify behavior
- **N** — assumptions made, confidence (high/medium/low), anything skipped

## N — Notification
In your N section, always state: every assumption you made (especially about unseen
callers), your confidence level and why, and any path you left unrefactored.

Write a viral post about our AI framework launch.

## I — Instructions
You are a developer-audience social writer. Your task: write one X/Twitter post announcing
the open-source launch of [FRAMEWORK NAME]. Rules: no "🚀 excited to announce"; no
engagement-bait ("RT if..."); lead with what the reader gets, not what we did.

## S — Source
Facts (use only these): [FRAMEWORK NAME] is an open-source framework that [ONE-LINE VALUE,
e.g. "turns any prompt into a structured, auditable contract"]; Apache-2.0; repo at
[URL]; works with any AI platform. Do not invent stars, users, benchmarks, or endorsements.

## A — Automation
Work in these steps:
1. State the pain the target developer has today, in one line.
2. Present the framework as the fix, in one line.
3. Close with the repo link.
Before answering, verify: the post is within the length limit in V; every claim appears
in S; the banned phrases in I are absent. If verification fails, revise once, then
report the failure in N.

## T — Tech stack
Do not browse or pull real-time trends. Do not fabricate metrics or quote real people.

## V — Variables
- Length: ≤ 280 characters for the post itself
- Tone: dry, confident, developer-to-developer; at most 1 emoji
- Audience: developers who are tired of prompt roulette
- Deliver 3 variants
- Fallback: if any constraint cannot be met, say which and why.

## O — Outcome
Structure your entire response in ISATVON format:
- **I** — the task as you understood it (1 sentence)
- **S** — the sources/context you actually used
- **A** — how you verified the result
- **V** — constraints honored; any broken, with reason
- **O** — the deliverable itself: 3 numbered post variants, each with its character count
- **N** — assumptions made, confidence (high/medium/low), anything skipped

## N — Notification
In your N section, always state: every assumption you made, your confidence level and
why, and anything requested that you could not deliver.