One prompt built 40 CLI commands and 847 tests. Here’s the setup.

847 tests. 40+ commands. Not a single line of code written by hand.

That’s what one developer shipped for a ClickUp CLI tool, built entirely through a single repeatable prompt. A Redditor going by u/krodak shared the setup in r/PromptEngineering, and it’s worth breaking down because it’s not magic. It’s a system.

The prompt itself is short. Here it is, exactly as shared:

Use brainstorming skill to prepare for implementing <task>,
ask as many questions as needed

Let's go with Approach <A/B/C>

Use writing-plan skill to prepare complete plan as
.md file for <task>

Use subagent-driven-development and executing-plans
skills to implement complete plan and confirm it with tests

Do not make development yourself, act as orchestrator
for subagents, by using dispatching-parallel-agents.
If you have further questions, make decisions on your
own and document them in DECISIONS.md

Keep PROGRESS.md to track progress and carry on this
to your next agents. Point subagents to those files
and link to them in compacting summary.

That’s it. But the prompt only works because of what’s built around it.

Why a short prompt can do this much

The prompt references “skills,” which are markdown files from the obra superpowers library. Each skill is a 100-300 line file describing a structured workflow: how to brainstorm approaches, how to write implementation plans, how to spawn sub-agents for parallel work, how to review. The agent reads the skill and follows it.

Think of the prompt as the main() function. The skills are the implementation. Instead of cramming all the workflow logic into one giant prompt, you just call the right skill in the right order. Complexity lives in the skills, not in what you type. This also means updating a skill once improves every future run that references it, without touching the prompt at all.

In practice, when the creator runs this for a new feature, here’s what happens:

1. The agent reads the brainstorming skill, asks clarifying questions, proposes 2-3 approaches
2. The author picks one
3. The agent reads the writing-plan skill and creates a detailed .md plan file
4. It reads the subagent-driven-development skill and dispatches parallel sub-agents, one per task in the plan
5. Each sub-agent writes code and tests, the orchestrator reviews

One feature (time tracking: 6 commands, fully tested, documented) took 10-15 minutes of the creator’s time. Most of that was reviewing the plan and picking an approach.

3 practical applications

You don’t need to replicate this exact stack. Here’s where the core idea maps to real work:

• 🔹 CLI or library development. Add an AGENTS.md to your repo that describes your release conventions, version bump process, and testing standards. Pair it with obra superpowers skills and you have a reusable loop for every new feature, from idea to npm publish.
• 🔹 Internal tooling with no dedicated dev time. If you’re building scripts or automation and keep context-switching, this pattern lets you hand off implementation to sub-agents. You become the approver, not the builder. Most decisions get documented in DECISIONS.md without you touching them.
• 🔹 Shipping a SKILL.md with your own tools. The creator’s CLI includes a SKILL.md that teaches any AI agent the command reference. It only loads when relevant tasks come up, so it doesn’t clutter long sessions. If you build tools that others use with AI assistants, this is a low-effort addition with real payoff.

Tips and pitfalls

A few things worth knowing before you copy this setup:

• The brainstorm step is optional. The creator skips it for simple tasks like “add comments functionality” and just picks an approach when asked. Use it when the implementation path isn’t obvious, skip it when it is.
• PROGRESS.md is what keeps parallel sub-agents coherent. Without a shared progress file, each sub-agent starts from scratch. Point each sub-agent to PROGRESS.md at the start and require it to update before handing off. This is the piece that makes multi-agent runs actually work across a long session.
• Tests are the entire safety net. The creator admits they sometimes only read the tests, not the code. That only holds up because the prompt explicitly requires tests alongside every implementation. Cut the testing requirement and you lose the ability to trust the output.

One commenter in the thread put it bluntly: “the abstractions only leak after release.” It’s a fair point. This setup puts a lot of trust in test coverage. If your tests are shallow, the system’s confidence is misplaced.

Worth exploring further

The obra superpowers library is publicly available on GitHub, and the ClickUp CLI built with this prompt is open source too. If you want the full picture, including how AGENTS.md handles the end-to-end release cycle, the original thread in r/PromptEngineering is the place to start.

One prompt that builds, tests, and releases full CLI features – here’s the setup behind it
by u/krodak in PromptEngineering