/app-taste

name: app-taste
description: Take a first-party Civitai App Block from functional to considered — the repeatable measure→brand→restructure→animate→socialise→moderate→test→re-shoot→submit pass, applied one app at a time. Use when the user says an app's UI/theme is boring or default, asks to redesign or polish an App Block, asks to apply "the taste pass" / app-taste to an app, wants a hero image or brand skin for a block, or wants the core flow of a block simplified. Authoring store icons/covers is the sibling `listing-media` skill; screenshotting a running block is `app-capture`.
argument-hint: "[<slug> | audit | rubric]"
allowed-tools: Bash, Read, Edit, Write, Glob, Grep

app-taste — functional → considered, one app at a time

A block that works is not a block anyone wants to use. This is the pass that closes that gap, in a fixed order, so the result is comparable across apps instead of being whatever the session felt like.

🔴 **Phase 0 is not optional and not a formality.** Every failed run of this pass so far failed there: a stale clone, a pinned SDK missing the method the design needed, or a platform limit discovered *after* the UI was built around it.

🔴 Read before designing anything

`.claude/skills/app-taste/reference/platform-constraints.md` — the measured shared-storage / identity / moderation surface, with the version each method landed in. **Four separate asks have been killed outright by a constraint in that file.** Do not design against the SDK you remember; the surface moves, and the app's *pinned* version is what compiles.

The gradeable checklist, and how to grow the taste: `.claude/skills/app-taste/reference/rubric.md`

---

Phase 0 — sync and measure

🔴 **Do NOT `civitai app pull` to get a working clone.** It clones the forgejo **deploy mirror**, which carries the right slug, the right manifest version and a clean `main` — and does **not** contain the source commit the app was built from, so there is nothing to branch off and no PR target. Development is on GitHub, and the repo name is not derivable from the slug. Constraints §12 has the full trap.

SLUG=app-requests
civitai app status "$SLUG"            # per-app; see §13 — it reports the newest SUBMISSION
git -C "${APP:?set APP to your clone of the app repo}" show origin/main:block.manifest.json \
  | python3 -c 'import json,sys;print(json.load(sys.stdin)["repository"])'

Then answer all five in writing before touching a file:

1. **Is the clone current, and is it the DEV repo?** The check that settles both is `git cat-file -t <live source sha>` against the clone — a mirror fails it while every other signal looks right. Comparing the manifest `version` alone passes on the mirror and proves nothing. A stale clone silently reverts shipped work. 2. **What does the PINNED SDK actually expose?** Read the installed `.d.ts`, not the monorepo source — they diverge by several minor versions. 3. **How big is the live dataset?** A cap that never binds is not a constraint; a cap that already binds is the design. 4. **What does the current app already handle honestly?** Reuse the disclosure, don't rediscover it. 5. **Which recipe drives it?** `.claude/skills/app-capture/scripts/recipes/`

Anything phase 0 finds that the platform cannot do becomes a **fork for the operator**, not an assumption. Present it with a recommendation before building.

Phase 1 — brand

The hue and mark come from the brand system, never invented here — read the live values as `listing-media` instructs, and treat any hue table you find in prose as a snapshot.

🔴 **The wheel's ≥40° separation bar binds hue CHOICE, not inheritance** — a hue measured from the app's approved live mark is recorded in the ledger's `wheelGate` block and ships as-is. Never contort a palette to satisfy the bar; the skin must stay in sync with the icon and cover already approved on the store.

**Decide brand DEPTH explicitly and record it** (`taste.json` → `brandDepth`):

| depth | surfaces | who owns light/dark | |---|---|---| | `accent` | host `--civitai-*` tokens | the platform | | `skin` | app-owned palette | **you** |

🔴 **`skin` transfers light/dark correctness to you, and that debt is invisible until someone opens the other theme.** Under `skin` the rubric's dual-theme check is mandatory, not advisory: every surface, border and text pair must be asserted in both themes, because the host token that used to flip for you no longer does.

**Hero image** — generate from the app's own mark and hue, never a stock prompt. 🔴 **`civitai generate` spends real Buzz and cannot be undone.** Always `--dry-run` first and report the estimate to the operator before spending. Record the prompt and seed in `taste.json` so the hero is reproducible; commit the rendered asset, not the intent to render one.

🔴 **`--aspect-ratio` snaps to the ecosystem's nearest ratio — generate wide-ish, then CROP.** The dry-run echoes your requested ratio back, which is not acceptance; the server picks the closest ratio that ecosystem offers, and the realized file can be nothing like what you asked for (constraints §11). Measure the output with `file` and record the real dimensions beside the seed. Generate a small batch and pick; a single render is a coin flip you will pay to re-roll anyway.

Phase 2 — information architecture

The single highest-yield phase, and the one most often skipped for styling.

• **Put the thing the app is FOR at the top.** Everything else is secondary.
• **Demote the creation CTA to secondary** once a board has content — a primary

"add" button on an empty-looking list teaches people the list is unimportant.

• **Delete copy that explains what the UI already shows.** Explainer paragraphs

are a tell that the layout failed.

• 🔴 **A filter or sort the server cannot do is a client-side lie past its

horizon.** If ranking or search only covers the rows you loaded, say so in the UI. An honest partial beats a confident wrong orde