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
frontend-form
Use when building a form anywhere in the frontend — inside a modal, on a full page, as a wizard step, or a settings panel. Typical phrasings: "add a form for X", "settings form", "profile form", "multi-step wizard", "form modal for create/edit Y", "confirm action dialog". Covers `useForm` wiring + `@shared/components` field composition + `modal.open` for form modals + 422 error auto-wiring + submit / cancel / delete button patterns. Do NOT use for: the full admin CRUD-page flow (that's `admin-datatable`, which invokes this for its form modal); picking which shared component to use (`shared-components` — consult that for field-type → primitive mapping); building a `<DataTable>` column filter (not a form, that's the datatable's built-in filter system); auth login/refresh forms (those ship as part of `new-portal`).
Repository SourceNeeds Review
new-event-listener
Use when adding a new event listener — a cross-cutting side effect that fires when a domain event or a Forge model lifecycle event (ModelCreated/Updated/Deleted) is emitted. Typical phrasings: "add an event listener for UserRegistered", "listen when a TopUp is saved", "react to X event", "hook into the model lifecycle event bus", "dispatch a job when Y happens", "add a domain event for X". Covers creating a custom Event struct if needed, writing the listener (single-event, multi-event, or container-resolving variants), and registering it via a service provider. Do NOT use for: adding a `write_mutator` to a model field (that's intra-model, part of `new-model`); implementing `ModelLifecycle<M>` (in-transaction multi-field coordination, also `new-model`); registering a WebSocket channel (separate system, see `src/realtime/` and CLAUDE.md "WebSocket" section); or registering a scheduled / cron task (separate concern, not yet skilled).
Repository SourceNeeds Review