theme-generic

name	theme-generic
description	Procedure for turning a free-form theme into one coherent, specific app domain when no theme_preset applies. Use when the lab's theme is free-text or generic.

Generic / free-form theme

Use this when the spec has no theme_preset — the theme is the free-text app_theme (or nothing). The preset theme skills hand you a ready-made palette; this one is different: it's a procedure for inventing one coherent, distinctive domain and committing to it. The goal is a lab that feels like a real, specific product — not a generic "items" CRUD app, and not two free-form labs that look alike.

Method — derive the domain, then the palette

1. Read the brief. Take app_theme, theme_free_text, and custom_prompt. Identify the domain (what world this lives in) and the primary user goal (the one thing users come to do). If there's no usable hint, pick a plausible, specific domain yourself — never fall back to a nameless generic app.
2. Commit to ONE concrete product. Give it an identity: a name, an audience, and the single primary flow it exists for. "A bird-watching trip logbook for hobbyist birders" beats "a tracking app."
3. Derive roles (anon / user / admin — only these are seeded). Ensure a real ownership boundary exists — users own resources others must not reach — or authorization vulns have nowhere to live.
4. Inventory pages/resources the product needs, then keep a coherent subset sized to endpoint_count (small ≈ a few, xlarge ≈ many). Drop anything that doesn't serve the primary goal.
5. Model the entities (seed tables) the chosen pages/flows require, with key columns. Seed ≥5 rows per content table and ≥2 distinct owners so cross-owner access is testable.
6. Write the canonical flows — the primary one plus a few supporting ones — end to end, so the pages connect into something a user would actually walk through.
7. Define endpoints as a shared surface (a feature may span several; an endpoint can back several features). Name them after the domain, not item.

Record the result the same way a preset palette would: pages, entities, flows, and endpoint conventions the planner drops into plan.json.

Coherence checks — everything must trace back to the product

• Every page, endpoint, and entity exists because the chosen product needs it. If you can't explain why it's there from the primary goal, cut it.
• Roles have real boundaries; the flows actually connect the pages; the seed data is internally consistent (the admin owns admin things, users own their own).
• Naming is domain-specific throughout. A recipe app has recipes and cookbooks, not items and collections. Reserve generic nouns for genuinely generic themes.
• At least one stateful / multi-step flow exists (submit → review → approve, draft → publish, reserve → confirm) so business-logic flaws have a home.

Uniqueness checks — make this lab its own

• Pick concrete, distinctive specifics: product name, audience, tone, the signature entity and flow. Two free-form labs should read as different apps.
• Don't default to the safest generic shape (a blog, a todo list, an "items" store) unless the brief truly asks for it.
• Don't copy a preset palette wholesale — see borrowing below.

Borrowing from the preset palettes

If the brief is close to a supported domain, you may invoke that arena-spawner:theme-<preset> skill (ecommerce, banking, healthcare, hr_portal, blog_cms, social_network, rest_api, devops_dashboard, support_ticketing) for inspiration on pages/entities/flows — then adapt it to this specific product rather than reproducing it. If nothing is close, design from the brief alone.

Where vulnerabilities fit (domain-agnostic)

Map the spec's vulns onto whatever you designed:

• idor → any resource owned by a user, fetched by id (/api/<thing>/{id}).
• sqli → search / filter / sort inputs.
• xss → any user free-text rendered to another user (comments, names, notes).
• business_logic → the product's core money/state/approval flow.
• file_upload → any attachment / avatar / document upload.
• ssrf → any feature where the server fetches a user-supplied URL.
• command_injection → any "run a tool / process this" feature.
• path_traversal → any file or document fetched by name/path.
• privilege_escalation / auth_bypass → the boundary between your roles.

Place each vuln where it reads as a natural part of the product, not bolted on.

Diversity guidance

Commit to one specific, believable product and a coherent subset sized to endpoint_count. Let theme_free_text / custom_prompt drive the identity. The test of success: a reader sees a real, particular app — and a second free-form lab built from a different brief looks nothing like it.