Skip to main content
You can ship an OpenHome Ability (and a companion dashboard) in an afternoon if you brief the LLM well. This page collects the prompts, patterns, and guardrails that make the difference between a plausible demo and something you actually leave running. Two surfaces covered: Both share the same Live Editor patterns and guardrails.

The rule of two tabs

When building, keep two browser tabs open side by side. You need to see both sides of the pipe at once.
  • Tab 1: OpenHome Live Editor → Ability logs
  • Tab 2: Your terminal (Claude + CLI) or Replit (server logs)
If a POST fails, you see it in both within a second. Fastest feedback loop voice AI has ever had.

Vibe coding Abilities with Claude

The OpenHome CLI was designed so an AI coding agent — Claude, Cursor, anything that supports tool use — can drive the build loop end-to-end.

Setup

1

Install the CLI

Paste your OpenHome API key when prompted.
2

Point Claude at the project

In your terminal, launch Claude Code (or your preferred agent) in the directory where your Ability lives. Claude has full tool-use access to the CLI.
3

Give Claude context

Share the SDK Reference and Simple Abilities Cookbook up front. These two documents are the entire operating context for Ability development.

The context you must give Claude

Before asking Claude to write any Ability code, paste or reference these four things:
  1. SDK Reference — every method, every sandbox rule, every prompt pattern
  2. Simple Abilities Cookbook — the 100+ examples so Claude understands the Ability shape
  3. Voice-First Best Practices — the UX rules that distinguish a demo from a product
  4. What you want to build — one paragraph, plain English, with concrete triggers and behaviors
Without all four, Claude will generate plausible-looking but wrong code — the worst outcome.

Scaffolding prompt for a new Ability

Copy and adapt:

Two-shot development

The worst failure of AI-assisted coding is generating a plausible implementation of the wrong design. Two-shot it:
1

Shot 1 — architecture in prose

Before any code: “Walk me through the architecture. What files, what loops, what prompts, what storage patterns? Flag any tradeoffs.”
2

Shot 2 — full code

Only after you’ve agreed on the shape: “Now write the full implementation. Follow every sandbox rule.”
Talking through the shape before typing is the single highest-leverage habit in Ability development.

Sandbox rules to pre-brief

Claude doesn’t know OpenHome’s sandbox until you tell it. The ones it gets wrong most often:
  • No asyncio.create_task — use self.worker.session_tasks.create()
  • No asyncio.sleep — use self.worker.session_tasks.sleep()
  • No print() — use self.worker.editor_logging_handler.info() / .error()
  • No raw open() — use the file storage API (write_file, read_file, check_if_file_exists)
  • No top-level import os, import signal, import json outside the register block
  • #{{register capability}} is a literal comment tag, not a function call
  • Every main.py exit path must call resume_normal_flow() — even exception handlers and timeouts
Pre-brief Claude on these once, and it’ll stop making the same mistakes.

Log-driven iteration

When something breaks, paste the live Live Editor logs directly into Claude and ask it to diagnose.
  • Don’t summarize
  • Don’t filter
  • Don’t try to identify the problem yourself first
The logs are the ground truth. Let the model see them raw.

Deploy and test in a loop

The CLI’s superpower is that Claude can build → deploy → test without you clicking anything:
This is the productivity unlock. See OpenHome CLI for the full command surface.

Vibe coding dashboards with the Replit Agent

Replit’s Agent is good, but only as good as the brief you give it. Be explicit about three things: what is POSTing in, what the frontend will poll, and that state lives in memory.

Master prompt for the backend

Copy this, adapt the <ability> placeholder, paste it into the Replit Agent:

Frontend-specific prompt

Run this as a second prompt after the backend is working. Mixing backend and frontend in one prompt produces muddled output.
See Build a Companion Dashboard for the full architecture this dashboard is serving.

OpenHome Live Editor patterns

The Live Editor is where most of your Ability development happens. A few patterns will save you hours.

Prompts at the top of the file

Every configurable LLM prompt, every URL, every constant belongs at the top of main.py as a named constant. When you want to fork an Ability for a new persona, you change the constants — not the logic. This rule is absolute.

Use the register-capability tag, not a function call

Inside your MatchingCapability class, use the literal comment tag #{{register capability}} — not register_capability(). The platform rewrites the tag at load time. Writing the function call manually throws sandbox errors.

Log generously in dev, sparely in production

During development, log every cycle, every POST, every API response. editor_logging_handler is your only window into the Ability’s behavior. Before shipping to the Marketplace, trim log lines to the bare minimum — one line per cycle, plus errors. A silent Ability in production is a good Ability.

Shared patterns and guardrails

These apply whether you’re vibe coding the Ability or the dashboard.

Forbidden imports and patterns

Full list: SDK Reference → Sandbox rules.

The session_tasks pattern

All background work — heartbeats, parallel LLM calls, dashboard POSTs — goes through self.worker.session_tasks.create(coro). This guarantees clean shutdown when the session ends.

The two feedback loops

Use whichever surface is live for the layer you’re debugging. Don’t try to guess.

Never send raw audio to a dashboard

Keep audio local to the Ability. Send transcripts, summaries, tone descriptors, metadata — never PCM or WAV bytes.
  • 1 minute of 16kHz 16-bit audio = 2 megabytes
  • 1 minute of transcript = 2 kilobytes

See also