菜单
Design a KlickerUZH feature before writing code. Use at the start of any non-trivial feature or change in this repository — to pin down domain vocabulary, affected layers, auth, i18n, gamification impact, and test level — and to write the plan file that the implementation will follow.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | klicker-feature-design |
| description | Design a KlickerUZH feature before writing code. Use at the start of any non-trivial feature or change in this repository — to pin down domain vocabulary, affected layers, auth, i18n, gamification impact, and test level — and to write the plan file that the implementation will follow. |
Spec before code. A design that answers the questions below prevents the classic rework loops (wrong entity, missing auth layer, forgotten codegen, untestable UI). Lifecycle context: docs/developing-a-feature.md.
Non-trivial work gets a plan in project/plans_wip/PLAN-<slug>.md (existing files there are the template). Keep it short: Goal, Non-goals, the answers below, slice list, Progress log. Update Progress as you work; move to project/plans/ (or per repo convention) when done.
User or Participant? Which activity type (LiveQuiz / PracticeQuiz / MicroLearning / GroupActivity)? Element or ElementInstance (source vs published snapshot)? Getting this wrong invalidates everything downstream.packages/types, GraphQL schema/service/ops (→ codegen commit), frontend app(s), i18n, Hatchet tasks? List the packages you will touch.asUser/asParticipant/…) and, for object-scoped operations, the PermissionLevel (READ/EXECUTE/WRITE/ADMIN). (docs/graphql-api-layer.md)data-cy hooks?klicker-testing-verification: what will you run, what will CI cover, what browser evidence will you capture?ff61d9bc7 read-feature, 38c92d035 schema+mutation) — mirror its shape rather than inventing structure.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.