emersonjds

Use ao implementar ou revisar QUALQUER feature de backend do BdayList no Supabase (Postgres + RLS + Edge Functions). Cobre motor de reserva atômico/idempotente, modelo de dados, contratos de RPC/endpoint, notificações e enriquecimento de link. Invoque para reserva/cancelamento de presente, RSVP, recados, jobs/cron, e quando o frontend precisar do shape correto dos payloads.

Use ao criar/alterar tabelas, policies RLS, Edge Functions ou qualquer superfície que toque PII de convidados, token de compartilhamento, ou enriquecimento de link no BdayList. Garante RLS fail-closed, privacidade da opção "surpresa", anti-SSRF/XSS e conformidade LGPD (dados em São Paulo). Invoque antes de mergear qualquer mudança de schema ou de autorização.

Specialize Blue Spec in a specific security area, from a source or topic you give it. It reads the material and distills it into a focused, defense-only sub-skill, shaped exactly like the built-in ones, so `/bluespec.skills` loads it afterwards like any other. It only audits and explains — it never writes attack inputs or exploits, and it never touches your code.

Establish or update the project's security charter, the safe-by-default principles every later Blue Spec phase must respect. Proposes a charter when run with no input, or follows the input when given.

Detect what the system actually does by reading the code, and map the security-relevant findings (login, uploads, payments, data exposure, and so on) with the evidence later phases need. Scans the whole project, specific files, or a focused scope, depending on the input.

Apply the defense plan's fixes to the code, safely and one at a time, then record what was applied and what is left. Reads the defense plan and the charter, then hardens every fix, just the fixes, files, or directories you name, or the priorities you choose.

List the findings Blue Spec is tracking, by name. It reads `.bluespec/tracking.json` through a hook and prints each tracked finding's name. It has no dependency on any phase and changes nothing, it only reads and reports. If nothing is tracked yet, it says so.

Turn what detect found into the defense plan, with a fix for each finding, its priority, and the charter principle it upholds. Reads the detect map and the charter, then plans every finding, just the files or directories you name, or a specific concern you describe.

Write the missing tests for the gaps redbar found, following the canonical standard for that layer (Playwright's best practices for e2e, Vitest/Jest idiom for unit, Testcontainers for integration). Reads `.redbar/gaps.json`, writes one test file per gap, RUNS each test it wrote, and never leaves a failing test behind — a test that fails twice is marked needs-human and deleted. Use after /redbar.inspect, or when asked to write the missing tests, cover a gap, or fix coverage.

Set a project up so redbar can inspect it. Detects the language and the test runner it actually uses, then proposes the test libraries that are missing (unit, integration, e2e) and prints the exact install command. It NEVER installs anything and never edits a manifest — the human approves and runs the command. Use when redbar reports no coverage report, when a project has no test setup, or when asked how to start testing a repo.

Find the test-coverage gaps in what changed on this branch. Runs the redbar engine, which crosses the project's coverage report with `git diff` and ranks the untested symbols by criticality. It calls no model to produce the number — the number comes from the coverage report and git. Use before opening a PR, when asked "what should I test?", or when asked what the branch left untested. It writes `.redbar/gaps.json` and reports what came back.