add-screenlisted

Add a presentation-only slice — Screen + ViewModel + tests + golden tree + spec + nav route — for an EXISTING entity/repository in this Compose Multiplatform app, cloned deterministically from the `home` exemplar's presentation layer. Requires the entity's data layer (model, repository, use case, fake) to already exist. Use this when the user wants to "add a screen", "add a screen for an existing entity", "add a screen backed by a repository I already have", "put a UI on this data", or names an existing domain noun they want a screen for (e.g. "add a screen for Tag", "I need a Bookmarks screen — the repository's already there"). Works with NO create-cmp plugin installed — the stamper (`qa/scaffold-feature.mjs --preset screen`) and this skill both ship inside the generated project.
kvdm-co-pilot/create-cmp-showcase · ★ 0 · AI & Automation · score 60

Install: claude install-skill kvdm-co-pilot/create-cmp-showcase

# add-screen — stamp a presentation slice over an existing entity > Deterministic-stamp, gate-proven. The script (`qa/scaffold-feature.mjs --preset screen`) does > the mechanical work — copy the `home` exemplar's presentation files, whole-word identifier > rename, DI injection for the ViewModel only, nav route + import. You (the AI) only refine spec > wording and adapt the screen to the entity's real shape. You are not done until > `node qa/verify.mjs` PASSes and the receipt is committed — see this project's `CLAUDE.md`. This is the `screen` subset of `add-feature` — same stamper, same rename mechanic, filtered to the 6 presentation+tests+spec files, **composed on top of an entity that already exists** (via `add-repository` or a prior `add-feature` run). If the entity doesn't exist yet, this will refuse to stamp anything — see step 2. ## Why a stamper and not hand-written files Every hand-written file is a drift chance in this project's architecture. `qa/scaffold-feature.mjs --preset screen` produces a **conforming skeleton by construction**: a Screen composable with a testTagged root, a ViewModel (+ test), a Compose UI test, a golden-tree test, and a seven-clause spec — wired into Koin and the nav graph. Your job is to make it *behave* like the real screen, not to make it *structurally correct*. ## The flow ### 1. Name the feature and confirm the entity Ask the human for the feature/screen name (PascalCase, plural-ish noun — e.g. `Tags`, `Bookmarks`) and the entity it