AI Prompt and Skill Library

Keep the meaning and the information density; fix the language only

You are a native-speaker editor. Make the passage below read smoothly. Requirements: 1) preserve the original meaning and information density; 2) cut boilerplate, repetition, and adjectives that do no work; 3) do not add anything I did not write; 4) after the rewrite, say in one sentence what you mainly changed.

[paste your draft]

Delete template phrasing like the 'not X but Y' antithesis and 'first, second, finally'

The passage below reads like it was written by an AI. Rewrite it: 1) remove antithesis constructions such as 'it is not X but Y' and 'not only X but also Y'; 2) remove 'first / second / finally', 'in summary', and 'it is worth noting'; 3) replace abstract nouns with concrete actions; 4) vary sentence length, and allow incomplete sentences. Output only the rewritten body text.

[paste your text]

Cut it in half without losing information — the work is picking out what actually matters

Compress the passage below to [target word count] words or fewer. Rules: 1) keep every fact, number, and conclusion; 2) cut the wind-up, the repeated explanations, and the ornament; 3) merge sentences if you need to, but do not change cause and effect.

[paste your text]

Feed in a pile of fragments, get back an outline you can use as is

Below are my scattered notes. Turn them into an outline: 1) start with a one-sentence thesis; 2) split it into 3–5 parts at a logical level, with one sentence each on the question that part answers; 3) file every fragment under the part it belongs to; 4) name the two ideas that actually repeat each other, or contradict each other.

[paste your notes]

Refuse, chase, correct a mistake — without groveling and without bristling

Write an email for me. Context: [context]. Recipient: [relationship and role]. What I need to achieve: [goal]. My bottom line: [what I cannot concede]. Requirements: keep it short; give the conclusion before the reasoning; apologize at most once; close with a clear next step and a date.

What your boss reads and what an engineer reads have to be two different documents

Rewrite the passage below into two versions: 1) for [managers] — under 150 words, covering only impact, risk, and the decision you need; 2) for [the people doing the work] — keep every technical detail and every step. Neither version may drop a load-bearing fact.

[paste the original]

Write titles for the same article from restrained to overblown, and mark the one that crosses the line

You are a veteran editor on a content distribution desk. Read the article below and give 5 titles, rising in intensity from restrained to overblown. After each title, note: 1) what it promises; 2) whether the body actually delivers it; 3) the most likely reaction of a reader who clicks (disappointment / feeling patronized / feeling it was worth it). Then, separately, name the one title that already counts as clickbait, and why. Do not trade accuracy for click-through.

[paste the article]

Firm, conciliatory, self-deprecating: three ways to say it, and what each one costs

Rewrite the passage below into three versions — same content, only the tone changes: 1) firm — no room left to negotiate, but give the reason; 2) conciliatory — keep the position, reduce the confrontation to a minimum; 3) self-deprecating — lower the other side's guard by admitting your own awkward position. After each version, add one sentence on what it costs you (how it may be read, what it gives up). Do not add facts that are not in the original.

[paste the paragraph]

Flag only what can be verified; do not rewrite the article

You are a fact-checking editor. Read the article below paragraph by paragraph and check only — do not rewrite. Output three sections: 1) every number, date, name, and quotation, listed one by one and marked 'needs verification' or 'contradicts the surrounding text'; 2) places where the article says two different things, quoting both sentences; 3) strong claims with no source ('all', 'never', 'inevitably'). For each item, give the cheapest way to verify it. Say nothing about the paragraphs that are fine.

[paste the article]

Keep the speaker's voice; cut the verbal repetition and the digressions

Below is a transcript of an interview. Turn it into an article of about 1500 words: 1) reorganize by theme, not chronologically; 2) keep 5–8 of the most informative sentences as direct quotes, word for word; 3) cut filler words, repetition, and digressions, but do not change the speaker's voice or position; 4) list 3 questions I stopped short of asking but should have.

[paste the transcript]

Users can follow it, and know what this release means for them

Write a changelog from the change list below. The readers are ordinary users who already use the product. Structure: 1) one sentence on the most notable change in this release; 2) grouped as 'New / Improved / Fixed', each entry saying 'what changed plus what it means for you', with no internal jargon; 3) a separate list of things users have to do themselves (sign in again, change a setting); 4) known issues. Do not write empty phrases like 'we improved the user experience'.

[paste the change list]

Find the sentence where the piece gets abandoned, not praise how clear it is

Play an impatient target reader: [reader profile], who only meant to skim. Read the draft below in order, then answer: 1) which paragraph you would close the tab at, and which sentence specifically lost your patience; 2) three places where the writer is talking to themselves and not answering the question in the reader's head; 3) the argument you suspect the author has not thought through either; 4) if you had to keep only half, which paragraphs you would cut. Do not comment on prose style, and do not offer encouragement.

[paste the draft]

Compress a long piece into three cards that each stand alone, not one shorter summary

You are an editor who builds knowledge products. Turn the long article below into three summary cards, each answering one standalone question: 1) Card one: the single most important conclusion, in one sentence; 2) Card two: the key evidence or mechanism behind it, keeping only the details needed to believe it; 3) Card three: what a reader can do with it, or when it does not apply. Keep each card under 80 words with a heading of no more than six words; add nothing that is not in the source. Finish by naming which card is most likely to be shared on its own, and why.

[paste the article]

Find where the subject actually changes, then make that structure visible in the headings

You are a nonfiction editor. Add subheadings to the article below: 1) read it first and mark where the subject actually changes, rather than cutting at even intervals; 2) keep each heading to 4–8 words and make it tell a skimming reader what question that section answers; 3) write headings as statements, not 'On...' or 'Thoughts about...'; 4) if a passage has no nameable subject, say it should be merged or cut. Finish by listing the headings you added or changed.

[paste the article]

State the strongest counterarguments properly before answering them, instead of knocking down straw men

You are an argument coach hired to find the weak points. Take the claim below through four steps: 1) restate it in one sentence and name the implicit premise it depends on; 2) give three counterarguments, each the version a smart person in the field would actually make, with no straw men; 3) answer each one: which part holds, which does not, and what evidence would settle it; 4) say how the original claim should be revised if any one of the three turns out to be right. Do not defend the claim at all costs.

[paste the claim]

Strip the repetition and jumps from spoken remarks and leave written decisions people can act on

You are a meeting-notes editor. Turn the spoken remarks below into a written document: 1) open with three lines stating what was decided, who owns it, and by when; 2) organize the body as context, discussion, decision, and action items, not in speaking order; 3) remove filler, repetition, and unfinished sentences without changing the speaker's position; 4) flag vague phrasing such as 'roughly' or 'we'll revisit' and convert it into a question that needs an answer. Do not invent anything that was not said.

[paste the transcript or your notes]

Compare the strength of each claim with the strength of its evidence; flag, do not rewrite

You are a manuscript editor checking one thing only: whether each claim is matched by evidence of the same strength. Do not rewrite the piece. Go paragraph by paragraph and find every sentence that asserts something: 1) grade the claim as fact, trend, causation, or prediction; 2) label the evidence behind it as data, case, quotation, common knowledge, or none; 3) flag mismatches, such as one case used to support 'all', or correlation presented as causation; 4) give each mismatch the smallest possible fix, either weaker wording or the evidence it needs. Do not comment on style.

[paste the article]

Keep the limits and failure modes; translate implementation detail into consequences the reader can place

You are a technical communication editor. Rewrite the technical document below for a non-technical reader: [role, e.g. product manager, customer, or executive]. Requirements: 1) open with one sentence on what this means for that reader; 2) the first time a technical concept appears, explain it with an everyday comparison and do not introduce another term; 3) keep the limits, failure modes, and numbers, and do not delete risk to make it easier; 4) list anything ambiguous or missing in the source separately and mark it 'needs confirmation'. Do not replace a mechanism with a metaphor.

[paste the technical document]

Ban the adjectives and write only verifiable details and situations of use

You are a product copy editor. Write a 120-word introduction to [product] for [target user]. Hard constraints: 1) no 'powerful', 'efficient', 'seamless', 'smart', 'all-in-one', or any synonym swap; 2) every selling point must land on a concrete action or situation: who does what, under what conditions; 3) include at least one verifiable detail, such as a number, a limit, or a condition of use; 4) produce three versions: by capability, by situation, and by comparison. Plain is better than unverifiable praise.

[paste the product details]

Turn fragments from comments, tickets, and interviews into a few themes you can act on

You are a user research analyst. Cluster the scattered feedback below into themes: 1) read it all first and cluster by what the user was trying to accomplish, not by keyword or sentiment; 2) for each theme give one summary sentence, the number of supporting items, two representative quotes verbatim, and one counterexample; 3) rank by reach times severity and state the basis for the ranking; 4) list the items that fit nowhere and any likely misreadings. Do not soften the wording or complete the users' logic for them.

[paste the comments, tickets, or interview notes]

Only the places that will cause a bug, a security problem, or a performance problem

You are a senior engineer. Review the code below and point out only what will cause a bug, a security problem, or a performance problem, ordered by severity. For each: 1) what the problem is; 2) the conditions that trigger it; 3) the concrete fix. Do not comment on code style, and do not offer things like 'consider adding comments'.

```
[paste your code]
```

Causes ranked by likelihood, plus how to verify each one

I hit this error on [stack and version]. [What I have already tried]. Please: 1) list the causes from most to least likely; 2) for each, give a way to verify it (one command, or a minimal reproduction); 3) do not repeat anything I have already tried; 4) if there is not enough information to decide, tell me exactly what to add.

```
[paste the error and stack trace]
```

Advice for this query, not generic best practice

You are a database expert. This SQL takes [elapsed time] on [table name, roughly X rows]. Please: 1) name the most likely bottleneck (read the execution plan); 2) give the optimized SQL; 3) say which indexes are needed and what they cost once added (slower writes, disk space). Do not give me generic advice like 'avoid SELECT *'.

```sql
[paste your SQL]
```

Explain it by data flow, not line by line

Explain the code below. Requirements: 1) start with one sentence on what it does overall; 2) then follow the data: where the input comes from, what transforms it, where the output goes; 3) flag 2–3 spots that are easiest to misread; 4) point out anything that looks redundant or suspicious. Do not translate the syntax line by line.

```
[paste your code]
```

Find the holes in the design before anyone writes the code

This is my API design: [paste the design]. Act as a reviewer and attack it: 1) list the 5 points most likely to break during implementation; 2) say which fields are redundant, and which are missing in a way that forces the client into a second request; 3) suggest changes that stay backward compatible; 4) if there is an obviously simpler alternative, say so outright.

Edge cases and counter-examples served with it

Write me a regex that matches [describe the requirement]. Requirements: 1) give the expression; 2) explain each piece; 3) give 3 examples that should match and 3 that should not; 4) say which extreme input would make this expression backtrack catastrophically, and how to avoid it.

Assume it has to be rejected first, then decide whether it is worth doing

You are the senior engineer brought in to review this migration, and your job is to find grounds strong enough to veto it. Please: 1) list the specific conditions under which this migration fails (data volume, downtime window, rollback, other teams' cooperation); 2) name the problems the plan waves off as 'we will deal with that then'; 3) propose a smaller alternative path (migrate a subset first, dual-write first, migrate reads only); 4) only at the end: if you cannot veto it, which two things must be added.

[paste the migration plan]

Dig the breaking changes you will actually hit out of the changelog

I want to move [dependency] from [current version] to [target version]; the project calls it in roughly [N] places. Please: 1) list every breaking change between the two versions that could affect me, keeping only the ones my calls actually reach; 2) sort them into 'must change / should change / can leave', with the edit for each; 3) give the upgrade order (which one goes first, whether to split it into two steps); 4) name the problems most likely to surface only at runtime, and how to catch them locally first.

[paste the changelog and dependency config]

Uncovered branches, ranked by how likely they are to cause a production incident

Below are my implementation and my existing tests. Find what the tests do not cover: 1) list all branches and boundaries, marking the ones with no case; 2) rank them by 'worst impact if it goes wrong in production' and give the top 5 cases to add (input, expected result, why it is easy to miss); 3) point out which existing cases are duplicates that could be deleted without losing confidence; 4) flag any test that asserts implementation details rather than behavior.

```
[paste the code and tests]
```

Entities, relations, a state machine — and the fields that are certain to change

Turn this requirement into a data model; no code yet. Output: 1) the entity list, one sentence each on what it represents in the real world; 2) the relations between entities and their cardinality, flagging the many-to-many ones that need a join table; 3) the state machine of the core object (states, triggers, irreversible transitions); 4) the fields that look sufficient now but will probably change within six months (price, permissions, localization, soft delete); 5) three places where the requirement is unclear and product has to be asked first.

[paste the requirement]

Find the swallowed exceptions and the errors that cannot be diagnosed

Review the error handling in the code below. Focus only on the failure paths: 1) which exceptions are swallowed or downgraded to a default value — will a failure pass silently? 2) is the error message enough to locate the cause (does it carry the key id, the inputs, the upstream state)? 3) which retries are unsafe (non-idempotent, double-charging or double-writing)? 4) where should it fail but keeps running, and where should it keep going but aborts entirely? 5) give the corrected key snippets.

```
[paste your code]
```

Assume two requests land at the same moment, then walk the shared state item by item

Review the code below for concurrency safety. Method: assume two requests arrive in the same millisecond and walk every piece of shared state. Please: 1) list all shared mutable state (in-memory variables, caches, database rows, files); 2) point out where there is a gap between checking and using (read-then-write); 3) say at what concurrency it surfaces, and what it looks like when it does; 4) give the minimal fix (lock, unique constraint, atomic operation, make it idempotent) and the cost of each.

```
[paste your code]
```

Deliver the migration, the rollback, and the checks together — validated on a small sample first

You are a backend engineer responsible for a production data migration. Given the schema and the intended change below, produce three things: 1) the migration script — batched, re-runnable, with a hard batch limit so no long transaction locks the table; 2) the rollback script — state which steps are irreversible and how to verify the data after rolling back; 3) verification SQL — run at each checkpoint (after backfill, before cutover, before rollback), with expected results and a pass threshold. Name the step most likely to lose data before you show any script. Do not assume a maintenance window.

[schema / intended change / data volume]

Turn scattered log lines into one timeline, with evidence separated from guesses

You are an engineer debugging a production incident. Below is a slice of logs, possibly from several services. Do four things: 1) build a timeline of events and mark the first anomaly; 2) split what the logs prove from what you are inferring into two columns; 3) name the log line still missing that would settle the cause; 4) give the smallest next verification step. Do not start from the first ERROR line — find what happened before it.

[log excerpt / time range / affected services]

Reproduce it with the least input, not with a whole test suite

You are an engineer who is good at isolating edge cases. Write one minimal test for the bug below: 1) keep only the input and state required to trigger it, and delete everything else; 2) assert the exact expected versus actual value, not just 'should not throw'; 3) state that it must fail before the fix and pass after; 4) if it cannot be reproduced reliably, list the missing environmental conditions instead of inventing them. Put it in a single file using the existing test framework.

[bug report / relevant code / runtime]

Assume the config will fail, then hunt for default values, secrets, and environment gaps

You are the SRE signing off the release, and your job is to find problems, not confirm that everything looks fine. Audit the config and environment variables below: 1) list every setting that only works because of a default, and write that default out; 2) flag anything where a mismatch across environments in secrets, connection strings, timeouts, retries, or concurrency limits would cause an incident; 3) trace the specific paths that work locally and fail in production; 4) give a pre-launch checklist sorted by risk, with a box for each item. Do not comment on formatting, and do not assume the platform catches it.

[config files / env var list / deployment environment]

Replace 'we will monitor more' with a timeline, a mechanism-level cause, and testable fixes

You are facilitating an incident postmortem. Using the timeline and response notes below, write the review: 1) keep only the moments that changed system state or a decision, with one timezone stated; 2) take the root cause down to the missing mechanism or the assumption that turned out false — 'human error' is where the analysis starts, not where it ends; 3) split actions into done and outstanding, each with an owning role, a due date, and a way to verify it; 4) add a separate section on what went right by luck. Do not include 'improve monitoring' or 'raise awareness' — anything that cannot be verified.

[incident timeline / impact / response notes]

Check every index against a real query, and call out redundancy, dead weight, and write cost

You are reviewing database performance. Given the schema, data volume, and slow queries below, evaluate the indexes one by one: 1) name the query each index serves and quote the WHERE / ORDER BY fragment it covers; 2) flag redundant indexes whose leftmost prefix is already covered, indexes nothing can use, and predicates that defeat them (functions, implicit casts, leading wildcards); 3) estimate the write and storage cost of each addition; 4) end with three columns — keep, drop, add. Do not infer queries from column names.

[schema / indexes / slow queries / row counts]

Cut along interface contracts so people can start without waiting on each other

You are the tech lead. Break the requirement below into tasks that can run in parallel: 1) first identify the ordering constraints that cannot be parallelized — data model, interface contract, migration; 2) cut everything else into units one person can deliver independently in a week, each with inputs, outputs, and acceptance checks; 3) mark dependency direction and the earliest start date; 4) name the shared files or modules most likely to conflict and how to avoid it. Do not split by frontend/backend — split by independently verifiable deliverable.

[requirement / current system / team size]

Name who gets hurt, which path is most fragile, and how you get out

You are arguing against this change, and your job is to find who it can hurt. Given the change description and system dependencies below, produce: 1) every affected caller, dataset, scheduled job, and downstream consumer, with how each one breaks; 2) the top three risks ranked by people affected × recovery difficulty; 3) the assumptions this change relies on that nobody has verified; 4) a rollout order and rollback plan, including the metric threshold that triggers a rollback. Do not close with 'the impact is contained' — give evidence.

[change diff / dependencies / traffic volume]

Keep only decisions, owners, and deadlines

Turn the meeting notes below into minutes. Format: 1) one sentence on what this meeting needed to settle; 2) decided items (each written as: decision + owner + deadline); 3) open items with disagreement (state both sides' reasoning); 4) what has to be done before the next meeting. Cut all small talk and repetition.

[Paste notes]

Written for your manager — results and risks first

Write a weekly report from the scattered notes below. Structure: 1) results produced this week (verifiable facts, not words like 'made progress'); 2) problems hit and how I handled them; 3) next week's plan (3 items max, with priorities); 4) what I need you to decide or coordinate. Keep the whole thing under 300 words.

[Paste notes]

Conclusion first, then the evidence and the risk

I need to report [topic] to [audience]. Write it in pyramid structure: 1) first sentence gives the conclusion; 2) three points that support it (one sentence plus one data point or fact each); 3) risks and how I'll handle them; 4) the decision I need from them. No background preamble unless I explicitly ask for it.

[Background material]

Rehearse their likely reactions before you walk in

I need to talk to [person] about [issue]. My goal is [goal], and what I'm most afraid of is [worry]. Please: 1) list the three most likely reactions they'll have, and the real concern behind each; 2) give me one opening line for each; 3) point out which phrase of mine is most likely to escalate things; 4) give me a fallback for 'if this falls apart'.

Turn a long document into steps you can tick off

Read the document below and produce an execution checklist. Requirements: 1) every step must be directly executable and start with a verb; 2) mark dependencies (which step must come after which); 3) flag the three steps most likely to be missed; 4) list any branch that needs a human decision separately.

[Paste document]

Ask back first, restate second — before you build the wrong thing

You're an experienced project lead, and right now you're my requirements-clarification partner. I received a vague task: "[boss's or client's exact words]". Don't propose a solution yet. Please: 1) list what I must know in order to start but that this sentence doesn't say — 6 items max, ordered by importance; 2) for each, give the default answer you'd guess and what goes wrong if that guess is wrong; 3) restate the task as you understand it in 100 words, marking which parts are my exact words and which you added.

Get them to cooperate instead of bouncing the ball back

You're a project lead who's good at moving things across departments. Write an email asking [team] to finish [specific task] by [time]. Background: [why it's needed, who I've already talked to]. Requirements: 1) open with one sentence stating what they need to do and by when; 2) explain the impact on them, not just on my schedule; 3) list the prep work I've already finished, to lower their perceived cost; 4) give a follow-up that names a specific date; 5) under 200 words, and don't open with 'sorry to bother you'.

Turn 'a bit of everything' into criteria that actually filter

You're the hiring lead. Write the JD for [role title]. Inputs: team situation [one sentence], what this person must solve [1–2 things], budget [range]. Requirements: 1) the first paragraph explains why this role exists — no company boilerplate; 2) write 4–6 responsibilities as the concrete actions they'll actually take; 3) no more than 5 must-haves, each verifiable in an interview, with nice-to-haves listed separately; 4) explicitly state the profiles you won't accept; 5) no unverifiable phrases like 'works well under pressure' or 'takes ownership'.

Argue from evidence, not from 'they felt fine'

Write candidate feedback from my interview notes. Key requirements for the role: [paste JD requirements]. Interview notes: [paste Q&A]. Requirements: 1) rate each requirement as exceeds / meets / below, and every rating must quote the candidate's exact words or a specific behavior as evidence; 2) add a separate paragraph on what I'm unsure about and what needs to be tested further; 3) give a clear call: advance, another round, or reject; 4) no unevidenced adjectives like 'strong communicator' or 'high potential'.

Ask it all at once, so three rounds in you still know what the price covers

You're the procurement lead. Write an RFQ email to [type of supplier]. We're buying [goods/service], quantity [qty], delivery needed by [date]. Requirements: 1) state the requirement as a list: specs, quantity, delivery location, acceptance criteria; 2) ask them to quote in one fixed format: unit price, tax, freight, payment terms, quote validity, MOQ; 3) pin down the three things that turn into price increases later: change-order fees, late-delivery penalties, warranty scope; 4) close by saying we're comparing several suppliers and the date we need their reply.

Play the opponent first, then turn the risks into a trackable table

You're a project auditor brought in to poke holes, and you assume this project will slip. Project info: [goal, deadline, staffing, dependencies]. Output a risk table with these columns: risk / trigger signal / impact (time, cost, quality) / likelihood / mitigation we can take / owner. Requirements: 1) at least 8 rows, covering staffing, external dependencies, scope change, technical uncertainty; 2) sort by likelihood × impact; 3) include only what we can still influence — list what already happened separately; 4) mitigations must be executable; no 'improve communication'.

Pull who does what by when out of hundreds of messages

Turn the group chat log below into action items. Requirements: 1) keep only messages with a clear action or conclusion — drop chatter, emoji, and repeated confirmations; 2) output a table: item / owner / due / current status / quoted summary; 3) list unclaimed items in their own section marked 'unassigned'; 4) put contradictory statements in their own section, saying who said what; 5) finish with the three questions that must be answered today.

[Paste chat log]

Name the cost, offer options, don't just push back

Rewrite the urgent request below as a reply. First confirm the outcome the requester actually needs and their real deadline, then state which committed deliverable would slip if you insert this work (name the project and date). Offer two options, A and B, each with its cost spelled out — which commitment slips, how much scope is cut, whether anyone is added — and ask them to choose one by end of day; if they do not reply, option B applies. Drop words like “try” and “if I get a chance”, and apologize at most once.

[Request]
[Current schedule]

Use evidence and an alternative, without a fight

Turn the situation below into a respectful disagreement with your manager. Structure: 1) restate the goal as you understand it, so you both know you are arguing about the same thing; 2) give one verifiable fact or data point behind your concern; 3) acknowledge the conditions under which their plan works; 4) offer your alternative and its cost; 5) ask for a decision by a specific time. Keep it about the plan, not the person, stay under 300 words, and do not open with “I feel” or “this might be a problem”.

[Context]
[Manager's plan]
[My evidence]

One verifiable question per competency

Using the JD and level below, design a 45-minute interview. Start with four or five competencies this role actually needs, eight words or fewer each; give each one a main question plus two follow-ups, and make the main question ask what the candidate has actually done in the past. For every question, write what a passing and a failing answer sounds like. Leave five minutes for their questions. Do not ask brainteasers, horoscopes, or marital status.

[Paste JD]
[Level]

Impact and recovery first, cause second

Write a customer notice from the incident details below. Structure: 1) when it happened, which functions were affected, and who was hit; 2) whether service is restored and what you did; 3) confirmed causes only — mark anything still under investigation as such; 4) the fixes you will ship in the next 72 hours and who owns each; 5) compensation and the next update time. No blame-shifting and no vague phrases like “a small number of users” or “system fluctuation”. Keep it under 400 words.

[Timeline]
[Impact]
[Confirmed cause]

Why now, what ships, and how success is measured

Turn the background below into a one-page project brief. Order: 1) the problem — who, in what situation, and the cost in numbers; 2) what happens if you do nothing; 3) goals and non-goals, three or fewer each; 4) approach in five steps or fewer, plus the biggest risk; 5) success metrics as baseline to target with a measurement window; 6) resources needed and decision points. One page, no vision statements or adjectives, and no unverifiable goal like “improve the experience”.

[Background]
[Resource constraints]

Turn recurring unowned items into assignments

Read the meeting notes below and find the items that come up repeatedly but never get a clear owner. Output a table: 1) the item, in one sentence describing what must be delivered; 2) how many times it was raised, with the actual quotes; 3) why nobody picked it up — no authority, no capacity, unclear ownership, or general worry; 4) the specific role it should go to, not “the relevant colleagues”; 5) the latest date it starts causing damage if still unowned. At the end, name the one item that needs a decision in the room.

[Paste notes]

List what someone else can actually take over

Build an offboarding handover checklist from my role and current work. Four sections: 1) live work — status, next step, deadline, and counterpart; 2) things only I know — accounts, metric definitions, past decisions, external contacts; 3) documents and access — Notion pages, where they live, how they transfer, who approves; 4) support boundary after handover — last working day and how long I will answer questions. For every item, name the receiver and how they will prove they can take it over. Do not write “handed over”, which cannot be verified.

[Role]
[Current work]
[Last working day]

Make “make it better” testable

Translate the vague feedback below into executable work. First list three specific problems it could mean, each with an observable signal. Then ask me the three questions I have to answer — goal, current state, and acceptance criteria. Then propose a default plan: what changes, what does not, how you will verify it, and the level of effort. Do not start rewriting, and do not treat “optimize” as “redo”.

[Vague feedback]
[Current version/data]

Analogy → definition → common misconception → self-test

Explain [concept] to me the Feynman way. Order: 1) give an analogy a 10-year-old would get; 2) give the precise definition and point out where the analogy breaks down; 3) name the most common misconception and why it's wrong; 4) give two self-test questions (one basic, one that's easy to get wrong).

One question at a time, until you run out of answers

You're a Socratic tutor. On [topic], ask me one question at a time and wait for my answer before going one layer deeper. Rules: 1) don't give answers; 2) when my answer is vague, make me give a concrete example; 3) when I'm wrong, use a counterexample so I find the contradiction myself; 4) 8 rounds max, then summarize where I got stuck.

Show where the boundary is, instead of listing definitions

Compare [concept A] and [concept B]. Requirements: 1) one sentence each on what it is; 2) three key differences (choose the dimensions yourself and say why they matter); 3) one example of something that looks like A but is actually B; 4) when does this distinction not matter at all?

Ask what it actually proved first, then look at the details

Help me read the paper excerpt below. Output: 1) what problem it addresses; 2) the core idea of the method, in plain language; 3) what the experiments proved and what they didn't; 4) limitations the authors admit; 5) if I had to reproduce it, the hardest step. Don't restate the abstract.

[Paste paper excerpt]

Test exactly the places most likely to be confused

Write 8 questions from the material below: 4 single-choice, 2 multiple-choice, 2 short-answer. Requirements: 1) only test details that are easy to confuse or easy to miss — no rote numbers; 2) give the answer and a one-sentence explanation for each; 3) mark what each question tests (recall / understanding / application).

[Paste material]

Get the skeleton first, then decide which chapters deserve a close read

I'm going to read [book title], in order to [what I want to solve]. Please: 1) explain the book's main thesis in 5 sentences, including how the claims depend on each other; 2) give a chapter map, one sentence each on what that chapter contributes to the chain; 3) mark the 2–3 core chapters and the parts that can be skipped, with reasons; 4) point out where the author merely asserts without proving; 5) give me 3 questions I should be able to answer when I'm done.

See how many blocks there are and which depends on which, then decide what to learn

I want to learn [field/skill], with the goal of [specific use]. Give me a knowledge map first, without explaining anything yet: 1) break it into 4–7 modules, one sentence each on the problem it solves; 2) use a table to show dependencies between modules (you need A before B); 3) mark which 20% drives 80% of the result, and what can be added later; 4) give the shortest path for my goal, and say what that path gives up.

Put it on the opposing side: only find errors, don't compliment

Here's my understanding of [concept]: [my explanation]. Take the opposing side and do one thing only: find what I got wrong. Requirements: 1) judge each sentence as accurate / inaccurate / vague, and for the inaccurate ones say what's wrong; 2) name the two concepts I'm conflating and distinguish them in one sentence; 3) give a concrete example where my understanding leads to a wrong conclusion; 4) don't add knowledge I didn't ask for, and don't affirm me first.

Explain it backwards to find out where the real holes are

I'm going to explain [concept] to you, and you're a strict listener. Rules: 1) after I finish, point out only three things: where I said something wrong, where I skipped a key step, and where I just recited a definition without explaining it; 2) for each, ask me one 'why' — if I can't answer, write it down; 3) don't fill in answers for me; wait until I ask; 4) end by listing the two vaguest parts as my review priorities next time.

I'll start: [my explanation]

Terms, acronyms, and insider language — cleared in one pass

The [field] material below is full of jargon. Make a comparison table: term / literal meaning / what it actually means in this context / what you'd miss without knowing it. Requirements: 1) only include terms I probably don't know — skip common words; 2) add a separate row for each confusing near-synonym pair, distinguishing them; 3) when a term has several industry usages, say which one this is; 4) finish with a 100-word rewrite of the whole passage that reads without any background knowledge.

[Paste material]

Start from boundaries and inputs/outputs, not from the details

Help me break down [system name], for example [specific example]. Go in order: 1) draw the boundary first — what's inside, what's outside; 2) list the inputs, the outputs, and the goal it maintains; 3) break it into 3–6 subsystems, stating each one's responsibility and how they interface; 4) point out where the bottleneck or single point of failure is; 5) walk one concrete scenario through the flow and mark the steps I'd tend to overlook. Where information is missing, say it's uncertain — don't make it up.

Weekly goals, each with something you can check at the end

I want to learn [skill] in 30 days, I can put in [X] hours a day, and my current level is [level]. Give me a plan: 1) split it into 4 weeks, one clear capability goal per week; 2) for each week, list practice tasks and one checkable deliverable (something you can show someone); 3) mark which day I'm most likely to quit, and what to do at that point; 4) leave 20% slack; 5) give a criterion for 'actually learned it' — no phrases like 'proficient'.

Get from the symptom to the mechanism instead of stopping at 'careless'

Trace this problem with five whys: [describe the symptom]. Rules: 1) one most likely cause per level, written as a single 'because X, therefore Y' sentence; 2) after each level, label the evidence strength (data / inference only); 3) when evidence is missing, don't push the chain further — give me a check I can run within a week; 4) stop at level five, output the full causal chain, and mark which level is actually actionable.

Premise, inference, conclusion — plus the step the author left out

Read the passage below and map its argument: [paste article or section]. Output: 1) the central conclusion in one sentence; 2) the premises, numbered, each labeled as a fact or a value judgment; 3) how the premises lead to the conclusion, including the unstated premise the author skipped; 4) the step where the argument jumps — where the conclusion claims more than the premises support; 5) if I wanted to push back, which single premise is cheapest to attack.

Definitions are easy; boundaries only show up in counterexamples

I'm learning [concept] and I already know the definition plus two typical examples. Give me three counterexamples, one per case: 1) looks like it fits the definition but doesn't; 2) counts only while a certain condition holds, and stops counting when it doesn't; 3) often used as a textbook example but is really a boundary case. For each, say which element of the definition it violates and what goes wrong if I misclassify it.

When I get it wrong, say which step I got wrong

Build a diagnostic quiz from the material below: [paste material]. Requirements: 1) first list the 4–6 steps involved in understanding this topic, e.g. identify the variables, pick the right formula, handle units, interpret the result; 2) one or two questions per step — few, but aimed at that step; 3) after I answer, diagnose which step I failed before explaining why that step is easy to get wrong; 4) if I miss the same step twice in a row, stop and re-teach that step before moving on.

Each turning point solved the bottleneck of the stage before it

Lay out the development of [field] as a timeline. Requirements: 1) 4–6 stages, each with an approximate era and a one-line theme; 2) for every turning point, what the previous stage was stuck on, what solved it, and what the new cost was; 3) which early approaches are still in use today and why they survived; 4) the assumption in the current stage most likely to be overturned next.

One good analogy, then take it apart yourself

Explain [concept] with an analogy, and state where the analogy breaks. Requirements: 1) one main analogy, mapping which elements of the concept it covers; 2) at least two places where it fails, and the wrong inference each failure produces; 3) one backup analogy that is more accurate from a different angle; 4) a short walkthrough showing where following the main analogy leads you astray.

Work backwards from what you can use next week and cut the rest

I need to use [skill or tool] to finish [specific task] within [timeframe]. Give me a minimum viable learning path: 1) define the lowest acceptable standard for finishing that task; 2) keep only the knowledge required to hit that standard, ordered by dependency; 3) one exercise of 15 minutes or less per item; 4) an explicit not-now list with reasons; 5) a test for when I can stop learning and start doing.

Turn 'studies show' into things you can actually check

Check this claim: [paste claim]. Please: 1) split it into specific propositions that data could falsify; 2) say what data would be needed — sample, time range, control group — and which of these the claim leaves out; 3) separate correlation from causation and give at least one alternative explanation; 4) rate the source (primary research, secondhand report, vendor material, no source); 5) give me a checklist of where to look up the underlying numbers.

Chinese description → structured English prompt

Turn the Chinese description below into an English image-generation prompt. Structure: subject and action → materials and environment → style → lighting → composition and camera → aspect-ratio parameter (--ar). Requirements: be specific enough that it can actually be drawn; do not use words like 'beautiful' or 'premium feel'.

[Chinese description]

Find usability problems instead of debating whether it looks good

Here is my UI design description: [description]. Review it from a usability perspective and list the problems: 1) Is the information hierarchy clear — what does the user see first? 2) Can the primary action be found easily? 3) Where does the user have to recall or guess? 4) How should the empty, error, and loading states each be designed? Do not comment on whether the color scheme looks good.

The developer who picks it up should not need to ask you anything

Turn the requirement below into a design spec (no code). Include: 1) The actions the user must complete, in order; 2) The UI elements and states at each step; 3) Exceptions and edge cases; 4) What not to do (explicit exclusions); 5) Acceptance criteria.

[requirement]

Translate 'I want it to feel premium' into executable requirements

I need to create [thing] and brief a designer, but I don't know design terminology. Write me a visual brief: 1) What this design is for and who it is for; 2) The feeling I want to convey (3 adjectives + concrete references); 3) Elements that must appear; 4) Elements that must never appear; 5) Deliverables list and sizes.

Turn an image you like into a reproducible prompt, not just a saved link

This is a reference image I found: [image description, or attach the image]. Reverse-engineer a prompt that could reproduce this style: 1) Break down the composition — subject and materials, light direction and color temperature, lens and depth of field, where the visual weight sits; 2) Extract style cues — brushwork or texture, the closest genre and medium, traces of post-processing; 3) Write one English prompt in the order subject → environment → style → lighting → camera → parameters; 4) List the 3 features most likely to come out wrong, with matching negative prompts; 5) Give an acceptance checklist: which features must be present for the result to count as a successful reproduction. Do not just stack adjectives.

Not hex codes — a palette you can derive and adjust

I need a color scheme for [product/page], but I don't want to just receive a few hex codes. Give me a scheme I can derive: 1) First rank the goals the colors must serve (readability, mood, brand recognition) and explain the ranking; 2) Explain why the primary color is that hue, and on what basis; 3) Give the logic of the neutral scale — how much lightness separates background, card, divider, and secondary text; 4) Set a usage quota for the accent color: at most how many appearances per screen, and only on which elements; 5) Give the adjustment rules for switching to dark mode. Do not use unactionable terms like 'premium gray'.

What the interface should say when there is no data or loading fails

Write the empty-state and error-state copy for [page/feature], across five scenarios: 1) First use, no data yet; 2) No results after filtering; 3) Failed but retryable; 4) No permission; 5) Network down. For each scenario give three things: main copy (within 12 words, saying what happened), a supporting line (why it happened, and what to do next), and a button label (starting with a verb). Rules: don't blame the user, don't say 'Something went wrong' — it carries no information, no cutesy tone, no exclamation marks. At the end, mark which scenarios can share one set of copy.

Count how much a user has to remember and decide on one form

Here is my form design: [field list and grouping]. Review it for cognitive load: 1) Count how many pieces of information the user must hold at once, and point out where that exceeds 3; 2) Which fields can be deferred, merged, or filled in by the system; 3) Which choices require looking something up elsewhere before they can be answered; 4) When do validation errors appear, and would they wipe out what has already been entered; 5) Reclassify the fields as required / can be added later / can be removed. Finally, give a trimmed field order and say what replaces each removed field.

Turn 'young, professional, warm' into sentences you can make tradeoffs with

Our brand tone is: [3 adjectives + a short description]. Turn it into 4 design principles. Each one must: 1) Be a sentence usable for making tradeoffs, e.g. 'Better to drop one entry point than to make the primary action something users have to hunt for'; 2) Come with one good example and one counterexample, down to UI elements; 3) Name which other principle it conflicts with, and which one wins; 4) Describe how it is most likely to be misused. Do not output a list of adjectives, and do not write 'user-centered' or anything else that applies to every product.

Find the icons whose stroke width, corner radius, or visual weight does not match

These are the icons used in my interface: [icon list or screenshot]. Check them for consistency: 1) Is stroke width uniform — how many pixels does it differ by when scaled to the same size; 2) Are corner radii and line caps handled the same way; 3) Is visual weight balanced — which icon looks too heavy or too light at the same size; 4) Are the metaphors consistent, or is one concept drawn two ways; 5) Name the 2–3 that must be redrawn, and give the specs for redrawing (canvas, stroke width, corner radius, negative space). Do not judge whether the icons look good.

Write spacing, type size, and hierarchy so developers do not have to guess

Turn this design into specs a developer can use directly: [design description or screenshot]. Requirements: 1) Define a spacing scale (e.g. 4/8/12/16/24/32) and state which steps this page actually uses; 2) By section, list the outer margin, section gap, element padding, and the gap between text and icons; 3) Specify the hierarchy of font size, line height, and weight, plus which text may wrap and how it aligns after wrapping; 4) Mark which values must be exact and which can be flexible; 5) Give the values for narrow screens. Do not just say 'keep spacing consistent'.

Extract what to change from a pile of complaints — and what not to act on

Here is the raw user feedback: [paste feedback]. Turn it into a design change list: 1) First merge it into no more than 6 problem categories, each with an occurrence count; 2) Separate what users say from what they actually run into — mark which are wording problems and which are flow problems; 3) Give one change action per item and note whether it changes the UI, the flow, or the copy; 4) Sort by 'people affected × cost of the fix'; 5) List which suggestions should not be followed, and why. Do not treat feedback as requirements, and do not rank something first just because it was said loudly.

Break "this looks good" into rules for grid, hierarchy, and density

Here is a reference image I like: [attach or describe]. I don't want to replicate this image; I want it broken into rules I can apply to other pages. Extract six layers: 1) grid and content width; 2) spacing rhythm, annotated in multiples of 4 or 8; 3) type scale and line height; 4) colour roles — how much area goes to background, surface, text, and accent; 5) corner radius, border, and shadow values; 6) information density — how many visual blocks share one screen. Write every rule as a number or a testable condition. Also flag what is incidental to this image (the photo's content, the length of its copy) and cannot become a rule. Finish by describing a page with completely different content using these rules.

Re-rank the first screen around the one task the user came for

This is my page: [screenshot or content inventory]. Review the information priority of the first screen: 1) List what is actually visible above the fold and rank its current visual weight by area and contrast; 2) Decide the single task the user came to this page for, and name the one element the eye should land on first — only one; 3) Point out what competes for attention without earning it — decoration, duplicate entry points, promotional blocks; 4) Give a reordered version using four levers, size, contrast, position, and negative space, and annotate each change; 5) Run a cover test: if only three elements could remain, which three, and why. Do not use the word 'clearer'.

Fix grid, stroke, and radius as numbers so the next 20 icons need no debate

I am defining an icon system for [product]. More than 20 icons will be drawn, possibly by a contractor. Write a spec that can be executed directly: 1) Canvas and live area, for example a 24×24 canvas with a 20 live area and 2 of bleed on each side; 2) Stroke width values, and whether they scale with the icon; 3) Corner radius and line-cap treatment; 4) Optical weight compensation — how circles, squares, and triangles are adjusted at the same size; 5) Naming and export, including sizes, formats, and dark-mode variants; 6) A five-item acceptance checklist, each one tickable. Finish with one correct and one incorrect example described in words, naming where people most often get it wrong. Do not write adjectives like clean and consistent.

What should happen in the 400ms after the user taps New

Scenario: a list page is empty on first use. The user taps New, submits, and the first item is created. Design the transition from empty state to content: 1) The state sequence — empty, submitting, skeleton, partial appear, complete; 2) Duration and easing for each step, keeping the whole thing under 400ms; 3) How to prevent layout shift, including reserving height and keeping skeleton dimensions identical to real content; 4) Where focus and scroll position go; 5) Accessibility — what changes under prefers-reduced-motion, and whether aria-live is needed; 6) The three things this transition must confirm to the user. Give a timing table showing what the user sees at each step.

Fix what the user actually hit, not what they asked you to fix

The user's exact words: [paste complaint]. Do not implement it as stated. Break it down: 1) Fill three columns — what they said, what they actually did, what they actually ran into; 2) List three possible interface causes, ranked by likelihood, each with its evidence; 3) For the most likely one, give the smallest change and say whether it touches copy, a control, or the flow; 4) Point out what new problem the literal request would introduce; 5) Give a way to verify — which metric, and for how long before calling it fixed; 6) Write one sentence back to the user that promises nothing you cannot deliver.

Measure contrast, glow, and elevation instead of eyeballing a dark theme

This is my dark-mode palette: [values or screenshot]. Assess readability risk and give numbers for each item: 1) Contrast ratios for body text, secondary text, placeholder, and disabled states against their backgrounds — flag anything under 4.5:1; 2) Whether the background should be pure black or an elevated surface like #121212, with the tradeoff; 3) Which saturated colours vibrate against a dark ground and need desaturating or lightening; 4) Shadows are nearly invisible in dark mode — what should carry elevation instead; 5) How to handle images, illustrations with white backgrounds, and 1px dividers; 6) Where fatigue sets in after ten minutes of reading. Finish with a revised palette.

Put every field on trial instead of squeezing the form tighter

These are my form fields: [list and what each is for]. Put every field on trial for deletion, answering four questions each: 1) If it were gone, could the user still finish the task; 2) Could this information come from somewhere else — the account, a previous entry, the device, a third party; 3) Could it be asked later, in settings, on a second visit, or on the result page; 4) What does it buy (compliance, fraud control, personalisation, marketing), and is that worth one more abandonment. Then give four columns: must delete, can merge, can defer, must keep. Finish with the trimmed field count and order, and an estimate of how completion rate moves. Do not cut for the sake of cutting.

Break it into contrast, tap target, competing elements, and position

My primary button on [page] has been reported as not obvious enough. Break that into measurable items: 1) Contrast between the label and the button fill, and between the button and the page background — give the current and target values for each; 2) Tap target size, and whether it reaches 44×44; 3) How many elements on the same screen are brighter, larger, or more saturated than it — list them; 4) Where it falls in the user's scan path, which visual stop it is; 5) Whether the screen has exactly one primary action. Then give three change options, each naming the single variable it changes, the expected effect, and how to verify it, such as time to first click or task completion rate. Do not just say 'make it bigger and bolder'.

Find only what is most likely wrong — no upsides

Here is my judgment: [my conclusion]. Do one thing only: find what is most likely wrong with it. Requirements: 1) Give at least one counterexample or contradicting data point; 2) Name the variables I may have missed; 3) Say when the error would first surface if the judgment is wrong. Do not reassure me, and do not add the merits.

Dimensions, worst cases, and the conditions for each option

Help me choose between [Option A] and [Option B]. Requirements: 1) List 4 comparison dimensions and explain why those four matter; 2) What is the worst case for each, and can I absorb it; 3) Under what conditions would I pick A, and under what conditions B; 4) Given my constraints [my constraints], give one clear recommendation — do not say 'each has its pros and cons'.

Assume it has already failed, then work backwards

Assume [project/plan] has failed completely six months from now. Write the post-mortem: 1) The 5 most likely reasons for failure, ordered by probability; 2) For each reason, what the early signal looks like today; 3) Which causes can be prevented right now; 4) If you could do only one thing to reduce the chance of failure, what would it be.

Find the premises the conclusion never states

Here is my reasoning: [reasoning]. Please: 1) List every implicit assumption in it (premises that are never stated but must hold); 2) Mark the most fragile one; 3) If that assumption does not hold, how does the conclusion change; 4) What information would make me more certain.

The same number tells a different story under a different definition

The claim I came across is: [conclusion + data]. Do one thing only: take apart how it was measured. 1) What are the numerator and the denominator, and does either include things that should not count; 2) How was the time window chosen, and does the conclusion hold under a different one; 3) Who is in the sample, and who was excluded; 4) Is it a mean, a median, or a percentage — what happens with another one; 5) Is there survivorship bias, or fake growth caused by a shrinking denominator. End with one line: how is this number most likely to be misread. Do not judge whether the conclusion is right.

Two things moving together does not mean one drove the other

I believe [A] causes [B], based on: [observed correlation or data]. Falsify this causal claim: 1) List at least 3 third variables that could explain both A and B; 2) Point out the possibility of reverse causation — the path where B causes A; 3) Say under what conditions the correlation would disappear; 4) Give a test that could distinguish causation from correlation, and the data it would need; 5) If I only have the current data, how far can my conclusion actually go. Do not affirm my judgment first.

Decide before you start what would tell you to stop

I am about to start [plan] and invest [time/money/people]. Help me set exit conditions before I begin: 1) List 3–5 observable signals that would mean the direction is wrong; 2) For each signal, set a checkpoint, a threshold, and who judges it; 3) Distinguish 'temporarily rough' from 'wrong direction', with a concrete example of each; 4) Say how to protect what has already been invested when exiting; 5) Offer a middle option: do not stop, but shrink the scope. No encouragement, and do not assume I will follow through.

Get an order of magnitude without data, and say which step is shakiest

Help me estimate [question, e.g. how many cups of coffee this city sells in a day]. Requirements: 1) Break it into 3–5 factors that can be estimated independently, written as a product or a sum; 2) For each factor, give a value, the basis, and upper and lower bounds; 3) Compute the result and give an order-of-magnitude range rather than a precise number; 4) Mark which factor drives the result most and is least reliable; 5) Say which number to look up first in order to halve the error. Do not give a fake answer precise to the unit, and do not skip the derivation.

Separate the decisions you can undo from those you cannot

Here is my plan: [plan]. Find the most expensive irreversible parts: 1) Label each decision as reversible, reversible at a cost, or irreversible; 2) For the irreversible ones, state exactly what undoing costs — money, time, relationships, or opportunity; 3) Point out which decisions can be split into two steps, starting with a small reversible version; 4) Recommend an execution order: what to do first, what to push back as far as possible; 5) Which single wrong call would make the whole plan impossible to continue.

List the questions you never thought to ask

I am about to do [thing]. My current understanding and information: [current state]. List only the things I do not know I do not know: 1) The 5 key variables outsiders usually miss in this field; 2) Which questions I never thought to ask that would change the plan once asked; 3) Which words in my description are vague and could be read differently by different people; 4) If someone who has done this read my plan, what three questions would they ask first; 5) Order by 'would this overturn the plan'. Do not summarize what I have already said.

Not a straw man — the strongest version of their case

My position is: [position]. Write the strongest version of the opposing case — strong enough that I would find it hard to answer: 1) First restate my position in their vocabulary and confirm nothing is distorted; 2) Give 3 of the most damaging objections, each with evidence or a mechanism rather than an attitude; 3) Say under what conditions my position does hold, then why those conditions may fail; 4) Mark the weakest link in the opposing case so I can respond; 5) Judge whether the disagreement is about facts, values, or interests.

Split a mixed passage into three kinds of claim

This passage mixes facts, inferences, and preferences: [paste text]. Go sentence by sentence and label each one: 1) Fact — independently verifiable by a third party; 2) Inference — derived from facts but possibly wrong; write out the reasoning chain; 3) Preference — a value judgment or stance, with no truth value in itself. Then answer: 4) Which sentence is being used as a fact but is actually an inference or a preference; 5) Which inferences could be verified with one more data point; 6) Give a version that keeps only the facts and drops the embellishment.

Kill the conclusion with the cheapest test, before you build on it

My conclusion is: [conclusion]. Do one thing only: find the shortest path to showing it doesn't hold. Requirements: 1) Give 1–3 of the cheapest tests, each doable within [time/budget]; 2) For each test, state what result would mean the conclusion fails; 3) Rank them by lowest cost and highest chance of a clean veto; 4) Name the test that, once run, makes the rest unnecessary; 5) If I can run only one, which one. Do not argue why it's true.

Split down to pieces that answer yes/no or a number

My big question is: [question]. Break it into a set of independently testable sub-questions. Requirements: 1) 4–6 of them, each answerable with yes/no or a single number; 2) For each, what data you need, where to get it, and how long it takes; 3) Flag the ones where a “no” settles the big question; 4) Rank by information gained per unit of cost and name the first three to check; 5) Separate the two kinds of question I've blurred together — factual questions and choices — and say which is which. Do not answer the big question.

Same word, two meanings, one argument

Here is the argument: [paste it]. Find where a term changes meaning. Requirements: 1) List the recurring key terms and what each one actually means in each sentence; 2) Show the step where meaning A slides into meaning B, quoting both sentences side by side; 3) Explain which conclusion the slide makes look supported; 4) Pin the term to a single meaning and rewrite the argument; 5) Does it still hold? If not, which step is missing. Do not comment on style.

Check only whether the estimate runs low — not whether it's worth doing

My estimate for this plan is: [total cost / timeline]. Check one thing only: is this estimate systematically low? 1) List the cost lines that usually get missed — communication, migration, rework, training, compliance, maintenance, opportunity cost; 2) Give each a magnitude and a basis, not “there may be some”; 3) Name the line that most often overruns on comparable projects and by how much; 4) Separate one-off from recurring costs, and annualize the recurring ones; 5) Give a conservative number and a worst case, and say which step drives the gap. Do not judge whether the plan is worth doing.

Check the variance band before you call it a trend

I'm seeing [metric] move [change] and reading it as [trend]. Answer one question only: noise or signal? 1) What is this metric's normal historical range, and how many standard deviations is the current move; 2) How many periods of data do I have — enough to call a trend; 3) Is a one-off event, a definition change, or seasonality at work; 4) If it's noise, how long until it reverts on its own; 5) To confirm a signal, what is the minimum further evidence and when would it arrive. End with one sentence on what I can claim today.

Rank the decision by “can I undo this,” then set the order

The decision I'm making is: [decision]. First pull out the irreversible parts and put them in order. Requirements: 1) Mark each action that can't be undone, with the concrete cost of undoing it; 2) What future options each one locks shut; 3) The cheapest information available before you push it — a pilot, a trial order, a quote, a small rollout; 4) The sequence: which must happen now, which can wait for more information, and the latest date for each; 5) Which single one, if wrong, invalidates the whole decision. Do not judge whether the decision should be made.

Write the failure modes first, then the first 24 hours

My judgment is: [judgment], and I've already committed [money / time / promises] to it. Write the “if I'm wrong” plan: 1) Three most likely ways it's wrong, ranked by probability × loss; 2) For each, the earliest observable signal and how soon it appears; 3) What to do at 24 hours, one week, one month after detection; 4) What to prepare now — fallback, budget, what to tell people; 5) Which step is unrecoverable past a certain date, and what that date is. Don't reassure me, and don't say it probably won't happen.

Take apart your own reasoning and see what's left

I'm leaning toward [option] because: [my reasons]. Split those reasons into two columns: facts and preferences. 1) Label each one — a fact must be independently verifiable by a third party; a preference is a ranking of values or a position; 2) Point out which “facts” are preferences in disguise, like calling “I know this better” a matter of “it's safer”; 3) With every preference removed, do the facts still support the choice; 4) Do my preferences contradict each other — wanting both speed and safety; 5) Name the one preference that, if it changed, would flip the conclusion. Don't choose for me.