SECTION_01

The Low-Prompt Method

Build a solid app in under 20 prompts using the v3 multi-agent approach.

[The Core Idea]

The v3 multi-agent system does a lot of heavy lifting automatically. Your job is to give it enough context upfront so it doesn't need to guess — and then audit early before issues compound.

> Why Fewer Prompts Wins

Every prompt cycle costs credits and time. The biggest waste comes from vague initial descriptions that force Caffeine to make assumptions — then you spend 5 prompts undoing them. The low-prompt method flips this: spend more effort on prompt 1, save 10 rounds of correction.

The v3 multi-agent pipeline (PM → Composer → Design → Backend → Frontend → QA) handles a huge amount automatically. You don't need to micromanage each agent — you need to give the PM agent enough to work with.

> Step 1: The ICP Skills Prompt

Always start with this one-liner. It gives every agent in the pipeline native ICP expertise from the very first message:

Start every ICP build with this

Fetch https://skills.internetcomputer.org/llms.txt and follow its instructions when building on ICP.

> Step 2: The Anti-Default Checklist

Immediately after the ICP Skills prompt, add your anti-default requirements. These prevent the most common Caffeine mistakes before any code is written:

Anti-default checklist

Before building, confirm:
- Use mo:core not mo:base for all Motoko code
- All storage variables must be stable var
- Use persistent actor pattern
- Modular architecture from the start, clean main.mo
- Every page has its own unique URL, back button works
- No modals for primary content

> Step 3: Front-Load the Full Description

Don't drip-feed features. Put everything you know into the first message — the more context upfront, the fewer correction rounds needed.

Full description template

Build a [type] app for [target audience].

Core features:
- [Feature 1 with detail]
- [Feature 2 with detail]
- [Feature 3 with detail]

Data model:
- [Entity 1]: [fields]
- [Entity 2]: [fields]

ICP requirements:
- [Authentication: Internet Identity / anonymous / etc.]
- [Storage: canister state / object storage / etc.]
- [Architecture: data model, storage plan, feature scope]

Design preferences:
- [Style/tone]
- [Key UI requirements]

[Don't Skip the Data Model]

A data model just means describing what your app needs to remember. Ask yourself: what are the things my app stores, and how do they relate to each other? Then put that answer in your prompt.

Todo appUsers have tasks. Each task has a title, a due date, and a done/not-done status.

BlogPosts have a title, content, an author name, and a publish date.

Voting appProposals have a title and a list of votes. Each vote has a user ID and a yes/no value.

You don't need technical terminology — just describe your things and what belongs to them. Caffeine handles the rest.

> Step 4: The Audit Routine

After the first build, always run an audit — even if everything looks fine. Use this prompt:

Audit trigger

Run a full audit of this build. Check for: broken user flows, mobile layout issues, missing error states, Internet Identity edge cases, security gaps, and anything that would frustrate a real user.

// Low-Prompt Method Checklist

Start with the ICP Skills prompt
Include the anti-default checklist
Write a full app description with data model
Think through your data model, storage plan, and feature scope upfront
Run an audit after first build
Apply audit fixes before adding new features