How to Get What You Want

The quality of what Claude builds is mostly determined by how clearly you describe what you want. Here's how to describe it well.

#Think like ordering food

When you order at a restaurant, you don't explain how to cook the dish. You describe what you want to eat.

"I want a cheeseburger, medium rare, with extra pickles."

You don't say: "Please take ground beef with a fat content of approximately 20%, form it into a patty, cook it to an internal temperature of 145 degrees, then place it on a brioche bun with cheddar cheese and additional pickle slices."

Vibecoding works the same way. Describe the outcome, not the implementation.

Instead of: "Write an AssemblyScript OP20 contract with a mint function that uses SafeMath for u256 arithmetic and a storage pointer at slot 1"

Try: "A token where only the owner can mint new tokens, with a maximum supply of 1 billion"

The plugin's knowledge slices already know how OPNet works. You don't need to explain it.

#The plugin already knows OPNet

This is the key insight that separates prompting on OPNet from prompting on other platforms.

The buidl-opnet-plugin loads knowledge slices into each agent before they start working. The contract dev agent already knows:

• OPNet's token standards (OP20, OP721)
• How storage pointers work
• SafeMath requirements for u256
• Bitcoin transaction construction
• CSV timelock patterns
• NativeSwap integration patterns
• Common bugs and how to avoid them

You don't need to explain any of this. You don't need to paste documentation. You don't need to say "make sure to use SafeMath."

The agents know. Focus your prompts on what you want to build, not how to build it on OPNet.

#The magic formula

Good prompts answer three questions:

What does it do? The core function of your app in one or two sentences.

Who uses it? Who are the users, what are they trying to accomplish.

What makes it yours? Anything specific about your version — restrictions, mechanics, visual style, special features.

Example:

/buidl "a staking contract where users lock their tokens for 30 days and earn 5% rewards.
Users connect their wallet, see their balance, stake any amount, and withdraw after the
lock period. The UI should look clean and dark, like a real DeFi app."

That's it. Contract mechanics, user flow, and visual direction — all in one prompt.

#Be specific about the things that matter to you

Claude will make sensible defaults for everything you don't specify. But if something matters to you, say it.

Restrictions matter: "Only one claim per wallet address" — say this if it's a core rule.

Numbers matter: "10% fee on all swaps" not "a small fee"

Flow matters: "Users must approve the token before they can stake it" — if there's a step that must exist, name it.

Anything that would make you say "wait, that's wrong" when you see it — say it upfront.

#What you don't need to explain

With the plugin loaded, you can skip all of this:

• How OPNet smart contracts work
• What OP20 tokens are
• How Bitcoin transactions get constructed
• What SafeMath is or why it's needed
• How wallet connections work on OPNet
• What the testnet vs mainnet difference is
• How to handle BTC in contracts
• Deployment process

The agents have all of this. Trust the knowledge slices.

#Prompts for iteration

After the initial build, you'll refine things. Here's how to prompt for changes:

For features: "Add a referral system where users get 10% of the rewards their referrals earn"

For design: "Make the dashboard feel more premium. Dark background, the OPNet orange as an accent, glassmorphism cards"

For bugs: "The stake button shows an error when the wallet isn't connected. Instead, it should prompt the user to connect their wallet first"

For UX: "When a transaction is pending, show a loading state on the button and disable it so users don't double-click"

Short, specific, describes the change and why.

#When to use /buidl-spec first

If your idea is complex or you're not sure exactly what you want, run /buidl-spec "idea" first. This runs just the spec phase — Claude will ask clarifying questions and write a detailed plan without actually building anything.

Review the spec. Does it match what you had in mind? Are the mechanics right? Did it include something you didn't want?

Fix the spec, then kick off the full build with /buidl.

This is especially useful for:

• Financial mechanics (staking rewards, fee distributions, AMM curves)
• Complex access control (multiple roles, time-gated permissions)
• Multi-contract systems (token + staking + governance)
• Anything where getting the spec wrong would waste hours of build time