The AI prompt
This is the block you paste into your AI chat before you describe your app. It
teaches the assistant GDN's rules — the panel size, that fonts are uppercase-only,
how http.get works — so it writes real GDN code instead of guessing from another
platform. It ends with the short form of the design guidelines, so
the AI asks for your layout before it writes code and lays the app out the way a
good Glance app is laid out.
Use it once at the start of a chat. After it, describe your app in a sentence or two, and the AI has the context it needs.
If you've connected the toolkit over MCP, the server sends these rules for you — there's nothing to paste. This page is the fallback for assistants that can't connect.
You are writing an app for the Glance Developer Network (GDN): an app that renders
to a Glance LED panel. The panel is always 32 pixels tall. Each panel module is
64 pixels wide and panels daisy-chain up to 384 pixels wide; for best performance keep
images to 192x32 or smaller and split content across multiple pages. An app is a FOLDER
with two files:
manifest.yaml - settings: id, name, width, height, refresh (seconds),
pages: [list of screen names], and inputs (the user's form).
app.star - Starlark (Python-like) code. Define ONE function per page:
def <page>(c, ctx): ... It DRAWS a picture; it never returns
anything. c = the canvas, ctx.inputs = the user's values,
ctx.now = the current time (UTC).
Coordinates: (0,0) is top-left, x grows right, y grows down. For text and images,
(x, y) is the TOP-LEFT corner. Circles/dots center on their coordinates.
Drawing (c.*):
fill(color) / clear() ; pixel(x,y,color) ; rect(x0,y0,x1,y1,fill=,outline=)
line(x0,y0,x1,y1,color) ; text(s,x,y,font="5x7",color="white",align="left")
text_stroke(s,x,y,font,color,stroke="black",thickness=1,align) - outlined text
text_width(s,font) ; image("file.png",x,y,w=,h=) ; bitmap([[0,1,...],...],x,y,color)
Helpers (composites, prefer these): circle, fill_circle, round_rect, hline, vline,
gradient_rect, text_center, text_right, text_wrapped, text_fit,
progress_bar, sparkline, bars, badge, trend_arrow, icon("sun"), sprite,
header, kv, stat, gauge, status_dot, table, scoreboard, grid, color.dim.
Colors: names ("green","amber","red","white",...) or hex ("#00FF00").
Fonts: "4x5","5x7","6x8","7x12","10x16","16x24", etc. The "10x15_outline" and
"10x16_outline" faces carry their own border, for a hero on a filled background.
HARD RULES:
- Fonts are UPPERCASE ONLY. Call .upper() on any text, or nothing draws.
- Frames are STILL IMAGES. Don't animate or scroll; the panel re-renders on the
manifest's `refresh` timer, so let the next refresh show new data.
- Draw immediately with c.*; there is no widget tree and you never return anything.
- Lay things out by hand; the panel is only 32px tall, so keep text short.
- To fetch live data, call http.get(url, headers={}, params={}, ttl_seconds=300).
It returns a DICT you read with SUBSCRIPTS: resp["status_code"], resp["json"],
resp["body"]. NOT resp.status_code — Starlark dicts have no attribute access, so
the dotted form errors. ALWAYS check resp["status_code"] == 200 before resp["json"].
- Read inputs with ctx.inputs.get("key", fallback). Declare each input in the
manifest with app_input_type: free-text|api-key|dropdown|checkbox|date|date-past|color|selection.
- API keys MUST use app_input_type: api-key, never free-text. Only api-key inputs
are stored encrypted; a key given as free text may not work. The input name of
an api-key MUST NOT contain _ or - (use "apikey", never "api_key" or "api-key");
validation rejects api-key input names containing them.
DESIGN (the full guidelines are at https://glance-led.dev/docs/design - read them
if you can; these are the essentials):
- BEFORE writing any code, ask me how the app should look: my layout (a sketch or
a zone-by-zone description), the hero, any pixel art, the palette, and the
width. Mock up MY layout with placeholder content first; wire up the data only
after I approve the look. These rules are defaults I can override, and the app
should end up materially different from other GDN apps - not a template.
- One hero per page, sized to read from 10-30 feet; everything else smaller.
- 64x32: use every pixel. Wider than 64 (SCROLL): keep content inside x 10-181 on
a 192-wide app, with 6-10 px of padding at the app's outer edges - other apps
play right before and after mine, so never run content to pixel 0 or 191.
- The app must identify itself: a title, a splash page, or unmistakable pixel
art. Location apps show the location on the panel.
- Design for the longest possible string, not the average. Measure with
c.text_width, pick the largest font that fits, and clip deliberately - nothing
clips for you. No overlapping text; 1 px minimum between text and anything else.
- High contrast: black or near-black background. Any text on a filled or colored
background is drawn with c.text_stroke(..., stroke="black") or an _outline font.
- No magic numbers: every value has a label or obvious pixel art; temperatures
carry degrees. Pixel art is pixel-perfect (no anti-aliasing) and never overlaps
anything at any size.
- White for live numbers, gray for labels; green = ok/up, amber = attention,
red = alarm.
- Design all four screens: live; error (two short lines - what, and what to do);
empty (a positive "ALL CLEAR", not an error); demo (labelled DEMO when a key is
missing).
- Prefer dropdown inputs over free text; every input is visibly used. Name the
app descriptively (no "LED" or "SCROLL" in the name) in a real category.
Give me BOTH files, complete. Keep text short and high-contrast.
You only need to send this at the start of a conversation. From there, keep describing changes in plain English and the AI already knows the rules. If a chat drifts and the AI starts breaking them (lowercase text, animations), paste it again to re-anchor.
The DESIGN block tells the AI to ask how you want the app to look before it writes code. Answer with a sketch, a photo of a napkin, or a few words per zone — "coin top-left, the rate huge in the middle, the currency code down the right edge." The design guidelines explain what makes a layout work on the panel.