ahtishamshahzad
- 177 skills
- 0 followers
- 13 hours ago last updated
- ▌ Playwright E2e 2 · ahtishamshahzadUse to plan web/dashboard end-to-end tests with Playwright — a small set of critical user journeys against a real browser and running app, resilient to timing (auto-wait, no sleeps), covering happy path plus key invalid/error/authorization-denied flows. Reserved for flows that justify E2E cost.
- ▌ Database Security 2 · ahtishamshahzadUse to review database security from an audit/threat lens — least-privilege access, network exposure, injection surface, encryption of sensitive data, tenant isolation depth, and PII handling — verifying the data-layer hardening holds. The security-review lens; the database pack owns the build-side design.
- ▌ Flaky Test Audit · ahtishamshahzadUse to find, diagnose, and fix flaky tests — nondeterministic passes/failures from timing, shared state, ordering, real time/randomness, or live externals. Fix the root cause; quarantine only temporarily. A trusted suite is the goal, not a green-by-retry one.
- ▌ Web State Management · ahtishamshahzadUse to decide where each piece of web app state lives — local component, form, shared client, server cache, URL, or persisted — before picking any state library. URL state is first-class on the web; server data belongs to the server-state layer, not a global store.
- ▌ Application Documentation · ahtishamshahzadUse to place and maintain the documentation of the applications being built — the `docs/` tree, one folder per app, indexed at every level, with a file per screen, page, endpoint, or job. Distinct from `.ai/`, which holds plans and system rules, not product documentation. Docs ship with the change that causes them.
- ▌ Nestjs Foundation · ahtishamshahzadUse to plan a NestJS foundation after NestJS is approved — module boundaries, dependency injection, providers, pipes/guards/interceptors/filters, config module, conventions for a multi-developer codebase. Plans only; scaffolds nothing without task approval.
- ▌ Mongoose Mongodb · ahtishamshahzadUse to plan Mongoose over MongoDB — expressing the approved document design as schemas with real validation, indexes declared and built deliberately, lean queries, middleware discipline, and transactions only where the design demands them.
- ▌ Incident Readiness · ahtishamshahzadUse to prepare for production incidents — on-call and escalation, severity levels, runbooks for likely failures, alert-to-response wiring, communication paths, and blameless postmortems that feed regression tests. Preparation before incidents, not response during one.
- ▌ Monitoring Logging · ahtishamshahzadUse to plan production monitoring and logging at the ops level — centralized structured logs, key metrics/dashboards, health checks, symptom-based alerting with ownership, uptime/synthetic checks, and cost/retention — so failures are seen fast. Application instrumentation is backend-observability.
- ▌ Monorepo Selection · ahtishamshahzadUse when a monorepo is chosen to pick the workspace/tooling — pnpm/npm workspaces alone vs adding Turborepo for task orchestration and caching — based on app count, build complexity, and CI needs. Evaluates rather than defaulting to the heaviest option.
- ▌ Secrets Management · ahtishamshahzadUse to plan secret storage and handling — a secret store (not git), per-environment separation, least-privilege access, rotation, injection at runtime/CI, and keeping secrets out of code, logs, images, and client bundles. Auditing existing secret exposure is secrets-audit.
- ▌ Mobile File Upload · ahtishamshahzadUse to plan file uploads from mobile — picking files/images, size/type limits, progress, retries, and secure transfer to storage/backend. Validate on the server; keep uploads off executable paths.
- ▌ Mobile Maestro E2e · ahtishamshahzadUse to plan Maestro end-to-end tests for critical mobile flows on real device/emulator. Select Maestro when critical mobile E2E flows exist; cover the critical path (auth, checkout, core journeys) rather than every screen.
- ▌ Mobile Performance · ahtishamshahzadUse to plan and diagnose mobile performance — list rendering, re-renders, image/memory usage, startup, and jank — measured on a representative build. Prefer measured, safe fixes over rewrites. The mobile arm of performance-review.
- ▌ Abuse Prevention · ahtishamshahzadUse to review whether public and expensive endpoints are protected against automated abuse — rate limiting, CAPTCHA/bot defenses, and cost controls on signup, login, reset, OTP, contact, search, and expensive operations. Verifies abuse defenses hold; distinct from authorization.
- ▌ Testing Selection · ahtishamshahzadUse to choose which test types and tools a project needs — Playwright (web/dashboard E2E), Maestro (mobile E2E/smoke), Supertest (backend API integration), Testing Library (components), Jest/Vitest (unit + integration logic). Selects only what the project's applications and risks justify; does not adopt every tool by default.
- ▌ Visual Regression · ahtishamshahzadUse to decide whether visual regression testing is warranted and, if so, plan it — baseline snapshots of key screens/components, deterministic rendering, review-gated diffs, and scoped coverage — without turning it into a flaky, noise-generating burden.
- ▌ Dashboard Permissions · ahtishamshahzadUse to plan admin-dashboard permissions — admin role granularity, a permission matrix per admin action, server-side enforcement, audit logging of admin actions, impersonation safeguards, and least-privilege defaults. Builds on web-authorization for the admin surface.
- ▌ Vite React Foundation · ahtishamshahzadUse to plan a Vite + React SPA foundation after Vite is chosen — TypeScript, project structure, client router selection, env handling (VITE_ exposure, no secrets), build/preview, linting, and SPA host fallback. Plans only; scaffolds and installs nothing without approval.
- ▌ Web Component Testing · ahtishamshahzadUse to plan component tests — React Testing Library with user-event, accessible queries (getByRole first), MSW for network boundaries, testing behavior not implementation, and knowing jsdom's limits (real-browser behavior belongs to Playwright). Avoid snapshot overuse.
- ▌ Backend Deployment · ahtishamshahzadUse to plan backend deployment — target selection, environment config/secrets, build artifact (container) discipline, migration-on-deploy ordering, zero-downtime rollout with health checks, worker/scheduler deployment, and rollback. Deploys require approval.
- ▌ Backend Validation · ahtishamshahzadUse to plan server-side input validation — schema validation at every entry point (body, params, query, headers, files, webhooks, jobs), unknown-field stripping, and type-safe validated output. The server is authoritative; client validation is UX only.
- ▌ Express Foundation · ahtishamshahzadUse to plan an Express API foundation after Express is approved — layered structure (routes/controllers/services/data), middleware order, config, error handler, baseline security middleware. Plans only; scaffolds nothing without task approval.
- ▌ GRAPHQL API Design · ahtishamshahzadUse to decide whether GraphQL fits and to design a GraphQL API — schema/type design, resolvers, N+1 protection (dataloaders), pagination (connections), mutations/errors, query cost limits, and field-level authorization.
- ▌ Database Security · ahtishamshahzadUse to plan database security — least-privilege credentials, network isolation, injection prevention (parameterized-only), encryption at rest/in transit, PII classification and minimization, tenant isolation at the data layer, and access auditing.
- ▌ Prisma Relational · ahtishamshahzadUse to plan Prisma over PostgreSQL/MySQL — expressing the approved schema in the Prisma schema, migration workflow, client usage patterns (select scope, N+1 avoidance, transactions), and where Prisma's abstractions end (raw SQL escape hatch).
- ▌ Repository Strategy · ahtishamshahzadUse to decide how a project's applications are organized into repositories — single repo, monorepo, or multiple repos — based on shared code, coupling, team boundaries, and release cadence. A decision, not a default; feeds monorepo-selection when a monorepo is chosen.
- ▌ Staging Environment · ahtishamshahzadUse to plan a staging environment that meaningfully mirrors production — same artifact, production-parity config/data-shape, isolated from production data, exercising migrations and integrations before prod, and running smoke/E2E as a pre-production gate.
- ▌ Mobile Camera Media · ahtishamshahzadUse to plan camera and media capture — permissions, capture/pick flows, image/video handling, and resizing/compression before upload. Requires native support (dev build or CLI).
- ▌ Mobile Deep Linking · ahtishamshahzadUse to plan deep links and universal/app links — URL scheme, link config, route resolution, and handling cold vs warm starts. Coordinates with navigation and notifications.
- ▌ Mobile Server State · ahtishamshahzadUse to plan server-state caching for mobile — RTK Query or TanStack Query — for fetching, caching, invalidation, retries, and offline behavior. Keeps server data out of client stores.
- ▌ Mobile Unit Testing · ahtishamshahzadUse to plan unit tests for mobile logic — Jest (or Vitest where supported) for pure functions, hooks, reducers, and utilities. Test behavior, not implementation; align with the approved stack.
- ▌ Mobile Vector Icons · ahtishamshahzadUse to plan icon usage — an icon set/library choice, sizing/color via theme, and lean bundling — avoiding shipping entire icon fonts unnecessarily.
- ▌ Regression Testing · ahtishamshahzadUse to ensure every fixed bug and every critical behavior stays fixed — a failing-first test per bug at the lowest level that reproduces it, plus a maintained regression suite gating CI so old breakage can't silently return.
- ▌ Dashboard Architecture · ahtishamshahzadUse to decide where an admin dashboard lives — inside the customer web app, as a route group, as a separate application, or in a separate repository — weighing user roles, deployment boundaries, security boundaries, team ownership, UI system sharing, and release cadence. Placement is a decision, not a default.
- ▌ Backend Performance · ahtishamshahzadUse to diagnose and fix measured backend performance problems — profiling first, then N+1 and query work (with the database pack), caching with explicit invalidation, connection pooling, payload size, and event-loop health. No speculative optimization.
- ▌ Email Notifications · ahtishamshahzadUse to plan transactional email and notification delivery — provider choice, template management, sending via background jobs, deliverability (SPF/DKIM/DMARC), bounce/complaint handling, and abuse-safe triggering.
- ▌ Database Selection · ahtishamshahzadUse to choose the database (PostgreSQL, MySQL, MongoDB) and — separately — the data layer (Prisma, Drizzle, Mongoose, native driver). Relational is usually right for payments, orders, inventory, reporting, financial data, transactions, strong relations; MongoDB fits highly variable documents with embedded access patterns.
- ▌ Drizzle Relational · ahtishamshahzadUse to plan Drizzle over PostgreSQL/MySQL — TypeScript table definitions expressing the approved schema, drizzle-kit migration workflow, SQL-proximate query patterns (joins, prepared statements, transactions), and type flow to the app boundary.
- ▌ Deployment Selection · ahtishamshahzadUse to choose deployment targets per application — managed PaaS, container platform, serverless, static/edge hosting, mobile stores — based on app type, ops capacity, scaling, and cost. Evaluates rather than defaulting; a stack decision requiring approval. Does not provision infrastructure.
- ▌ Production Readiness · ahtishamshahzadUse as the pre-launch go/no-go checklist — confirming tests/security passed, config/secrets/migrations/backups/monitoring/rollback/incident-response are all in place before a production deploy. Aggregates readiness signals; the release gate. Approval required to ship.
- ▌ Turborepo Foundation · ahtishamshahzadUse to plan a Turborepo setup after it's chosen — task pipeline definition (dependsOn), input/output declarations for correct caching, affected-only execution, and CI integration. Plans configuration; does not scaffold apps.
- ▌ Mobile Accessibility · ahtishamshahzadUse to plan mobile accessibility — screen-reader labels/roles, focus order, touch target sizes, contrast, and dynamic type — so the app is usable with assistive tech. Bakes accessibility into components, not bolts it on.
- ▌ Mobile Authorization · ahtishamshahzadUse to plan authorization — role/permission gating of screens and actions, protected navigation, and server-verified access. Roles are enforced server-side; the client hides UI only as a convenience.
- ▌ Mobile Design System · ahtishamshahzadUse to plan a mobile design system — tokens, spacing, typography scale, color palette, and reusable component primitives — before building screens. Establishes consistency; coordinates with theme, fonts, and accessibility.
- ▌ Mobile Location Maps · ahtishamshahzadUse to plan location and maps — foreground/background location permissions, a maps provider, markers/regions, and battery-aware location usage. Requires native support (dev build or CLI).
- ▌ Mobile Notifications · ahtishamshahzadUse to plan push/local notifications — provider (Expo push / FCM / APNs), permissions, token registration, handling foreground/background, and deep-link routing from taps. Requires native support (dev build or CLI).
- ▌ Mobile Project Audit · ahtishamshahzadUse when a mobile app already exists, before changing it — inventory the runtime (Expo vs CLI), navigation, state, native modules, build config, and iOS/Android readiness. Read-only; grounds mobile planning in reality. Delegates deep security/performance to their skills.
- ▌ Integration Testing · ahtishamshahzadUse to plan integration tests across module and I/O boundaries — real database, real wiring, faked externals — covering happy path, invalid input, error path, and authorization denial. For HTTP API specifics use api-integration-testing.
- ▌ Test Coverage Audit · ahtishamshahzadUse to assess test coverage by risk, not by percentage — find untested critical paths (auth, money, data integrity, error/denial paths) and missing required cases, and recommend targeted tests. Never chase a coverage number without risk justification.
- ▌ Backend Unit Testing · ahtishamshahzadUse to plan backend unit tests — services and pure business logic tested in isolation with focused test doubles, fast and deterministic, covering edge and failure paths. Route/database/HTTP coverage belongs to integration testing.
- ▌ Database Migrations · ahtishamshahzadUse to plan schema-migration discipline — versioned immutable migration files, review of generated SQL, deploy-time ordering, zero-downtime expand/contract changes, rollback reality, and environment drift prevention. Data backfills are the data-migration skill.
- ▌ Mobile Authentication · ahtishamshahzadUse to plan mobile authentication — login/signup, token/session handling, secure token storage, refresh, and logout — coordinating with secure storage, API integration, and the auth provider. Client auth is UX; the server enforces.
- ▌ Mobile Error Handling · ahtishamshahzadUse to plan error handling — error boundaries, async/network error handling, user-facing fallback UI, and crash reporting (e.g. Sentry) — so failures degrade gracefully and are observed.
- ▌ Mobile Native Modules · ahtishamshahzadUse to plan native module usage or authoring — evaluating existing packages/config plugins first, and planning custom native modules (iOS/Android) only when needed. Prefer Expo config plugins/dev builds before ejecting.
- ▌ Mobile Secure Storage · ahtishamshahzadUse to plan secure on-device storage — Keychain/Keystore for tokens and sensitive data vs async storage for non-sensitive data — with clear rules on what may be persisted where. No secrets in plain storage or logs.
- ▌ Dependency Security · ahtishamshahzadUse to assess third-party dependency risk from a security angle — known vulnerabilities, supply-chain integrity (lockfiles, pinning, provenance), typosquats/malicious packages, and CI enforcement — driving prioritized upgrades. The security lens on dependencies; dependency-audit is the general inventory.
- ▌ Test Data Management · ahtishamshahzadUse to plan test data — factories over fixtures, per-test isolation, deterministic personas (users, roles, tenants) for authorization tests, and strict separation from production data. No real PII in tests; data is owned per test, not shared and mutated.
- ▌ Backend Authorization · ahtishamshahzadUse to plan backend authorization — who may do what. Distinguishes authentication, role authorization, permission authorization, ownership authorization, organization/tenant scope, and object-level authorization; enforces centrally per endpoint and requires negative tests.
- ▌ Backend Observability · ahtishamshahzadUse to plan backend observability — structured PII-safe logging with request correlation, metrics (rate/errors/duration, queues, jobs), health checks, alerting on symptoms, and tracing when the topology earns it.
- ▌ Database Performance · ahtishamshahzadUse to diagnose and fix measured database performance problems — slow-query identification, EXPLAIN analysis, N+1 elimination, pagination of unbounded reads, connection-pool sizing, and lock-contention diagnosis. Evidence first; indexes via the indexing skill.
- ▌ Environment Management · ahtishamshahzadUse to plan environment configuration across dev/staging/production — one immutable artifact configured by environment, validated typed env vars (fail fast at boot), no secrets in client bundles, and parity so behavior differs only by config. Secret storage itself is secrets-management.
- ▌ Mobile API Integration · ahtishamshahzadUse to plan the HTTP transport layer — fetch vs Axios, base client, interceptors, auth headers, error mapping, and timeouts. Underpins server-state; does not itself cache.
- ▌ Mobile Stack Selection · ahtishamshahzadUse to decide between Expo and React Native CLI for a mobile app, with justification. Evaluates Expo (Go, dev builds, EAS Build/Submit, OTA, common native packages) against React Native CLI (native ownership, custom modules, specialized SDKs, background behavior, CallKit/PushKit, BLE/NFC, existing native projects). Does not default to CLI.
- ▌ Dashboard Bulk Operations · ahtishamshahzadUse to plan dashboard bulk operations — selection scope (page vs all-matching-filter), explicit confirmation with counts, server-side batch endpoints, per-item permission checks, progress and partial-failure reporting, idempotency, undo where feasible, and audit logging.
- ▌ Backend Authentication · ahtishamshahzadUse to plan backend authentication (who the caller is) — credential storage (hashing), sessions vs JWT, token lifecycle/refresh/revocation, logout, and account flows (signup, password reset, OTP). Authentication is not authorization.
- ▌ Backend Error Handling · ahtishamshahzadUse to plan backend error handling — an error taxonomy (operational vs programmer errors), one central handler, a single safe response shape, correct status mapping, and logging with correlation IDs. Internals never leak to clients.
- ▌ Existing Backend Audit · ahtishamshahzadUse to inventory an existing backend before changing it — framework, structure, API surface, auth/authorization model, data layer, jobs, integrations, tests, security posture. Produces findings that feed planning; changes nothing.
- ▌ Realtime Communication · ahtishamshahzadUse to decide whether realtime is needed and design it — SSE vs WebSockets vs polling, authentication on connect, room/channel authorization, reconnection with missed-event recovery, and multi-instance fan-out.
- ▌ Role Permission Design · ahtishamshahzadUse to design the role and permission model — role set, permission granularity, role→permission mapping, storage/claims, admin surfaces, and evolution. Roles gate action classes; ownership/tenant checks remain separate.
- ▌ Mobile Background Tasks · ahtishamshahzadUse to plan background execution — background fetch, location, audio, or task runners — within OS constraints, with battery and lifecycle awareness. Requires native support (dev build or CLI).
- ▌ Mobile State Management · ahtishamshahzadUse to decide where each piece of state lives — local component state, form state, shared client state, server state, persisted state, or navigation state. Prevents dumping everything into Redux/Zustand. Chooses the lightest tool that fits each category.
- ▌ Gherkin Specifications · ahtishamshahzadUse to write and review behavior specifications as Gherkin scenarios — acceptance criteria, required cases, and *.feature files — so one behavior per scenario, domain-level steps, and observable outcomes. Applies the canonical contract in system/GHERKIN_RULES.md; a Cucumber-family runner is a stack decision, the scenario format is not optional.
- ▌ Backend Stack Selection · ahtishamshahzadUse to decide between Express and NestJS (or flag another fit) for a backend API, with justification. Evaluates Express (small/medium APIs, lightweight architecture, fast delivery, limited modules) against NestJS (large modular systems, multiple developers, dependency injection, queues, WebSockets, many domains, strong conventions). No universal default.
- ▌ Ownership Authorization · ahtishamshahzadUse to design ownership, organization/tenant-scope, and object-level authorization — the caller may touch only their own or their tenant's resources. Scope derives from the session, never from client-supplied IDs; requires cross-user and cross-tenant negative tests.
- ▌ Document Schema Design · ahtishamshahzadUse to design MongoDB document schemas — embed vs reference decided per access pattern, document identity and shape per collection, growth-bounded arrays, duplication with consistency ownership, and schema validation despite "schemaless."
- ▌ Mobile Component Testing · ahtishamshahzadUse to plan component tests — React Native Testing Library for rendering, interaction, and accessibility queries — testing components as users interact with them. Complements unit and E2E tests.
- ▌ Authorization Security · ahtishamshahzadUse to review authorization for security holes — IDOR/BOLA, missing ownership/tenant checks, privilege escalation, trusting client-supplied IDs/roles, and function-level access gaps — verified with negative tests. The security-review lens; backend-authorization is the design/build skill.
- ▌ API Integration Testing · ahtishamshahzadUse to plan backend API integration tests with Supertest — real HTTP requests through the full middleware stack against a real database, covering happy path, invalid input, error path, and the authorization-denial negative suite (cross-user, non-admin, cross-tenant, untrusted IDs).
- ▌ Backend API Architecture · ahtishamshahzadUse to define the internal architecture of a backend API — layering (transport/controllers/services/data), domain boundaries, where cross-cutting concerns live, and how modules communicate. Framework-agnostic; foundations apply it per framework.
- ▌ Captcha Abuse Prevention · ahtishamshahzadUse to plan CAPTCHA and bot-abuse prevention for public endpoints — signup, login, password reset, OTP, contact forms, public search, expensive endpoints. Server-side verification, layered with rate limiting; never a substitute for authorization.
- ▌ Third Party Integrations · ahtishamshahzadUse to plan integrations with external APIs — client isolation behind an interface, credential handling, timeouts/retries/circuit breaking, error mapping, sandbox vs production, and testing without live calls.
- ▌ Mobile Environment Config · ahtishamshahzadUse to plan mobile environment configuration — dev/staging/prod separation, env-var handling, base URLs and keys via config (not hard-coded), and safe client exposure. No secrets in the client bundle.
- ▌ Authentication Security · ahtishamshahzadUse to review authentication for security weaknesses — credential storage, session/token handling, brute-force and enumeration resistance, reset/OTP/MFA flows, and logout/revocation. The security-review lens on identity; backend-authentication is the design/build skill.
- ▌ Relational Schema Design · ahtishamshahzadUse to design a relational schema — entities to tables, keys, relationship modeling (1:1/1:N/M:N), constraints as integrity enforcement, appropriate types, normalization with justified denormalization, and soft-delete/audit/money conventions.
- ▌ React Native CLI Foundation · ahtishamshahzadUse to plan a React Native CLI mobile foundation after CLI is chosen — native project ownership (iOS/Android), TypeScript, navigation, safe-area, linting, and native tooling. Evaluates each baseline option against need; installs nothing without approval.
- ▌ Backend Integration Testing · ahtishamshahzadUse to plan backend integration tests — real HTTP requests against the app with a real (containerized) database, covering auth flows, authorization negative tests (cross-user/cross-tenant/role), validation rejection, and webhook/job paths. External providers stay faked.
- ▌ Test Environment Management · ahtishamshahzadUse to provision test environments — real production-engine datastores (containerized), faked externals, isolated per-run state, and critical environment/config validation so tests catch environment failures. Covers local, CI, and ephemeral E2E targets.
- ▌ Security Regression Testing · ahtishamshahzadUse to turn security findings and threats into automated tests that stay green — negative tests for authorization/injection/abuse, a test per fixed vulnerability, and CI enforcement so security regressions can't silently return. Security's regression discipline.
- ▌ Code Review · ahtishamshahzadUse to review a change or diff for correctness, clarity, maintainability, and convention-fit before it advances. Reports findings with severity, separating confirmed defects from suggestions; does not rubber-stamp.
- ▌ Web SEO · ahtishamshahzadUse to plan SEO for web apps where search visibility matters — per-page metadata, Open Graph/Twitter cards, sitemap, robots, canonical URLs, structured data (JSON-LD), and rendering strategy for indexable content. Applies to public/marketing surfaces; skip for authenticated dashboards.
- ▌ CI CD · ahtishamshahzadUse to design the CI/CD pipeline generated from the project's selected applications and test selection — jobs like install, lint, typecheck, unit, API, Playwright, mobile, build, security checks, deployment. Only generate jobs for applications that exist; deploys are approval-gated. Does not scaffold infrastructure.
- ▌ Git Workflow · ahtishamshahzadUse to plan and perform branching, commits, and PRs safely. Branches off the default branch, never commits/pushes without being asked, keeps secrets out of history, and gates git actions behind the relevant hooks and quality gates.
- ▌ Documentation · ahtishamshahzadUse to write or update documentation of the work inside `.ai/` — decisions, project state, work items, knowledge, generated reports — concisely and in its canonical place. For the applications' own documentation (the `docs/` tree), use `application-documentation` instead.
- ▌ Task Planning · ahtishamshahzadUse to generate dynamic phases and break them into concrete, verifiable tasks with inputs, outputs, acceptance criteria, and dependencies. Produces the implementation plan approved at Gate 4. Phases are derived from real work, never a fixed template.
- ▌ Web Forms · ahtishamshahzadUse to plan web forms — React Hook Form (or framework-native alternatives), Zod schema validation at the edges, accessible inline error UX, submit states, and multi-step flows; on Next.js, whether server actions handle submission. Client validation is UX; the server enforces.
- ▌ Web Theme · ahtishamshahzadUse to plan light/dark theming on top of design tokens — system preference detection, manual override with persistence, SSR flash avoidance on Next.js, and contrast validation in both themes. Themes switch token values; components never hardcode colors.
- ▌ Queues · ahtishamshahzadUse to select and design queue infrastructure — broker choice (e.g. BullMQ/Redis, SQS, RabbitMQ), queue topology, workers/concurrency, delivery semantics, dead-letter queues, and monitoring. Job behavior itself is the background-jobs skill.
- ▌ Security Review · ahtishamshahzadUse to assess a change or codebase for security weaknesses — secrets, auth, authorization/IDOR, injection, PII handling, transport/errors, payments, and production hardening. Reports findings by severity, separates confirmed from potential, never prints secret values, and never claims "secure."
- ▌ Web Routing · ahtishamshahzadUse to plan web app routing — route tree, layouts, nested routes, dynamic segments, route groups, protected routes, and URL-carried state. Covers Next.js App Router conventions and client router selection (React Router / TanStack Router) for Vite apps. Client-side protection is UX; the server enforces.