dev-skills

Rules and review checklist for authorization and tenant isolation — who may read or change what, in apps where data belongs to a tenant (organization, account, workspace, project, team, building). Use it whenever you add or change an endpoint, controller action, policy, role, permission, admin screen, route guard, serializer field, export, cache, background job that reads tenant data, or "only admins can…" / "members can see…" rules, and whenever you review such changes — even when the task never says "security" or "authorization".

Rules and review checklist for query and list performance — pagination, N+1 queries, eager loading, indexes, EXPLAIN, search/filter queries, aggregates, JSON columns, large-table migrations, and the frontend side of big lists (duplicate requests, debounce, stale responses, huge DOMs). Use it whenever you add or change a list/index endpoint, a filter or search, a serializer that walks associations, a dashboard/count, a migration or index, or a page that renders many rows — and whenever you review such changes or investigate "this page is slow", even if nobody mentioned performance.

Rules and review checklist for changes that must survive the deploy itself — migration order and reversibility, schema and code deployed at different moments, new environment variables and secrets, backward compatibility between a new API and the old frontend still open in browsers (and the reverse), background jobs lost on restart or run twice, scheduled jobs that overlap or span many tenants, new or upgraded dependencies (security advisories, licenses, lockfiles), feature flags and rollback. Use it whenever a change adds a migration, an env var, a job or scheduler, a dependency, a breaking API change, or anything that needs a specific deploy order, and whenever you review such changes — even if the task only says "add a column" or "bump the gem".

Rules and review checklist for business logic that must stay correct over time — status workflows and state machines, money and decimal amounts, dates, times and time zones, bookings and availability (overlaps, double booking), counters and cached totals, invariants that span several tables, transaction boundaries, soft-deleted records, and an audit trail of who changed what. Use it whenever you add or change a status, a transition, a price/amount/total, a date range or schedule, a reservation or stock rule, a counter, a multi-step write or an admin action that changes someone else's data, and whenever you review such code — even if the task only says "add a cancelled status" or "show the total".

Independent, evidence-based review ("judge") of a merged or open feature — reads the diff of one or more PRs across backend and frontend and their history, runs the project's checks, exercises the app per role with hostile inputs, breaks the code on purpose to test the tests, challenges every finding, and reports only what it can prove, ranked by severity, with a coverage matrix and a ready-to-run fix prompt. Use it whenever the user asks to judge, audit, review in depth, "find any problem", "check the last changes", "verify this feature", or wants a second opinion on code performance, security or correctness of recent work — not for quick style feedback on a small diff. Pass the scope (PRs / commit ranges per repo) as arguments.

Rules and review checklist for anything that accepts, stores, serves or deletes user files — uploads, attachments, documents, images, avatars, imports, downloads, signed URLs, CDN or object storage (BunnyNet, S3, local disk on a VM), the shared upload infrastructure (validators, content-type detection, uploaders), and generated files (PDF, CSV, exports). Use it whenever you implement, change or review such code, even if the task only says "add a PDF field", "let admins attach a file", "allow Word documents" or "fix the download link", and whenever a diff touches upload validators, uploaders or storage services, because those are shared by every feature that handles files.

Rules and review checklist for the user-facing quality of a web frontend change (React, but mostly framework-neutral) — accessibility measured with axe and the keyboard, translations complete in every locale with no hard-coded strings, data that stays fresh after a mutation (cache invalidation, optimistic updates and rollback), navigation that survives refresh, deep links and the back button, error boundaries and error states, Content Security Policy for new resources, and the per-page loading cost. Use it whenever you add or change a page, a form, a modal, a list, a route, a translation, a data-fetching hook or a third-party script, and whenever you review such changes — even when the task only says "add a button" or "show the documents".

Rules and review checklist for operations that may run twice — idempotency keys on create/upload endpoints, double submits, client and proxy retries, concurrent requests for the same thing, unique-constraint races, and calls to external services (storage/CDN, payment, email, messaging) with timeouts and bounded retries. Use it whenever you add or change an endpoint that creates something or has a side effect, an `Idempotency-Key` header, a shared idempotency store, a retry loop or an HTTP client for an external service, and whenever you review such code — even if the task only says "make create safe to retry" or "upload to the CDN".

Workflow for implementing a feature, fix or refactor as one reviewable pull request in a real codebase — read the project rules and the plan, load the matching topic skills, write tests first, keep scope tight, verify locally with the project's own CI steps, self-review, and report honestly. Use it whenever the user asks to implement, build, add, fix or refactor something that will end up as a PR ("implement step 3 of the plan", "add the documents page", "fix the upload bug", "do the next item in the plan"), especially in multi-repo (backend + frontend) projects.

Rules and review checklist for messages and third-party integrations — e-mails, push, SMS and WhatsApp notifications (when they are sent, to whom, how often, in which language, with what content), bulk sends to a whole tenant, user preferences and opt-out, inbound webhooks (signature verification, replay, ordering, idempotent processing, fast acknowledgement) and outbound calls to providers (e-mail/SMS/messaging services, payments, maps). Use it whenever you add or change a mailer, a notification, a message template, a recipient list, a webhook endpoint or handler, or a client for an external provider, and whenever you review such code — even if the task only says "notify the admin" or "handle the delivery status".

Rules and review checklist for user-supplied text that the app stores, compares or shows back — titles, names, descriptions, tags, labels, file names, search terms, slugs. Covers invisible and control characters (NUL, bidi overrides, zero-width), length limits vs column size, normalization that matches the database collation (case, diacritics) for uniqueness and de-duplication, limits on list sizes, and how hostile text renders in the UI. Use it whenever you add or change a form field, a free-text or tag input, a uniqueness rule, an upload's file name or display name, or review such code — even if the task only says "add a title field" or "let admins tag documents".

Rules and review checklist for web-application security beyond authorization — stored and reflected XSS, mass assignment / over-permissive params, open redirects, SSRF on user-supplied URLs, CORS and CSRF on cookie-authenticated endpoints, secrets and personal data in logs, job arguments, error trackers and analytics, rate limiting and enumeration on public endpoints, silent failures that hide attacks or data loss, error traceability, and the lifecycle of personal data (deletion, anonymization, retention). Use it whenever you add or change an endpoint, a param list, a redirect, a fetch of a URL, a cookie, CORS/CSP config, logging, analytics events, error handling or a public (unauthenticated) endpoint, and whenever you review such changes — even if the task never says "security". Pair it with authz-multitenancy (who may do what) and file-uploads-cdn (files).