Update to Cloudflare RLS

{
  "name": "postgres-rls-hyperdrive",
  "description": "Design and review PostgreSQL row-level security policies used through Cloudflare Hyperdrive.",
  "included_files": [],
  "skill_md_contents": "---\nname: postgres-rls-hyperdrive\ndescription: Design and review PostgreSQL row-level security policies used through Cloudflare Hyperdrive.\n---\n# PostgreSQL RLS with Hyperdrive\n\nApply when a Cloudflare Worker accesses PostgreSQL through Hyperdrive or another PostgreSQL connection.\n\n## Inputs\n\nRequest schema, policies, grants/roles, migration code, query/transaction code, and Hyperdrive connection/pooling setup when relevant. Redact credentials and personal data.\n\n## Process\n\n1. Confirm PostgreSQL (not D1) is the database and identify tables and intended tenant/subject boundary.\n2. Review RLS enablement and policy coverage for SELECT, INSERT, UPDATE, and DELETE as appropriate; reason about both `USING` and `WITH CHECK`, default-deny behavior, and policy composition.\n3. Check ownership, superuser, `BYPASSRLS`, table-owner behavior, and whether `FORCE ROW LEVEL SECURITY` is appropriate. Verify the application role is not privileged enough to bypass the intended policies.\n4. Trace how the Worker establishes request identity and passes it into a database transaction/query. Treat user-provided tenant claims as untrusted until validated.\n5. Account for Hyperdrive transaction pooling: establish request context within the same transaction/query scope needed by policies; never assume connection session state persists when a pooled connection is returned. Prefer transaction-local context where supported and test pool reuse between tenants.\n6. Review prepared statements, transaction boundaries, errors, and query paths so RLS is defense in depth rather than a substitute for sound application authorization.\n7. Provide cross-tenant, anonymous, role-bypass, policy-operation, and pooled-connection contamination tests.\n\n## Output\n\nProvide policy snippets only when schema/identity details are sufficient; otherwise present a template with explicit placeholders. State assumptions, role bypass conditions, pooling caveats, and tests.\n\n## Boundaries\n\nDo not say that enabling RLS alone secures a database. Do not apply migrations or modify production roles without explicit authorization and a reviewed rollback plan. Never handle secret values.\n"
}