uzh-bf

Change the KlickerUZH Prisma schema, write migrations, or update seed data. Use when editing packages/prisma schema files, adding models/fields/enums, creating typed Json fields, syncing the analytics Python schema, or when a schema change must reach GraphQL types and e2e fixtures.

Choose the right test level and verify changes before a KlickerUZH PR. Use when deciding what to test, running tests locally, interpreting test failures, or assembling pre-PR verification evidence (typecheck, build, targeted tests, browser screenshots) for any change in this repository.

Work with devrouter for local dev routing (HTTP + TCP/Postgres + dependency-only Docker services)

Diagnose and repair a broken KlickerUZH development environment. Use on a fresh clone/worktree, when pnpm install/build/check or git hooks fail, when Docker infra or ports misbehave, when codegen artifacts are stale, when Hatchet-dependent features do nothing, or when the database needs (re)seeding. Every other klicker skill routes here on environment failure.

Keep the KlickerUZH engineering wiki (docs/) and custom skills (.agents/skills/) accurate and up to date. Use when a change alters behavior or documented behavior, when you discover a non-obvious pattern worth recording, when adding/renaming/removing wiki pages or skills, or when documentation/skills and code disagree.

Use when writing, reviewing, or executing batch database scripts (seeds, updates, cleanups) to enforce the Safe Mutation Protocol, dry runs, PII refusal, and double-dump validation.

Build or change UI in the KlickerUZH pages-router frontends (frontend-manage, frontend-pwa, frontend-control, auth). Use for new pages/components, styling, forms, i18n strings, wiring generated GraphQL documents, and the mandatory browser verification of any visible change. NOT for apps/chat (app-router island — see docs/chat-platform.md).

Maintain and debug the LEGACY Cypress E2E suite for KlickerUZH (frozen pending removal — write NEW specs with klicker-playwright-e2e instead), including GitHub Actions debugging via gh.

Work with devrouter for local dev routing (HTTP + TCP/Postgres + dependency-only Docker services)

Build the frontend of a GBL platform game - player cockpit with status-switch pattern, admin pages, realtime wiring, and which components to reuse from @gbl-uzh/ui and @uzh-bf/design-system. Use when creating or changing game pages/components in apps/<game>/src.

Scaffold a new GBL platform game app inside this monorepo by copying apps/demo-game - file-by-file copy/rename checklist, prisma setup, local dev environment, and first-run verification. Use when starting a brand-new game.

Keep the GBL platform wiki (docs/) accurate and conformant with the Open Knowledge Format - the repo-specific extension of generic OKF/LLM-wiki practice - when to update it, how to fact-check against code, house conventions, and validation. Use whenever a change touches packages/platform, packages/ui, apps/demo-game behavior, or when doc-code drift is noticed.

Implement the backend of a GBL platform game - the six-module Services contract (Actions, Period, PeriodResult, Segment, SegmentResult, GameFacts), facts types with yup schemas, and seed data. Use when writing or changing game logic in apps/<game>/src/services.

Design a learning game for the GBL platform - check platform fit, map a game idea onto periods/segments/decisions/facts, and produce a build-ready game design. Use BEFORE writing any code for a new game.

Create, run, debug, review, and extend Playwright E2E tests for GBL games (the demo-game suite and specs adapted for new game apps). Use when working in playwright/tests, Playwright config/CI, local devrouter/devcontainer browser validation, multi-player game flows, OIDC mock auth, report/dice/countdown assertions, flaky Playwright failures, or GBL Cypress-to-Playwright coverage planning.

Deploy a GBL game to a shareable staging URL with Vercel + Neon Postgres, driven from the CLI (neonctl + vercel). Use when a game builds and runs locally and needs a public URL for review - the easy alternative to the k8s deploy/ path.

Turn an idea YOU have already chosen into something tangible enough to test with other people. Use in the prototyping phase to produce a storyboard, a worked example, landing-page copy, or a low-fidelity wireflow. This renders a decision you have made - it is execution, not ideation. Triggers on "prototype", "make it tangible", "storyboard", "mock this up", "what would this look like", "wireframe".

Spark cross-domain ideas by handing you distant analogies to think from - you do the mapping and the ideas yourself. Use during ideation to escape obvious in-domain answers, when ideas feel generic, or to find cross-industry inspiration. This is the core "Praxistransfer" move. Triggers on "ideas", "we're stuck", "transfer", "analogy", "think differently", "cross-industry".

Widen a set of ideas that has collapsed toward the same safe answer - by showing you the rut and the exits so you climb out yourself. Use when a brainstorm feels repetitive, when every option is a variation on one theme, or to open up the space. Triggers on "these are too similar", "more options", "diverge", "wilder", "what else", "we're in a rut", "SCAMPER", "worst idea".

Turn REAL user evidence into insight - prepare research, synthesise notes you bring, and capture what testers actually said. It never invents users, quotes, personas, or needs. Use to draft an interview or observation guide, to turn raw interview/field notes into an empathy map or journey map, or to synthesise real user-test sessions into learnings and a next iteration. Triggers on "empathy map", "interview guide", "user research", "journey map", "synthesise interviews", "what did we learn", "test session", "user testing".

Plan and run a design-thinking workshop or sprint - a tailored agenda, the exercises for each phase, and a facilitator's run-of-show. It designs the session; the people in the room do the thinking. Use to prepare a creative session, a half-day workshop, or a one-day design sprint. Triggers on "workshop", "facilitate", "design sprint", "run a session", "agenda", "plan a creative session", "crazy 8s", "ideation session".

Sharpen a vague or broad problem into a well-framed challenge by drawing the framing out of you, not handing it to you. Use at the start of a design-thinking cycle, when reframing a problem, or whenever a problem statement feels too broad, solution-shaped, or stuck at the symptom level. Triggers on "frame this", "is this the right problem", "reframe", "help me define the problem", "5 whys", "point of view", "POV", "how might we", "HMW".

Pressure-test an idea or solution you have already chosen, before you commit to it. Use in the review or testing phase, before presenting an idea, or whenever a solution feels too comfortable. This is the one place AI should bring its own judgement hard - it is reviewing your work, not generating it. Triggers on "stress-test", "poke holes", "review this", "what's wrong with this", "grill my idea", "challenge this idea", "is this idea any good".

Apply the University of Zurich (UZH) corporate design guidelines to any visual output — web pages, artifacts, presentations, documents, dashboards, diagrams, posters, or UI components. Use this skill whenever the user asks to create something that should follow the UZH brand, mentions "UZH design", "corporate design", "UZH colors", "UZH style", "UZH branding", or requests any visual output in a UZH context. Also trigger when creating artifacts, prototypes, HTML pages, slides, or any visual deliverable for UZH or the Department of Finance (UZH BF/DF). Even if the user just says "make it look like UZH" or "use our colors", this skill applies. Trigger on any mention of UZH in combination with visual, design, styling, layout, or presentation work.