菜单
Use before implementing a non-trivial, multi-file or cross-app feature — write a short spec that names the real repo touchpoints first, then implement against it. Replaces ad-hoc guessing with a plan-first flow. Invoke as /write-spec <feature>.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Playbook for adding or changing API behavior in apps/server (NestJS + Fastify). Use when implementing endpoints, services, repositories, DTOs, guards, or gateways. Enforces controller→service→repository layering, the shared response/error envelope, DTO validation, and the separate user/admin auth systems.
Playbook for UI work in apps/web and apps/admin (Next.js App Router + next-intl). Use when adding pages, components, hooks, forms, or data fetching. Enforces Server Components by default, TanStack Query, react-hook-form + Zod, the typed API clients, @open-meet/ui primitives, and locale-aware routing.
Use whenever adding or changing user-facing UI or API copy. open-meet ships 15 locales; this skill keeps every locale in lockstep and registers new namespaces so useTranslations doesn't throw at runtime.
Use for database/schema work in apps/server — adding models, fields, relations, indexes, or migrations. The Prisma schema is split into multiple files by domain; this skill keeps edits and migrations in the right place.
Use when changing websocket / Socket.IO behavior — events, payloads, or gateways. open-meet has two namespaces (/meeting and /chat); this skill keeps the shared socket contract and both ends in sync.
Orientation map for the open-meet monorepo. Use at the start of a task to find which app, module, and shared package own a feature (auth, meetings, meeting-scoped chat, persistent team chat, recording, RBAC, branding, uploads) before editing. Answers "where does this change go?".
| name | write-spec |
| description | Use before implementing a non-trivial, multi-file or cross-app feature — write a short spec that names the real repo touchpoints first, then implement against it. Replaces ad-hoc guessing with a plan-first flow. Invoke as /write-spec <feature>. |
For multi-file or cross-app features, produce a spec before coding. Skip this for one-file diffs.
Reference actual apps/modules/packages/routes/DTOs/tests from this repo (use the repo-map skill); if a section is unknown, write "Not detected yet" rather than guess. If requirements are ambiguous, interview the user with AskUserQuestion before writing the spec.
Then: implement against the spec, validate (see validate-changes), and finish with the end-to-end verification step. Save the spec where the user wants it (default: paste it inline for approval, or write it next to the work as <feature>.spec.md).
Goal — the problem being solved + the user-visible outcome.
Scope — what's in scope / explicitly out of scope; existing rules that must stay true.
Touchpoints (real repo paths) — owning apps/modules; shared DTOs / socket contracts; which app(s) change (apps/web, apps/admin, apps/server).
Database — Prisma schema changes / migrations, or "No database changes" (see prisma-schema).
API — new/changed endpoints, DTOs, auth/guard/RBAC implications, socket/LiveKit contract changes (see backend-feature, realtime-contracts).
Frontend — routes, components, hooks, stores, queries; i18n copy (see frontend-feature, i18n-copy).
Validation & permissions — backend DTO + frontend Zod limits; upload constraints; who can use it (RBAC / guest / host).
Edge cases — empty / failure / race / realtime / backward-compatibility concerns.
Verification checklist
