Busabase Template Creator

busabase-app-creator already answers is this a valid template — the package format, the
contract, the runtime, the security boundary. It says so itself: "the contract here is **format and
correctness, not taste." This skill answers the question it deliberately leaves open: is this
good enough to put in a public catalog with our name on it.**

Everything below is additive. Never restate, re-derive, or contradict a rule that
busabase-app-creator owns; call it instead.

Which skill am I in?

These names look interchangeable and are not. Read this before deciding where a change belongs.

| Skill | Owns | Answers |
| --- | --- | --- |
| busabase-app-creator | AirApp modeling, package/template format, contract, security, runtime, deployment, maintenance. The single technical source of truth. | Is it correct? Will it install? |
| busabase-template-creator (this) | Cover, screenshot coverage, brand hygiene, demo-data quality, publishing gate for busabase/templates. | Is it good enough to publish? |
| kelly-app-skill-creator | The same layer as this skill, for a different catalog (mr-kelly/skills) with its own taste. | Is it good enough for that catalog? |

Two traps worth naming, because both have cost real time:

• "App vs template" is not the split. busabase-app-creator authors templates too — its

package-first route and references/template-format.md are exactly that. The split is
correctness vs publishability, not app vs template.

• **busabase-package-creator, busabase-skill-creator, and busabase-app-package-creator are

symlinks to busabase-app-creator**, not separate skills. If four names feel like the same
thing, that is because four of them literally are.

To change a format or correctness rule, edit the busabase-app-creator skill itself. Do not
fork its rules into this file.

The publishing bar

A template ships when all of these hold. Each is checkable; none is a matter of opinion.

1. It passes the format gate

npx busabase-cli check ./<name>

Zero errors. Warnings are allowed only when the reason is written down in the PR — the format
reference is explicit that warnings are "documented defaults worth defending in review."

This is a precondition, not the finish line. busabase-app-creator explains why a green validator
does not prove a working install; this skill does not repeat that argument, it inherits it.

2. It has a generated cover, and the cover is first

assets/screenshots/cover.webp, 1440×900, pinned at template.screenshots[0]. Generate it — never
hand-compose it:

python3 <templates-repo>/skills/busabase-template-cover/scripts/generate_cover.py <template-dir>
python3 <templates-repo>/skills/busabase-template-cover/scripts/generate_cover.py --check <template-dir>

The renderer owns the layout and enforces its own safe areas; that skill's SKILL.md is the
contract. Two ordering rules that are not obvious and have both bitten:

• Generate the cover after capturing screenshots, never before. The cover is rendered from a

real screenshot, so a cover made from a stale screenshot is stale.

• A screenshot-capture pass must skip cover.webp. Capture tools that enumerate

assets/screenshots/* treat the cover as a route (#/cover), silently overwriting a designed
cover with a picture of whatever that route falls back to.

3. Screenshots are rich enough to sell the workflow

Not "has at least one image." A card that shows only a landing view proves nothing about the
product. Cover at least:

• the overview / landing state,
• the core working surface (the queue, the board, the list that carries the job),
• the human-attention state — what needs review, what is blocked. For a review-queue app this is

the whole point; a gallery that never shows it is advertising the wrong product.

Both locales when the app ships both. Uniform viewport across the catalog — mixing framed
(window-chrome) and unframed shots produces a frame-inside-a-frame in the cover, with the template
name printed twice.

Do not ship a "this is a mock image" disclosure baked into the app's own demo mode. Some
templates render a banner (e.g. a demo-visuals.js/.css panel gated on ?demo=1) explaining that
certain images are synthetic placeholders. It never reaches a real installed template — real users
never pass ?demo=1 — so it is dead weight from their side, and from the gallery's side it is
actively harmful: busabase-template-cover requires the screenshot's top edge to stay inside the
canvas while only the bottom may overflow, so anything pinned to the top of a demo page is
guaranteed visible in the cover. A disclosure banner nobody but a screenshot tool ever sees ends up
permanently occupying the highest-value real estate in the card, pushing the actual product below
the fold. If a template has one, remove it (client-side file + /