Total Skills
10
Author Profile: weiloon1234
Skills published by weiloon1234 with real stars/downloads and source-aware metadata.
Total Stars
0
Total Downloads
0
Skills Performance
Comparison chart based on real stars and downloads signals from source data.
admin-badge
0
Stars
0
Downloads
0
admin-datatable
0
Stars
0
Downloads
0
admin-page
0
Stars
0
Downloads
0
frontend-form
0
Stars
0
Downloads
0
jobs-and-notifications
0
Stars
0
Downloads
0
new-event-listener
0
Stars
0
Downloads
0
new-permission
0
Stars
0
Downloads
0
new-store
0
Stars
0
Downloads
0
Published Skills
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
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
jobs-and-notifications
Use when dispatching asynchronous work OR delivering user-facing notifications. Typical phrasings: "add a job to do X in the background", "send an email to user after Y", "queue a CSV export job", "notify user when their order ships", "welcome email on signup", "multi-channel notification (email + in-app + push)", "retry a failing webhook delivery", "in-app notification inbox for users". Forge provides both systems — Jobs (bare async work with retry/backoff/rate-limit) and Notifications (multi-channel delivery with a recipient + `Notifiable` trait). Notifications dispatch via the Job queue under the hood but carry recipient identity and per-channel rendering. Do NOT use for: recurring scheduled tasks (→ `src/schedules/`, not yet a skill); cross-cutting side-effects on model save (→ `new-event-listener` for the trigger, which dispatches the job/notification); WebSocket channels for real-time data (→ CLAUDE.md "WebSocket" + `admin-badge` for counts); badge count updates (→ `admin-badge`).
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
new-permission
Use when adding a new variant to the `Permission` enum in `src/ids/permissions.rs` — a new RBAC scope for a feature area. Typical phrasings: "add a new permission", "new RBAC scope for topups", "permission for withdrawals / kyc / exports", "add `foo.manage` permission", "gate this feature behind a new permission". Covers the enum variant, the `module()` / `action()` / `implied_permission()` match arms, the TS regeneration, and pointers for downstream wiring. Do NOT use for applying an existing permission to a new route (just call `.permission(Permission::X)` — no skill needed), adding RBAC to a brand-new portal (that's part of `new-portal`), permission-gating a React component (regular frontend work with `usePermission`), or listing/auditing existing permissions (reference task, not a skill trigger).
Repository SourceNeeds Review
new-store
Use when adding a new frontend shared-state store — a `createStore`-backed container for state that spans multiple components / hooks / pages within a portal. Typical phrasings: "add a shopping cart store", "global notification state", "store for admin's active filters", "track unread count across components", "persistent sidebar collapsed state". Covers choosing portal-local vs shared placement, the state shape + imperative API + selector-hook pattern, and the typical lifecycle (hydrate on mount, update via imperative setters, reset on logout). Do NOT use for: form state (→ `useForm` from `@shared/hooks` — never build custom form state); component-local state that doesn't need sharing (→ `useState` / `useReducer` in-place); server state that a single fetch handles (→ direct `api.get` in `useEffect`; no store needed); auth state (→ `auth.useAuth()` from `@/auth`); locale state (→ `localeStore` / `useLocale` from `@shared/i18n`); runtime config (→ `runtimeStore` / `getConfig` from `@shared/config`).
Repository SourceNeeds Review
shared-components
Use when a developer is picking, composing, or questioning frontend primitives — the `@shared/components`, `@shared/hooks`, `@shared/modal`, `@shared/store`, `@shared/auth`, `@shared/api`, `@shared/websocket`, `@shared/config`, and `@shared/i18n` library surface. Typical phrasings: "which component should I use for X", "is there a shared button / input / select", "can I use a raw `<input>`", "how do I open a modal", "what's in @shared/components", "how do I compose a form", "add a Select with async search", "how does `useForm` wire errors". Authoritative catalog of every shared primitive + anti-raw-HTML discipline + theming rules. Do NOT use for: adding a brand-new shared primitive to `@shared/components` (rare; see `references/` when that first arises); writing frontend business logic (that's a page / feature skill); backend Rust work; understanding TS generation (`typescript` skill).
Repository SourceNeeds Review
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