Claude always gives you safe little answers—this command makes it ask three layers first

Claude easily turns a task into a small, safe version. You ask it to fix a crash, and it gives you a patch; you ask it to design a course, and it gives you an outline. The problem is often that the prompt fixes the size of the task. That's the step /be-ambitious tries to change.

It is a free Claude skill, with the project at robonuggets/be-ambitious. The author, RoboNuggets, broke Felix Rieseberg's article How to be more ambitious: a tutorial for humans with models into steps an agent can follow. Felix works on Claude at Anthropic, and these ideas are his.

It mainly uses three ambition questions:

• Altitude: What is the goal above the goal? For example, don't just fix a crash; make the app stop crashing.
• Depth: How would a true expert in this field work from the raw data, and what external check would prove it was done right?
• Range: Which other fields should be involved, and what would experts in those fields actually do?

The fourth one, Speed, is skipped. The source material says most people already use AI this way—to do the same things faster.

Install for all projects:

git clone https://github.com/robonuggets/be-ambitious ~/.claude/skills/be-ambitious

Then invoke:

/be-ambitious [your task]

To install it for only one project, put the skill in the project's .claude/skills/be-ambitious. claude.ai users can package SKILL.md and LICENSE into a be-ambitious folder and upload it to Skills. You can also just say be more ambitious with this.

After receiving a task, it first looks for the goal above the goal, then chooses the appropriate ambition type(s)—usually one or two, without forcing all three. Next it writes a plan, listing the data, tools, and access permissions needed, and clearly stating what's missing. Finally, it rewrites the prompt and closes with an external check. If you give it a task, it goes on to do it; if you give it a prompt to improve, it stops at the rewritten prompt.

There is a real test in GitHub: a marketing website takes 8 seconds to load. The plan it produces starts from a real trace, first using Lighthouse, WebPageTest, a network waterfall, and a bundle analyzer to find the biggest causes of delay, then fixing them in order and measuring after each fix. The target is set at about 200 ms for useful first-screen content. The external judge is repeated measurements and real user data. The plan also adds a deployment check to prevent the site from slowing down again.

The limitations also need to be clear. It requires the model to have a computer where it can install software and access to real data, whether via an MCP connector or another method. Without these, it lists what's missing and what each missing item would unlock, without making up data. The project also maintains several hard lines: better, not bigger; do what an expert would do, don't role-play; don't grade yourself; hard targets must be reasonable, and report honestly according to the checks.

Someone in the comments asked whether it would make simple tasks complicated. Another suggestion was more specific: after altitude, depth, and range, first write a minimal slice to prove the big goal, get it working, then build the rest. That cap is worth adding.

If you often feel that Claude's answers are 'right, but too small,' give it a try. Before installing, confirm two things: it can install software, and it can get real data. Without these two, it won't conjure ambition for you.