AI Agent Workflow Collection

Use to critically review AI-generated output (plans, code, docs, decisions) for the failure modes AI agents are prone to — unsupported assumptions, invented facts, conflicting architecture, unnecessary dependencies, security risks, missing tests, over-engineering, scope expansion, outdated patterns, incomplete validation, and false claims of completion.

Use to validate Android release readiness — application id, signing (keystore/Play signing), permissions and manifest, target/compile SDK, 16KB page-size support, and Play policy fit. Read-and-verify; flags gaps before submission.

Use to decide which applications a project actually needs (mobile, public web, admin dashboard, marketing site, backend, worker, real-time service, database, file storage, shared packages). Each is evaluated independently with justification; nothing is auto-scaffolded.

Use 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.

Use 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.

Use 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.

Use 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.

Use 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.

Use 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.

Use 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.

Use 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.

Use to plan backend security hardening — secrets handling, security headers, CORS, injection defenses, dependency risk, request limits, and audit logging. Coordinates the specialist skills (validation, authz, rate limiting) and feeds security-review.

Use 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.

Use 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.

Use to plan backups and recovery — RPO/RTO targets, automated backups with point-in-time recovery where needed, off-site/cross-account copies, retention, encryption, and above all restore drills: an untested backup is a hope, not a plan.

Use to diagnose and plan the fix for a defect — audit, reproduce, find root cause, fix minimally, add a regression test, and validate. Fixes the cause, not the symptom, and pins it so it can't return.

Use 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.

Use 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.

Use 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.

Use 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.

Use to plan dashboard reports and charts — server-side aggregation, date-range/filter state in the URL, chart library evaluation, CSV/PDF export, scheduled reports, and handling slow queries (async generation, caching). Numbers must be verifiably correct before charts get pretty.

Use to plan dashboard data tables — server-side vs client-side pagination/sorting/filtering by data size, column architecture, virtualization for large sets, row selection for bulk operations, URL-carried table state, and library evaluation (e.g., TanStack Table).

Use 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.

Use 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.