Examples

Real prompts that produce shippable apps. Use these as templates — adapt the specifics, keep the shape.

Waitlist landing page

Use agentry to build me a waitlist landing page for "Quill —
distraction-free writing".

- Hero with the product name, a one-sentence pitch, an email input,
  and a "Get early access" button.
- The submit handler stores the email + timestamp in a JSON file
  on disk under data/signups.json.
- Below the form, show "N people in line" where N is the count of
  rows in that file.

Why this works:

• Tight scope (one page).
• "Use agentry" routes to the sandbox.
• No stack pin — the sandbox picks the right defaults for a small web app.
• Concrete data layer (JSON file, no DB setup needed for a prototype).

Internal CRM dashboard

Prereq

Bind Postgres to your server first: agentry service bind postgres. Then prompt.

Use agentry to build me a simple sales CRM. The Postgres bound to
this server should be the data layer; read DATABASE_URL from env.

Pages:
  /             — Pipeline view, columns for Lead / Demo / Won, drag-and-drop between.
  /accounts     — Table of all accounts with company, value, stage.
  /accounts/:id — Detail page with notes (markdown), edit button.

Schema (create in a schema named "crm" so we don't collide with anything
else in this database):
  accounts(id, name, value_cents, stage, created_at, updated_at)
  notes(id, account_id, body, created_at)

Seed five sample accounts.

Why this works:

• Names the data layer + the env var so the agent doesn't reach for an in-memory fake.
• Specifies the routes you want and what each does.
• Names the schema instead of letting the agent guess (and namespaces it so the bound database stays tidy).
• Includes seed data so you can see something on first load.

AI assistant over your docs

Prereq

Bind your AI provider: agentry service bind anthropic (or openai, or openrouter). Optionally bind a vector store: agentry service bind pinecone.

Use agentry to build me a chat assistant that answers questions from a
folder of markdown files I'll upload.

UI:
  /  — Sidebar lists the markdown files I've uploaded. Drag-and-drop
       upload area. Main pane is a chat: question on top, answer
       streaming below, source citations under the answer.

Backend:
  - On upload, chunk the markdown and store embeddings in Pinecone.
  - On query, retrieve top-5 chunks, send to Anthropic with the
    user's question, stream the answer back.
  - In the answer, cite the source files inline.

Why this works:

• Splits the build into UI + backend explicitly.
• Names every external service (Pinecone, Anthropic).
• Specifies the retrieval flow so the agent doesn't have to design it.

Long-running scraper

Use agentry to build me a background scraper that pulls product prices
from a list of URLs every 4 hours. No web UI needed.

- A config file lists URLs.
- Use playwright (headless) to fetch each one and extract the price.
- Store results in a SQLite file with timestamp + url + price + raw_html.
- Use project_start to run the scraper loop in the background.
- Print a one-line summary after each cycle.

Then start the scraper and let me see the first cycle's output.

Why this works:

• Background work — uses project_start (long-running) instead of command_run (sync).
• SQLite for local storage; no service binding needed.
• Asks for a visible signal (one-line summary) so you can confirm it's working.

Static portfolio with blog

Use agentry to build me a personal portfolio site. Static output.
Astro is fine here — content-heavy site, no server-side work needed.

Pages:
  /             — Hero with name, one-paragraph bio, list of three projects.
  /projects/:slug — Project case study (markdown content).
  /blog         — List of posts.
  /blog/:slug   — Post content (markdown).

Content lives in content/{projects,blog}/*.md
Each markdown file starts with frontmatter (title, date, slug, summary).

Generate three sample projects and two sample posts so I can see
the layout. Use a calm color palette — black, white, one accent.

Why this works:

• One of the rare cases where naming the stack is helpful — Astro is genuinely better than the default for a static, content-first site, so the hint is worth the override.
• Specifies content layout instead of leaving it to the agent.
• "Calm color palette + one accent" gives the agent a clear visual direction.

Refactor / debug prompt

When you already have a working sandbox and want to fix something specific:

The submit button in /workspace/projects/quill/src/app/page.tsx
calls the /api/signup route but the page never updates after a
successful submit. Network tab shows 200 OK.

Fix it.

Why this works:

• Names the file by relative path.
• Describes the symptom + observed behavior + expected behavior.

"Make it look better" prompt

The waitlist page works but looks plain. Make these changes:

- Use Inter for body, larger headings (text-5xl on the hero).
- Add a subtle radial gradient background.
- The "Get early access" button should be black on a white card,
  not the default Tailwind blue.
- Add 2px of letter-spacing to the hero headline.
- Make the email input feel premium — taller padding, soft border.

Don't change the functionality.

Why this works:

• Lists concrete style changes instead of saying "make it pretty".
• Explicitly says "don't change functionality" so the agent doesn't drift into refactoring.

"Add a feature" prompt

Add a `/admin` page to the waitlist app.

Behavior:
  - Password-protected via a single env var ADMIN_PASSWORD.
  - Shows the full list of signups (email, timestamp).
  - Has a "Download as CSV" button.
  - Has a "Send to N invites" button that posts to a /api/send-invites
    route. Stub the actual send — just write to a file
    /workspace/projects/<name>/data/sent.json.

Use the existing styling.

Why this works:

• Names the route (/admin) explicitly.
• Specifies the auth approach (single env var) so the agent doesn't reach for a full auth library.
• "Stub the actual send" prevents the agent from getting blocked on email integration.

What these have in common

Read the examples again. The shape is consistent:

1. "Use agentry to…" — opens with the trigger phrase so the harness reaches for the MCP tools.
2. What to build (in one sentence).
3. Structure (routes, pages, files — concrete enough that two agents would build the same shape).
4. Data (schema or storage approach, named env vars for any bound services).
5. Verification (a production build at the end).

Stack is conspicuously not on that list. The sandbox has an opinionated default that works for the common case — let it pick unless you genuinely need to override.

Hold to that shape and the agent does the work. Skip pieces and you'll iterate three times to get to the same place.

Next

• Patterns that work — the principles behind these examples.
• Mistakes to avoid — anti-patterns.
• Ship an app — go from working preview to production URL.