App Creation

App Creation

Takes the agent from "I want to build app X" to "a permanent git-versioned working tree exists at $REPO and the daemon is reading from it." Once that's true, hand control to AUTHORING.md for the edit → commit → install loop.

First: is this an app, or a workflow?

Most "build me something that does X" requests are workflows, not apps. Apply this litmus before scaffolding:

A workflow takes inputs, runs a sequence (transform, call actions, use system:summon for an LLM step), and returns a result — summaries, digests, drafting/writing, triage, monitor-and-notify, multi-source synthesis, "do X when Y". This is the default — including when the user wants to run it repeatedly and review past runs (the platform persists run history for free; authors never build that).

Scaffold a full app only if at least one is true:

1. It owns a data model the user edits — records they create / update / delete and return to (tracker, CRM, library, kanban). Wanting to see past runs does not count — that's free platform history, not a custom data model.
2. It has more than one distinct operation — several verbs the user chooses between (add, browse, configure, approve…), not just "run it". A single trigger, even with inputs, is still a workflow.
3. It has a conversational or long-lived agent — something the user talks to, or that carries memory/its own tools across turns. A one-shot "generate X from Y" is a system:summon step, not an agent.

None of those → STOP and use coding:workflow_creation instead. Two smells that you've mis-split a pipeline into an app: reaching for a db: section to store past outputs, or standing up a custom agent for a one-shot generation. A workflow is a verb (do this, give me the result); an app is a noun (a place that holds my stuff).

If — and only if — the litmus says app, continue.

Invariants this skill enforces

1. Every app has a permanent, version-controlled source home. The agent picks an absolute path up front, scaffolds the template into it, then runs git init and commits — so the bundled template lands as the first commit inside a tracked tree. There is no throwaway "session" — $REPO is where the app lives forever, and the agent can audit its own work through git log / git diff.
2. spec.source points at $REPO itself with mode: "source" — the daemon owns build + pack + install as one install. It runs the workspace's pnpm install + pnpm build, packs into $REPO/.rome/artifact (daemon-managed; never edit or commit it), and installs the packed artifact. Every install call must pass source explicitly — the daemon does not infer it from the lockfile. Subsequent installs pass the same { mode: "source", path: "<absolute $REPO>" }.
3. Every generated app uses format version 2 canonical artifact ids. Definitions keep only an app-local name (review, run, researcher); every reference or runtime call uses <app-id>:<local-name>, including same-app references. Never emit a bare artifact reference or self:<name>. Platform examples must use their real owners: system:summon, system:create_routine, system:send_message, connector:connector_proxy, core:main, and assistant:assistant. The full fixed-id table is in REFERENCE.md.

The scaffold flow

# 1. Pick an absolute path for the app's repo UNDER the "Custom app authoring
#    directory" given in your Runtime Context (`~/.rome/<profile>/projects/apps`)
#    — i.e. <authoring-dir>/<appId>. This tree is both the canonical authoring
#    root and the runtime source of truth, and it sits under the projects root
#    so the app shows up in the dashboard. Do NOT use `$HOME/projects` — that is
#    off the projects tree and the app would be invisible. <appId> must match
#    /^[a-z][a-z0-9-]*$/ — short, lowercase, hyphenated.
REPO="${ROME_APP_AUTHORING_ROOT:-$HOME/.rome/${ROME_PROFILE:-default}/projects/apps}/<appId>"
mkdir -p "$REPO" && cd "$REPO"