Apply it: summarize, rewrite, extract

Four jobs make up most day-to-day use: summarising, rewriting for a different reader, pulling structured data out of prose, and generating options. Each has a characteristic way of going wrong, and each is fixed by asking for something more specific than the job's name.

Summarising loses decisions. "Summarise this thread" averages everything: a settled decision and an offhand aside come out weighted the same, and the one line you needed — who agreed to what — dissolves into the general sense of the discussion. Ask for the parts instead: the decisions, the actions and their owners, and the questions still open.

Instead of:
  Summarise this meeting transcript.

Ask for:
  From this transcript, list:
  1. Decisions made (and by whom)
  2. Action items with owners and dates
  3. Questions raised but not answered
  Mark anything you're unsure about as "unclear" rather
  than guessing.

Rewriting drifts. A message rewritten for a busy manager and the same message rewritten for a new starter should differ in what they include, not just in vocabulary — the manager's version can drop the explanation and keep the ask; the new starter's needs the reverse. If both versions say the same things in different words, the rewrite hasn't happened yet.

Extraction invents. When a field is missing from the source, the most fluent thing to do is produce something plausible. Head it off by naming the fields you want and saying what to do when one isn't there: leave it null, or mark it "not stated". Without that instruction you can't tell a real value from a confident guess.

Brainstorming converges. Ask for ten ideas and the first three will be the obvious ones. Push past them explicitly: ask what a competitor with half the budget would do, or what you'd try if the obvious option were banned. For critique, ask for the strongest objection rather than "feedback" — feedback comes back agreeable, while an objection has to argue.

Loading your workspace…