Templates

Templates

Edit source

Templates

Templates are pre-built Centraid apps that ship with the desktop. Each one is identical in shape to an app you'd author yourself — index.html, app.css, app.js, queries/, actions/, migrations/, app.json. You clone, you tweak, you ship.

The templates live in packages/app-templates/.

The two flavors

Plain apps

Single-purpose UIs. Cup tracker. Todos. Daily journal. These are the seed shape for "an app that you open and click a button on".

Template What it is
hydrate Track 8 cups a day. One table, one query, one action. The reference shape.
todos Capture and clear small things.
journal A clean place to write each day.

Automation-flavored

Templates with kind: "automation" in the gallery's index.json (separate from each app's own app.json — see the distinction below). These are headless automation apps: an app.json with empty actions[] / queries[], no index.html, and one or more automations under automations/<id>/. The handler (handler.js) typically gathers data via ctx.tool, calls ctx.agent to reason, and writes the result back. Designed for "the agent does the work in the background; you read the result". See the Automations tab for the full runtime.

Template Category Trigger
auto.briefing Daily rhythm Weekdays · 6:00 PM
auto.evening-wrap-up Daily rhythm Daily · 9:00 PM
auto.meeting-prep Daily rhythm (see template)
auto.email-triage Inbox (see template)
auto.issue-triage Inbox (see template)
auto.pr-review-digest Engineering (see template)
auto.release-notes-drafter Engineering (see template)
auto.flaky-test-tracker Engineering (see template)
auto.dependency-update-check Engineering (see template)
auto.system-health-check Engineering (see template)

TODO(#120) — flesh out the per-template trigger schedules. They're declared in each template's index.json entry as triggerLabel; worth pulling them all into this table.

What's inside packages/app-templates/

Code
packages/app-templates/├── README.md├── src/                      # listTemplates(), types├── index.json                # the manifest source — TemplateManifest├── manifest.json             # generated by scripts/build-manifest.mjs├── hydrate/                  # one folder per template, full app shape├── todos/├── journal/├── auto.briefing/├── auto.evening-wrap-up/└── …

Each <id>/ directory is a fully-formed app. The index.json at the top is the gallery manifest — what the desktop reads to render the template picker.

Gallery manifest entry

For a plain app:

json
{  "id": "hydrate",  "name": "Hydrate",  "desc": "Track 8 cups a day.",  "colorKey": "indigo",  "iconKey": "Water",  "version": "0.1.0"}

For an automation:

json
{  "id": "auto.briefing",  "name": "Briefing",  "desc": "A scannable catch-up …",  "version": "0.1.0",  "kind": "automation",  "emoji": "🌤",  "category": "Daily rhythm",  "triggerKind": "cron",  "triggerLabel": "Weekdays · 6:00 PM",  "integrations": ["Google Calendar", "Gmail", "Slack"]}

The kind: "automation" flag plus triggerKind / triggerLabel / integrations are what the gallery uses to render automations differently from regular apps.

This kind field is gallery-level metadata only — it lives on the template-gallery entry in packages/app-templates/index.json, not on the runtime app.json inside the template directory. The runtime doesn't read it. The desktop's gallery picker reads it to decide which tab to surface the template under (Apps vs Automations).

Pre-built handlers

Templates ship with compiled .js already in place. Cloning is "click and deploy" — no bun install, no compile step.

Pre-build the handlers: commit the compiled .js files alongside .ts so cloning is "click and deploy" — no bun install needed on first use. — packages/app-templates/README.md

This is what makes the gallery feel instant.

Where to go next

Was this useful?