Prompts we actually use, with the variables left in.

Here are three samples of my writing, delimited by ---.
Analyse them and produce a voice profile: sentence length, vocabulary level, rhythm, recurring structures, and three habits to avoid.
Then rewrite the target text to match that profile exactly. Do not add new claims.

Samples:
---
{{samples}}
---

Target text:
{{text}}

You are an editor. From the brief below, produce an outline with:
- a working title
- the single question the piece answers
- 4-6 section headings, each with the one claim it makes
- where each supplied example belongs
- one section you recommend cutting, and why

Do not write prose. Brief:
{{brief}}

Write 10 headlines for the article below. Use a different angle for each: contrarian, how-to, number-led, question, outcome, warning, comparison, definition, story, and plain-descriptive.
Label the angle. Max 12 words each. No colons, no "ultimate guide", no exclamation marks.

Article summary: {{summary}}
Audience: {{audience}}

Rewrite the text below for a smart reader outside the field.
Rules: keep every technical fact exact; define a term the first time it appears in six words or fewer; remove filler and hedging; keep paragraphs under four sentences.
Return the rewrite, then a list of terms you defined.

Text:
{{text}}

Write a production system prompt for the capability below, using exactly these sections:
1. Role and scope (including what it is NOT for)
2. Inputs and missing-field handling
3. Rules, numbered, where a higher number wins on conflict
4. Output contract (exact format)
5. Refusal and escalation cases
6. Two examples, one of them an edge case

Capability: {{capability}}
Consumer of the output: {{consumer}}

Audit the prompt below. Report:
- instructions that cannot be objectively checked
- contradictions or unresolved conflicts
- missing output contract details
- missing behaviour for absent or malformed input
- instructions that duplicate each other

Then return a rewritten version that fixes each item, and a changelog of what you changed and why.

Prompt:
{{prompt}}

Design a 30-case evaluation set for the task below.
Cover: 18 typical cases, 8 edge cases, 2 malformed inputs, 2 that must be refused.
For each case give: id, input, expected output or acceptance criteria, and the failure mode it probes.
Return as a markdown table.

Task: {{task}}
Output contract: {{contract}}

Review the diff below against this rubric, in order of severity:
1. Correctness and data loss
2. Security and authorisation
3. Error handling and edge cases
4. Performance at expected scale
5. Readability and naming

For each finding: severity, file and line, why it matters, and the concrete fix.
Say "no findings" for a clean category rather than inventing nits.

Diff:
{{diff}}

Given the symptoms, logs, and relevant code below, list the five most likely root causes.
Rank by probability. For each: the mechanism that would produce these exact symptoms, the cheapest test that confirms or eliminates it, and what the test would show.
Do not propose a fix until a cause is confirmed.

Symptoms: {{symptoms}}
Logs: {{logs}}
Code: {{code}}

Plan a refactor from the current state to the target state below.
Break it into steps that each keep the test suite passing and can ship independently.
For each step: what changes, what stays temporarily duplicated, the risk, and the rollback.
Flag any step that cannot be made backwards compatible.

Current: {{current}}
Target: {{target}}

Read the sources below, each numbered.
Produce: a synthesis of what they agree on, an explicit list of disagreements with the source numbers on each side, and the questions none of them answer.
Cite source numbers inline. Never assert anything that is not in a source.

Sources:
{{sources}}

List the assumptions the argument below depends on, separating stated from unstated.
For each: how load-bearing it is (the argument fails without it, weakens, or is decorative), and how it could be tested with data you could realistically obtain.

Argument:
{{argument}}

Using only the material supplied below, produce a teardown of {{company}}:
positioning in one sentence, target segment, core value claim, pricing model, three visible strengths, three visible gaps, and what their messaging avoids talking about.
Mark anything you are inferring as an inference.

Material:
{{material}}

I am new to {{topic}}. Produce:
- the 6 concepts I must understand first, each in two sentences
- the main schools of thought and what they disagree about
- 5 terms that mean something different here than in everyday use
- the 3 questions a practitioner would ask to test whether I understand it

No preamble.

Turn the notes below into a spec with: problem, who has it and how often, success metric, in scope, explicitly out of scope, user flows as numbered steps, edge cases, and open questions.
Put anything ambiguous under open questions rather than guessing.

Notes:
{{notes}}

Cluster the feedback items below into themes.
For each theme: a name, how many items it covers, two verbatim quotes, the underlying need, and the severity for the user.
List unclusterable items separately rather than forcing them into a theme.

Feedback:
{{feedback}}

The scope below is too large for {{timeframe}}.
Propose three versions: the smallest thing that still tests the core bet, a middle version, and the full scope.
For each: what is included, what is deferred, what you learn, and what risk you accept by cutting.

Scope:
{{scope}}

Write release notes for the commits below, for a non-technical user.
Group as: New, Improved, Fixed. One line each, describing the user-visible change and not the implementation.
Omit internal refactors entirely. No version numbers of dependencies.

Commits:
{{commits}}

Extract data from the text below into exactly this JSON schema:
{{schema}}

Rules: return JSON only, no preamble or code fences. Use null for any field not stated in the text — never infer. If the text contains conflicting values, use the most specific one and add the other to a "conflicts" array.

Text:
{{text}}

Given the schema below, write a single SQL query answering the question.
Before the query, list any assumption you had to make about grain, joins, timezone, or null handling.
After the query, state what the result set means, one row at a time.
Use CTEs over nested subqueries.

Schema:
{{schema}}
Question: {{question}}

A metric moved: {{metric}} changed from {{before}} to {{after}} over {{period}}.
List the possible explanation classes: measurement change, composition or mix shift, seasonality, upstream product change, external event, and genuine behaviour change.
For each, the cut of the data that would confirm or rule it out.
Do not name a single cause until the cuts are checked.

Write a dataset card for the sample and description below: what each column means, units, grain, known nulls and their meaning, collection method, time coverage, three ways it could mislead an analysis, and the questions it cannot answer.
Flag anything you could not determine from the material.

Description: {{description}}
Sample rows: {{sample}}