Aim higher — the goal a top expert would set

Purpose

People under-ask models: they size a goal by what they believe is possible, inside the one field they trust themselves in. This skill learns how the best in the field actually work, then returns the goal a top expert would set — the outcome behind the ask, a hard bar reached with the trade's real instruments, a method borrowed from another field — still short, and still checked by something other than the agent doing it. Deeper, not bigger: a goal already sized right comes back nearly as it went in. It writes nothing; the person sets the goal it returns.

When to use / when to skip

• Use before a goal goes to an agent or a session, or on "aim higher", "be more ambitious", "sharpen this goal", "what should I really be asking for".
• Use on a raw idea before planning starts, on the brief before an unattended run, or on the bar a prototype has to beat.
• Skip a mechanical edit — a typo, a rename, a version bump — where any raise costs more than it returns, and say so in one line.
• Near-miss, nobody yet knows what they want: interview them first — interview-me, where installed.
• Near-miss, the person wants options to react to rather than one goal: idea-refine, where installed.
• Near-miss, a decision already taken, to be cross-examined: doubt-driven-development, where installed.

Inputs

• The goal as asked — helps: the material · without it: there is nothing to raise; ask for it.
• The person's constraints and Not-Doing (what they ruled out) — helps: the lines a raise never crosses · without it: take only what the ask states, and write any line you assumed under Not.
• The repository, data and tools in reach — helps: a bar grounded in what the agent can touch · without it: name what the raise needs under Needs rather than shrink the goal silently.
• The web — helps: what the best in the field have actually done, not what you remember of it · without it: raise from what you know, and write Sources: unsourced.
• Who runs the goal — helps: a person, a session and an unattended run each want a different check · without it: assume an agent running unattended.

Process

1. Strip it to the outcome. Ask yourself what has to be true in the world when this is done, and for whom. Peel off the method the ask smuggled in: "write a report" is a method; "leadership decides what to cut" is an outcome. Sort every limit into real — a budget, a date, a system it must not touch — or believed — habit, "too hard", "models can't" — and keep only the real ones. Ask yourself, too, whether the thing asked for is needed at all: the shortest path to the outcome may run through what already exists, so keep that option in play.
2. Size it before raising it. A goal earns a raise when the outcome behind it is worth more than the ask and an agent can reach it. A mechanical change comes back unchanged, with one line saying why. A goal already specific, hard and checked from outside keeps the person's own words, plus only what closes a way it could pass falsely: a missing guardrail, or an outside check in place of one the doer controls. Leaving a right-sized goal alone is a result, not a skip.

3. Learn from the best before setting anything. Rather than imagine what a top expert would do, find out. Each line of the goal is otherwise a guess, so work out who does this best — the people and the work that set the field's bar — and search the web for what they published themselves, not summaries of it, until a handful of sources answer whichever of these would change the goal:

   • Does it exist already, whole or in part? Earlier work to adopt or start from.
   • What is the bar? The best result anyone has reached, and what has just become possible — the proof a believed limit is not real.
   • How do the best work? Their methods and instruments.
   • How do they judge done? The benchmarks, standards and tests the field trusts.
   • What went wrong for them? Their failures, and what they changed after.

   What you find raises the bar and sharpens the method; it never swaps the outcome from step 1 for what a source happens to measure, and never pushes the goal past what the agent can own. Cite only pages you opened, and only for what they say. A goal step 2 left alone skips this.

4. Altitude — one level up. Ask yourself "and then what?" once, sometimes twice, and stop at the highest outcome the agent can still own end to end and be checked against. Fixing a crash becomes keeping the app crash-free; a report becomes the decisions it exists to force, argued for and against; a recurring process becomes a better one, tested against its own history. "Make money" is above the line — no agent owns it end to end — so come back down until one does.
5. Depth — work the way the best in the field work. From what step 3 found, name what the best do beyond the ask: the raw material they start from (all the data, not a summary of it), the trade's real instruments (a profiler, a load test, a statistical model, a database — not a markdown table), and a hard number. Set the number past what feels reasonable whenever a path to it can be named — 200 ms where the target was 5 s. Name the assumption under the goal and make testing it part of the work. Where the goal touches a system you cannot see, invent none of its details — send the agent to read what is there first (who may see what, how it is filtered, what already runs) and build on that. Where the agent will be deep in the data, make the goal demand something nobody knows yet, validated on data it has not seen.
6. Range — borrow from another field. Rewrite the goal's noun as a verb: a quarterly review is getting busy people to believe a cause-and-effect story and act on it. Work out which fields do that verb best, look up how they do it as step 3 did, and borrow one method or tool from them. Where stakes are high, add the specialist who would attack the result — a short seller, a forensic accountant, a red team — doing their actual work, never playing their voice.
7. Make done something the doer cannot grade. Name the check: a test suite, a benchmark, a held-out dataset, a replay against history, a blind judge in a fresh context, a real user. One the agent can run for fast feedback is best, provided the agent did not write it to pass. Put a number in it wherever one exists, and name what must not get worse — correctness, error rate, existing behaviour — so a win on one number cannot hide a loss on another.
8. Name the access the raise needs. A bigger goal fails on missing infrastructure before it fails on skill: the data, connectors, machines, test environments and credentials (by name, never a value) an agent needs to work without being steered. What the agent can find or generate itself — sample data, test queries, fixtures — is part of the work, not a precondition; list only what someone has to grant. Where a grant is missing, getting it becomes the goal's first step, or the goal comes down to what is reachable.
9. Hold the person's lines. A raise never crosses a constraint or a Not-Doing the person stated. Where crossing one would pay, offer it in one line after the goal; never bake it in. A line you add under Not names what this goal leaves out or guards against harm — money, live users, anything irreversible — and never forbids work the goal needs.
10. Pick, don't stack. Keep the two or three moves that change the outcome most and drop the rest — a goal carrying every lens reads as a wish list nobody can check. Write it in the shape and within the cap under Outputs & handoff, and return it.

Rationalizations

• "Bigger is more ambitious." → ambition is the outcome's value; twice the scope with no check is a wish.
• "That number is unreasonable." → specific, hard goals beat "do your best", and what a model can do moved since anyone last checked; the number stands while a path to it can be named.
• "The agent can grade its own result." → a doer grading itself is the false green an outside check exists to catch.
• "A summary of the data is enough." → the summary already made the expert's decisions for them.
• "Add a crew of personas." → role-play changes the transcript, not the result; the method is what transfers.
• "Even the typo deserves a raise." → inflating a mechanical goal spends the person's attention for nothing.
• "Go make money." → no agent owns that end to end yet; altitude stops where ownership does.
• "Name every lens, to be thorough." → three moves that land beat seven that blur.
• "I'll fill in how their system works." → an invented rule is a wrong spec delivered with confidence; the agent can read the real one.
• "A sharp goal still belongs in the template." → the person's words already work; reshaping them only adds risk.
• "I already know how the experts do it." → memory is a snapshot and the field has moved; their own accounts show where the bar stands now.

Red flags

• A goal block over its cap under Outputs & handoff, or wrapped in an essay.
• A Done when the doer grades, or one with no number where a number exists.
• A goal raised past anything an agent can own end to end.
• A typo or rename returned as a programme.
• A constraint or Not-Doing the person stated, quietly crossed.
• A persona doing the talking where a method should be doing the work.
• A raise that leans on data or access no Needs line names.
• A detail of the person's system stated as fact, never having been read.
• A Needs line that has the person do the agent's prep before it can start.
• A raised goal whose bar no source backs while the web was in reach — or research that came back as a report instead of a goal.

Verification

• On a raised goal, Goal names an outcome, not a method, and the level above it was weighed.
• On a raised goal, Done when holds a check the doer did not write and cannot grade, with a number where one exists, and names what must not get worse.
• On a raised goal, Needs names every piece of access the raised goal leans on, or says nothing new is needed.
• Every constraint and Not-Doing the person stated survives, in the goal or under Not.
• On a raised goal, the notes name the sources its bar and method came from, or say the bar is unsourced.
• A right-sized goal kept the person's words, with one line saying why.
• The goal block is within its cap under Outputs & handoff, with its parts named in a note when it runs past 100 words.

Outputs & handoff

• One goal block, in conversation — nothing written to disk. Cap 100 words; 200 only for work spanning several separate systems or stages, each needing its own check — three client platforms, or a launch spanning product, pricing and press. A cap is a ceiling, not a target. In this shape:

  Goal: <the outcome, one level up, carrying its hard number>
  Done when: <a check the doer did not write and cannot grade>
  Needs: <data, tools and access to grant first — or "nothing new">
  Not: <the person's lines, and what this deliberately leaves out>

• A right-sized goal skips the shape: the person's words, plus any check step 2 added, and one line saying why it stays.
• Below it, at most three lines, each naming a move and the lens it came from, plus any offer from step 9; for a goal over 100 words, one line naming its parts; and, on a raised goal, one Sources: line naming what the bar and method came from, or unsourced. Nothing else. These notes are for the person, not part of the goal, so the word cap does not count them.

• Example — "write the onboarding guide for new engineers" comes back as (its notes left out):

  Goal: A new engineer opens a passing, reviewable pull request on day one, with no help past hello.
  Done when: three fresh agents with no repo context, then the next real hire, each go from clone to
  that pull request in under 4 hours using only the guide; every stall is fixed and re-run.
  Needs: a clean container image, a starter-issue list, read access to the repo.
  Not: no rewrite of the build system.

• Hands on: the person sets the goal — as a session goal, a task's brief, or the input to whatever plans or builds next (in achilles-skills, /ideate or /gauntlet-loop). No verdict; this skill grades nothing.