Ambition · an agent skill
The essay ↗Hand your agent a task. Get back the more ambitious version of it, and the judge that will prove it worked.
Most of the time we ask a model for the task we already had in mind. In “How to be more ambitious”, Felix Rieseberg, an engineering manager at Anthropic, makes a clear and generous case that a task is only our best guess at the outcome we want. His essay inspired this skill, and I highly recommend reading it first. It takes eight minutes, and the framework here is all his. The bigger wins, he shows, come from asking for a different task: one that sits higher, goes deeper, or pulls in more fields.
Ambition is an agent skill that does that pass for you, in Claude, Codex, Cursor or any agent that reads SKILL.md. Give it a task and it returns the baseline, a ranked list of more ambitious versions, and a rewritten brief you can run. Each version names something other than the model that would prove it worked. Then it stops, so the choice of what to take on stays yours.
Four kinds of ambition
Felix sorts ambition into four types. The skill runs all four on every task and lets the kind of work decide which one leads.
- Speed
The same work in less time.
Felix skips it as the easy one. The skill keeps it as the baseline that every upgrade is measured against. - Altitude
Going up in abstraction and considering the outcome rather than the individual task.
“Fix this crash” becomes “keep the app crash-free.” - Depth
Considering a task the way a field-leading expert would.
Raw data instead of summaries, the instruments professionals use, and a judge that isn't the model. - Range
Drawing on multiple fields rather than just the one the task might need at the surface.
Turn the deliverable's nouns into verbs, then assemble the crew that does those verbs, including an adversary.
Writing a prompt
Type /ambition and the task, the way you would have asked for it anyway. Two optional words steer it.
planningAltitude leads: the outcome, the decisions it feeds, a workflow that keeps running.
researchDepth leads: raw data, a challenged assumption, something new checked on unseen data.
featureDepth, then Altitude: tests or benchmarks as the judge, then owning the outcome.
lightOne line per type and exactly three upgrades, in under 450 words.
fullEvery question answered, the crew run as parallel subagents, and the top five upgrades. Picked on its own when the result feeds a decision that's costly to reverse: money, headcount, a launch, a public claim.
- A feature
/ambition add a CSV export button to the orders table - A research question
/ambition why did our open rate drop from 41% to 33%? research - A plan
/ambition plan our team's two-day offsite, full - Anything
/ambition write the onboarding email for new customers
You don't need the slash command. Agents that support skills also pick it up when you ask them to think bigger or make something more ambitious, and each agent has its own way to call a skill by name.
What the agent does
Five steps, in order. Steps one to three are Felix's techniques, mostly in his words; the baseline and the synthesis are what turn them into something you can run.
- Baseline.
Write the literal task in one sentence and the fastest competent way to do it. This is the control.
- Altitude.
Climb from the task to the outcome in two or three rungs, each with the access it needs. Stop where the result can no longer be measured. “Go make money” is past that point.
- Depth.
Answer Felix's four questions: what a top professional would add, the rawest material they would start from, the real methods and tools, and what outside judge would show it is right. Then set a stretch target, name an assumption to test, and look for one thing nobody knows yet.
- Range.
Rewrite the deliverable as verbs, pick three to five fields including an adversary, and state the method each field brings. In full mode each field runs as its own read-only subagent.
- Synthesis.
A ranked table of upgrades with type, cost, payoff and judge, ranked by payoff against cost rather than one per type. Then a recommended brief and a list of what it needs from you. Then it stops.
| Size | What you get | When |
|---|---|---|
| Light | One line per type, exactly 3 upgrades, no subagents, under 450 words | The default |
| Full | Every question answered, the crew as subagents, top 5 upgrades, a brief ready to run | When the result feeds a costly decision, or when you ask |
If a task is trivial, the skill says so in one line and just does it. Called by name on a small task, it still runs the pass but keeps the brief to the task as asked.
Three real runs
Unedited output from Claude Opus 5.5 running the skill on three made-up tasks on 16 October 2026. None of them had access to real data, which is why each one ends with a list of what it needs.
/ambition Add a CSV export button to the orders table in our admin dashboard. light
Ambition: Add CSV export to the orders table [feature] [light] 2026-10-16
Baseline
Add an "Export CSV" button that turns the rows already loaded in the orders table into a CSV in the browser and downloads it.
Passes
- Altitude: The CSV is someone's guess at an outcome. Find where the file goes next (bookkeeping, a 3PL, refunds) and own that handoff, so nobody has to export at all.
- Depth: Stream every row that matches the current filters from Postgres on the server, with a fixed column contract and formula-injection escaping. Stretch target: 1M orders with flat memory and first byte under 300 ms.
- Range: As a verb, the export is "get order data to where the next decision is made, without leaking it." Crew: an accountant (columns that tie to payouts), a data engineer (streaming and the column contract), a pen tester (who can pull customer PII, CSV injection).
Upgrades (ranked)
| # | Type | Upgrade | Cost | Payoff | Judge |
|---|---|---|---|---|---|
| 1 | Depth | Server-streamed export of all filtered rows, fixed columns, injection-escaped | ~1-2 h agent; column list from ops; seeded DB | Right file at any size, opens cleanly in Excel | Round-trip test against the DB on a hostile fixture; 1M-row load test |
| 2 | Range | Role-gate the export, drop unneeded PII, write an audit row per export | ~1 h agent; a decision on roles and PII | Customer data cannot leave silently | Tests: a disallowed role gets 403; each export writes an audit row |
| 3 | Altitude | Replace the recurring export with scheduled delivery to its real destination | Hours of agent work; 15 min with the ops lead; two weeks elapsed | The manual step disappears | Audit log shows manual exports falling to zero over two weeks while totals still tie to payouts |
Recommended brief
Add CSV export to the orders admin. In a server route, stream every order that matches the table's current filters from Postgres (cursor or COPY, never buffered in full). Use a fixed, documented column list, RFC 4180 quoting, a
'prefix on cells starting with=,+,-,@, a tab or a CR, UTF-8 with a BOM, money as decimal strings and timestamps in ISO 8601 UTC. Allow only [roles], leave out [PII columns], and insert anorder_exportsrow (user, filters, row count, time) for every export. Prove it with a round-trip test on a hostile fixture (formulas, commas, quotes, emoji), authz and audit integration tests, and a 1M-row seeded load test that reports first-byte time and peak memory.
Needs from you
- Access to the repo and to a seeded or staging Postgres, and whether the agent can run tests there (all unknown).
- The columns ops needs, and where the file goes after it downloads.
- Which roles may export and which fields count as PII.
- The host's response-time limit (a serverless timeout caps how long a stream can run).
/ambition Figure out why our newsletter's open rate dropped from 41% to 33% over the last two months. full
Ambition: Explain newsletter open-rate drop from 41% to 33% [research] [full] 2026-10-16
Baseline
Export per-send stats from the ESP dashboard, chart open rate against known changes (subject lines, send time, list growth, template), and write a one-page memo naming the likely cause.
Passes
Altitude
- Explain the 8-point drop and what to change before the next send. Needs: ESP exports, a dated log of changes since June.
- Know whether readers are receiving and reading each issue, by mailbox provider and cohort (the number that matters if sponsorships are priced on opens). Needs: event-level data, Google Postmaster Tools, Microsoft SNDS, DMARC reports.
- Own reader engagement continuously: after every send, split any change into measurement, list mix, deliverability and content, track a human-engagement metric instead of raw opens, and alert before a slide reaches 2 points. Needs: read-only ESP API, a scheduled job, an alert channel.
Stop there: "grow the newsletter" is past what this access can measure.
Depth
- Unasked: check whether the ruler moved before the readers did. Since Apple Mail Privacy Protection, many opens are machine prefetches, and ESPs change how they filter machine and scanner opens. A filtering change, a shift in the Apple share, or a new denominator (sent vs delivered, suppression rules) can move the rate 8 points with no change in reading. Then check inbox placement by provider.
- Raw material: per-recipient events for 26 weeks (every open and click with timestamp, IP and user agent; bounce and deferral codes; unsubscribes; complaints), the subscriber table, DMARC aggregate XML, Postmaster history, raw headers from a seed send. Not the dashboard percentage.
- Methods and tools: DuckDB over the export; rule-based classification of opens and clicks (Apple proxy, scanner hits seconds after delivery, human); Kitagawa decomposition of the 8 points into list mix vs within-segment rate across provider x signup cohort x source; change-point detection (ruptures) to date each break against the change log; a fixed cohort present all 26 weeks; a seed-list placement test (GlockApps or similar).
- Outside judge: human clicks per delivered, scanner clicks stripped; Postmaster Tools and seed placement; the ESP's written confirmation of any tracking or filtering change and its date; forecasts scored against the next three sends.
Stretch target: named causes summing to at least 7.6 of the 8 points (95%), each confirmed outside the analysis, plus a forecast of each of the next three sends' open rate within ±1 point, recorded before they go out.
Assumption to challenge: "Fewer people are reading." Rebuild the fixed cohort's rate from raw opens with machine opens removed. If human opens and clicks are flat, the drop is measurement or mix, and the 41% may have been the inflated number.
New knowledge: what share of this list's opens are human, by provider, and whether a composite of human opens, clicks and replies predicts 90-day retention better than raw opens. Fit on a random 80% of subscribers; test on the held-out 20% and the next four sends.
Range
Verbs: not "a memo on why opens fell" but "tell readers from machines, find who stopped receiving or reading and why, and decide what to change before the next send."
Subagents skipped: no raw material in reach yet.
| Field | Method | Artifact | Needs |
|---|---|---|---|
| Deliverability engineering | Authentication alignment, reputation history, bounce codes by provider, seed placement | Per-provider placement timeline | DNS, Postmaster, SNDS, DMARC reports, seed tool |
| Demography | Rate standardization, Kitagawa decomposition by cohort | Composition vs within-segment waterfall summing to -8 pts | Subscriber table with signup date, source, domain |
| Ad-fraud measurement | Classify machine opens and clicks by IP range, user agent, latency | Human-only open and click series per send | Event-level opens and clicks with IP, UA, timestamps |
| Survey research | One-question survey and short interviews of readers who went from clicking to silent | Reasons in readers' words, coded by frequency | OK to email a targeted segment |
| Forensic accounting (adversarial) | Restate six months under one metric definition; hunt definition breaks; test whether 41% was inflated | Restated series and dated list of breaks | ESP changelog, the export, figures quoted to sponsors |
Upgrades (ranked)
| # | Type | Upgrade | Cost | Payoff | Judge |
|---|---|---|---|---|---|
| 1 | Depth | Restate the series from raw events: human vs machine opens, fixed cohort, per provider | ~1 hour of agent time; you supply the event export | Know whether readers left or the ruler moved | Human-click series; ESP's written confirmation of any filtering change |
| 2 | Depth | Decompose the 8 points into mix vs rate, date each break, forecast the next sends | Hours of agent time; subscriber table and change log; three weekly sends | Named causes covering at least 95% of the drop | Forecasts within ±1 pt on the next three sends |
| 3 | Depth | Deliverability audit plus seed-list placement test | ~1 hour of agent time; DNS, Postmaster, SNDS access; seed-tool subscription; one send | Learn whether Gmail or Outlook are sending you to spam | Seed placement results; Postmaster spam rate and reputation |
| 4 | Altitude | Post-send monitor: decomposition, human-engagement metric, alert at 2-point drift | ~1 day of agent time; API key, alert channel, 30 minutes to approve the metric; six sends | Catch the next slide in a week, not two months | Backtest alerts on this drop within two sends; then live over six |
| 5 | Range | Survey and interviews of readers who went silent | ~1 hour of agent time; your OK to send, 3-4 calls; two weeks elapsed | Causes in readers' own words | The respondents; reasons checked against #2 |
Recommended brief
Explain the newsletter's open-rate drop from 41% to 33% over the last eight weeks, covering at least 95% of the 8 points, each cause confirmed by a source outside this analysis. Work from raw data, not the dashboard: per-recipient events for 26 weeks, the subscriber table, a dated change log, DMARC reports, Postmaster and SNDS history.
- Load everything into DuckDB. Classify every open and click as Apple proxy, scanner or human. Restate weekly open rate as human opens / delivered and say whether the 41% survives.
- Compare a fixed cohort (present all 26 weeks) with the full list on human opens and clicks.
- Kitagawa-decompose the change across provider x signup cohort x source into list mix and within-segment rate. Date each break with change-point detection and match it to the change log.
- Audit deliverability: authentication alignment, reputation and spam rate, bounce codes by provider, one seed-list placement test.
- Try to break the conclusion twice: argue it is a measurement artifact, then a deliverability problem. Keep what survives.
- Deliver a waterfall of named causes with their outside confirmations, and a recorded forecast of the next three sends' open rate by segment within ±1 point.
Do not change send settings, lists or DNS. List what you could not confirm and what would confirm it.
Needs from you
- Per-recipient events for 26 weeks (opens and clicks with timestamp, IP, user agent; bounces; unsubscribes; complaints), or a read-only ESP API key.
- Subscriber table with signup date, source, mailbox domain.
- Dated changes since June: ESP notices, template, send time, sending domain or IP, list imports or cleanups.
- Read access to DNS, Postmaster Tools, SNDS, DMARC reports.
- Decision: seed-tool budget; OK to send one seed test and one survey.
- Whether open rate is quoted to sponsors.
- Whether the agent can run Python and DuckDB, and later schedule jobs.
/ambition Plan the agenda for our 12-person engineering team's two-day offsite in January. light
Ambition: Plan two-day January engineering offsite agenda [planning] [light] 2026-10-16
Baseline
Fill a standard two-day offsite template (kickoff, retro, roadmap, workshops, team dinner) with generic sessions for 12 engineers, in minutes.
Passes
- Altitude (lead): The real outcome is not a full agenda. It is the 3 to 5 decisions the team keeps putting off, made, owned and still holding in April.
- Depth: Pick topics from raw material (an anonymous pre-survey, postmortems, cycle-time and on-call data). Stretch target: every session ends in a written decision with an owner, and 80% of those decisions are done or still in force at 90 days. Test the assumption "we need alignment" against the survey.
- Range: As verbs: get 12 people to settle what they can't settle async, and keep it settled. Adversary: a pre-mortem run by engineers outside the planning group.
Upgrades (ranked)
| # | Type | Upgrade | Cost | Payoff | Judge |
|---|---|---|---|---|---|
| 1 | Altitude | Build the agenda backward from 3 to 5 named decisions; each session produces a decision record with an owner | ~1 hr agent; your deferred-decision list; 90 days elapsed | The offsite produces decisions, not just discussion | Mid-April review: 80% of decisions done or in force |
| 2 | Depth | Choose topics from an anonymous pre-survey plus incident, cycle-time and on-call data | ~2 hrs agent; metrics access; 1 week for responses | Time goes to the team's real pain | Post-offsite anonymous survey: at least 10 of 12 say the time went to what mattered |
| 3 | Range | Pre-mortem on the draft ("It's April and nothing changed. Why?"); cut blocks that can't answer | ~30 min agent; 30 min from 2 to 3 engineers | Weak blocks are cut before 12 people spend a day on them | Cut list from the non-organizer engineers |
Recommended brief
Plan our 12-person engineering team's two-day January offsite backward from outcomes. Draft a 5-question anonymous pre-survey. Use it plus [postmortems, cycle-time and on-call data] to name the 3 to 5 decisions the team must leave with. Build both days around them, and end each session with a one-page decision record (decision, owner, first step). Give every social block a stated purpose. Have 2 to 3 engineers outside the planning group run a 30-minute pre-mortem on the draft, and cut what fails. Deliver the agenda, the record template, the pre- and post-offsite surveys, and a mid-April review hold that scores decisions done or in force (target 80%).
Needs from you
- Dates, location, budget, and whether anyone joins remotely.
- The decisions the team keeps putting off, and who has authority to make them.
- Access to postmortems, cycle-time and on-call data (unknown whether any of it exists).
- Approval to survey the team anonymously, and an owner for the April review.
Rules it keeps
- No self-grading.Every upgrade names a judge other than the model: a test suite, holdout data, a benchmark, a reviewer, real users. Upgrades without one are cut or flagged. Felix: “Do not ask the model to judge itself.”
- Methods, not voices.Fields bring what they do, not how they talk. “Don't ask the model to write like a short seller, ask it to do what a short seller does.”
- Stretch targets are meant.A page asked to load in 5 seconds gets a 200 millisecond target. If one proves infeasible after a real attempt, the skill says what blocked it and offers the next-best target.
- Cost in model terms.Cost is model time plus what you have to supply, never human work-weeks. Those anchor on how long things took before models and talk the plan down.
- Your scope, your call.It never starts the bigger version on its own. You pick the upgrades, then run the brief.
Install
One command installs it into Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and dozens of other agents. The skills CLI asks which ones you use.
npx skills add https://nickbeaird.com/ambition/ambition.zipThe source, with the eval behind each change, is on GitHub.
Or download the skill and unzip it yourself:
Download ambition.zip| Agent | Unzip into |
|---|---|
| Claude Code | ~/.claude/skills |
| Codex, Cursor, Gemini CLI, Copilot, OpenCode (one project) | .agents/skills in the repo |
| Claude app | Upload ambition.zip under Customize, then Skills |
No skill support? The skill is plain Markdown, so it still works. Paste SKILL.md into any chat with your task underneath, or save it in your repo as docs/ambition.md and point your AGENTS.md at it:
When asked to make a task more ambitious, follow docs/ambition.md.Then hand it something you were about to ask for anyway:
/ambition plan next quarter's roadmap reviewLimits
It plans; it doesn't do the work. The output is a better brief. The ambitious version is the next run, and it costs what the table says.
It's only as ambitious as its access. Felix's point holds: every kind of ambition needs a model with a computer it can install software on and connectors to real data. Without them most upgrades land under “Needs from you”.
Altitude has a ceiling. Asking for the outcome works until the outcome can't be measured or acted on. “Claude, go make money” still doesn't work for most businesses.
Creative work gets less from Altitude. A song or a short story has no goal beyond the goal, so that step goes light. Depth and Range still help.
Cost and payoff are estimates. The judges are what keep it honest, so check that each one is something you can actually run.
Questions
- Is this official?
- No. The four types of ambition and the techniques are Felix Rieseberg's, from his essay. This is an independent packaging by Nick Beaird, not made or endorsed by Felix or Anthropic. Read the essay; it's eight minutes and better than this page.
- Which agents does it work with?
SKILL.mdis an open format, and Claude, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and many others read it. Nothing in the skill depends on one model; Felix's advice isn't model-specific either. Agents with subagents run the crew in parallel in full mode; the rest work through the fields in one pass.- Why a skill and not AGENTS.md?
AGENTS.mdholds standing instructions for one repository and loads into every conversation there. A skill loads only when the task calls for it and travels with you between projects. If your agent only readsAGENTS.md, the one-line pointer above gets you the same thing.- Why does it stop before doing the work?
- The more ambitious version usually costs more and needs your access, data or decisions. Expanding scope without asking is how agents burn an afternoon on the wrong thing.
- Can I change it?
- Yes. It's one Markdown file. Rename the modes, change the output table, or add guardrails that fit your team.
- License?
- MIT for the skill file. The framework and the quoted lines are Felix's.