How We Built an Agent CLI for Onchain Mini Apps

Our crypto team at Lazer has been deep in mini apps for a while now, both as active builders and across client engagements. We’ve been supporting Coinbase on Base App for over a year, helping build the platform where mini apps, trading, chat, and discovery come together onchain. We helped Titles launch the top AI mini app on World App and Base last year, and we are actively building Dinari‘s RWA trading app, including its mini app on Base and World.

We believe in the future of onchain experiences and want to make it as easy as possible for anyone looking to bring their ideas to life. That’s why we built this mini app agent harness.

The Lazer Mini App CLI ships with a context layer that covers the foundational skills required to build onchain apps and publish them to Base and Farcaster app ecosystems. Specifically:

• /auth — social login and wallet auth with Privy support

• /web3 — EVM reads, writes, and wallet flows

• /contracts — Foundry smart contracts

• /codex — Realtime onchain data using Codex’s API

• /postgres — Postgres with migrations

• /ds — Design system and tokens

• /base — Base platform adapter and sharing

• /farcaster — Farcaster SDK, actions, and notifications

These aren’t wrappers or feature flags. Each skill reads version-matched source references that ship inside the generated app, checks the current state of your repo, and writes the smallest implementation that satisfies what you asked for. For example:

Each command builds on whatever already exists. You don’t start with the whole stack and delete. You start clean and grow into it.

We wanted to build mini apps the way we think about them: start with an idea, describe the intent, and get something live fast enough to learn from real users.

An agent-first approach makes that possible. Instead of manually wiring auth, wallets, platform adapters, contracts, and data layers for each new app, we built a harness where the agent already knows how to do that work. The focus shifts from how to build it to what you want to build and how quickly you can test it.

Most scaffolding templates and starter repos try to solve this differently. They front-load everything. You answer a few prompts and get a project with auth, wallets, providers, routes, contract tooling, and a pile of dependencies already wired in. It feels productive for about five minutes. Then you start deleting the half you didn’t want.

npm packages make a different tradeoff: they hide complexity behind APIs, but your app logic ends up split between your repo and node_modules, and customization means learning someone else’s abstraction instead of owning the code.

We wanted a different model. The generated app ships two layers of code:

1. Runnable app code for the developer: a small Next.js app that compiles and runs immediately.

2. Reference source code for the agent: read-only module source copied into .claude/skills/*/references/, version-matched to the generated app.

The app starts small. The implementation stays local and editable. The agent isn’t browsing stale docs or guessing at package versions. It’s reading the exact module source that shipped with your project. That reduces drift and makes the output much easier to trust.

A group of opinionated agent skills paired with product CLIs may be where templates and developer starter kits are headed, and this pattern extends well beyond mini apps.

Simply run Lazer Mini App CLI and equip your agent with the skills it needs to bring your idea to life.

At any time from your agent terminal session (e.g Claude) you can run /lazer with a question or a defined feature prompt.

Learn more: miniapps.lazer.tools

We want to see what you build. Tag us on X and Farcaster!

Contributors: @sudojbird, @0x_reed, @james_mccomish, @freyja__3991, @iykAzorji

🌐lazertechnologies.com 𝕏@lazer_hq 🔗LinkedIn 📬 founders@lazertechnologies.com