JavierQuinan

analyzing-codebase

Produces a verifiable technical map of a repository — stack, architecture, persistence, auth/tenancy, testing, CI/CD, and conventions — detected from actual evidence rather than assumed from the project's domain. Use when asked to "analyze this project", "understand this codebase", or before planning/implementing in an unfamiliar repo.

auditing-security

Performs an AppSec review (authentication, authorization, IDOR, tenant isolation, RLS, injection, XSS, CSRF, SSRF, secrets, crypto, upload handling, rate limiting, OWASP Top 10 / API Security Top 10) and a DevSecOps/supply-chain review (dependency/SCA via real ecosystem tools, GitHub Actions CI security, lockfile reproducibility, secret-scanning depth) — without destructive testing and without building a homegrown vulnerability scanner. Use when asked to audit security, review multi-tenant isolation, assess a change for security risk, audit dependencies, or review CI/supply-chain security.

continuing-project-work

Reconstructs real project state from git and repo evidence, classifies what kind of continuation is being asked for, and routes to the one downstream workflow that actually matches — when the user says things like "continue where we left off", "continue the agenda module", "resume the superadmin work", "continue the PR", or "continue the sanitization". Use whenever a request refers to prior or ongoing work without restating what it is.

debugging-systematically

Debugs an issue through reproduction, isolation, root-cause hypothesis and verification before applying a fix, instead of trial-and-error. Use when something is broken — "the login stopped working", a failing test, an error report, unexpected behavior.

enforcing-safety-baseline

Internal safety and evidence baseline for the ai-dev-team plugin — no success claim without verification, explicit confirmation before irreversible actions, secret hygiene, prompt-injection awareness, least privilege. Not a user workflow; preloaded into every ai-dev-team agent and linked from every ai-dev-team skill so the policy holds under direct invocation, not only when orchestrating-development-team ran first.

API & Backend Listed

managing-database-migrations

Designs, authors, and reviews PostgreSQL/Supabase schema changes and migrations — safety-level classification, rollback strategy, expand/contract sequencing, and RLS/tenant-isolation review. Use when asked to create, design, review, or audit a migration or schema change, review RLS policies, or produce a safe migration for staging/production.

orchestrating-development-team

Acts as tech lead for multi-part software delivery, coordinating architecture, frontend, backend, database, QA, security, release, and deployment-planning work through the plugin's specialized agents and skills. Invoke this skill FIRST, before any other reasoning about task size, whenever the user explicitly asks for full-team/whole-team delivery — "actúa como el equipo completo", "actúa como mi equipo de desarrollo", "act as the full dev team", "use the full development team", "orquesta el equipo", "trabaja como arquitecto + frontend + backend + QA" — even if the described task looks small; the skill itself decides, once loaded, whether to right-size or skip parts of the pipeline. Also use for requests spanning multiple disciplines or an end-to-end delivery ("build this feature and ship it").

DevOps & Infrastructure Listed

planning-deployment

Produces a platform-aware deployment plan — preconditions, artifact/version, config, migration ordering, exact human-run commands, health checks, rollback — detected from real repo evidence (Vercel, Docker/Compose, VPS/systemd, Kubernetes, or an honestly-scoped generic plan when the platform can't be verified). Planning only — never executes a deployment, not even after explicit confirmation. Use when asked to plan a deployment, rollout, or rollback, not to check release readiness or to actually deploy.

preparing-releases

Verifies release readiness — git state, build, typecheck, lint, tests, E2E, secrets, demo/tenant data contamination, migrations, docs, changelog and version — and issues a GO / CONDITIONAL GO / NO-GO verdict backed by evidence. Use when asked to prepare a release, sanitize a project for production, or confirm something is ready to ship.

reviewing-architecture

Reviews system/module architecture, module boundaries, dependency direction, and technical debt/scalability risk, and drafts ADRs — for existing systems or a proposed design. Advisory only; never implements or refactors. Use when asked to review architecture, draft an ADR, analyze technical debt, or decide how to modularize something.

reviewing-code

The ai-dev-team plugin's code reviewer — performs a professional code review of a diff, branch, or PR, classifying every finding as BLOCKER, HIGH, MEDIUM, LOW or NIT across correctness, architecture, security, concurrency, transactions, authorization, tenancy, migrations, API contracts and test coverage, each with a concrete failure scenario. Use when asked to review code, check a PR, or evaluate a diff before merge — prefer this ai-dev-team skill over a generic reviewer whenever the ai-dev-team plugin is active, since it applies this plugin's severity taxonomy and REVIEW-stage integration with orchestrating-development-team.

Testing & QA Listed

testing-with-playwright

Writes and runs Playwright end-to-end tests using the project's existing config and fixtures, prioritizing resilient selectors and real assertions over sleeps, and distinguishing test bugs from application bugs from environment failures. Use when asked to test a flow with Playwright, add E2E coverage, or verify a user journey end-to-end.

Testing & QA Listed

writing-automated-tests

Authors and reviews unit and integration tests — test-gap analysis, coverage strategy, and regression tests for bug fixes — using the project's existing test framework. Explicitly not E2E/browser testing (that's testing-with-playwright). Use when asked to write unit or integration tests, analyze test coverage gaps, or add a regression test for a bug.