typescript
Use when a developer needs to understand or extend the Rust-to-TypeScript type generation in this project. Typical phrasings: "how do TS types get generated?", "add a field and get it in TypeScript", "why isn't my DTO showing up in the frontend types?", "what TypeScript does Forge auto-generate?", "how do I reference an enum from TypeScript?", "add a #[ts(...)] override for field X", "regenerate types after adding a DTO". Covers the full pipeline: ts_rs annotations on Rust DTOs, forge::AppEnum auto-generation for shared enums, the `make types` command, and the `@shared/types/generated` frontend import surface. Do NOT use for: changing frontend TypeScript that consumes generated types (regular frontend work); writing a brand-new DTO as part of a larger feature (use the feature's own skill — e.g., `admin-datatable`); tsconfig.json or Biome configuration; or frontend build/Vite errors unrelated to generation.
Repository SourceNeeds Review
admin-badge
Use when adding a new admin-portal sidebar badge — a pending-item count indicator such as "pending topups", "pending KYC", "unreviewed withdrawals", or any "show count on admin menu" request. Covers the full cross-layer flow: backend AdminBadge trait file + BadgeServiceProvider registration + frontend MenuItem wiring. Do NOT use for Forge user notifications (outbound messages delivered to users), dashboard metrics / charts, or generic global-state counters unrelated to admin work queues.
Repository SourceNeeds Review
admin-datatable
Use when adding a new admin-portal listing / CRUD page backed by a datatable. Typical phrasings: "add a users page", "add admin for top-ups with filters and search", "create a CRUD page for withdrawals", "list page with export and create modal for X". Covers the full cross-layer flow — backend Datatable trait + registration + CRUD routes + request/response DTOs + service functions + frontend list page + form modal + delete modal + router + menu + i18n. Do NOT use for: single-record detail pages (separate skill), wizard-style multi-step forms, user-portal listing pages (admin-portal only for v1), or public-facing datatables.
Repository SourceNeeds Review
admin-page
Use when adding an admin-portal page that is NOT a CRUD list backed by a datatable. Typical phrasings: "add an admin dashboard", "admin detail page for X", "settings page", "admin report / analytics page", "admin workflow step", "admin-only viewer for logs / audit". Covers the full flow — optional backend route + DTO + service (for pages that fetch data), frontend page component, router entry, sidebar menu entry, i18n, permission gating. Routes CRUD/list requests to `admin-datatable` and auth/login requests to `new-portal`. Do NOT use for: list/CRUD pages (→ `admin-datatable`); login / auth UI (→ `new-portal`, which scaffolds these); user-portal pages (adapt by analogy — no user-page skill yet); dashboards on the frontend without any backend data (regular component work, no skill needed).
Repository SourceNeeds Review