Francisco×Lovable
Lovable Skill for Non-Coders

RLS Policy Auditor

Use /rls-policy-auditor when you are unclear or missing RLS policies. It helps Lovable review RLS policies, identify missing protection, and recommend safer rules. The goal is to protect user data without breaking the app.

In plain English

This skill helps Lovable follow a safe process for audit RLS policies so non-coders can keep building without guessing the next technical step.

The problem

Review RLS policies, identify missing protection, and recommend safer rules.

When to use it

  1. You added a new table
  2. You enabled Supabase auth
  3. You want to publish your app
  4. You are unsure who can read or write data

What this skill checks

  • Check RLS is enabled on every table
  • Check policies for read and write
  • Check service role vs anon role usage
  • Recommend updates

What to avoid

  • Unrelated redesigns
  • Broad rewrites
  • Database changes without a reason
  • Hidden security risks
  • Changing working behaviour without explaining the impact

Skill instructions

Copy this into your Lovable workspace as a saved skill.

SKILL.md
# /rls-policy-auditor

Use this skill when unclear or missing RLS policies in a Lovable project.

Before editing:
1. Explain the current problem in plain English.
2. Identify the affected feature, route, component, table, function, or integration.
3. Review recent changes where relevant.
4. Produce a short fix or implementation plan before making changes.

What to check:
- Check RLS is enabled on every table.
- Check policies for read and write.
- Check service role vs anon role usage.
- Recommend updates.

Rules:
- Do not redesign unrelated parts of the app.
- Do not rewrite unrelated components.
- Do not change database schema unless clearly required.
- Do not expose private data or secrets.
- Prefer the smallest safe change.

Implementation:
1. Apply the smallest safe change first.
2. Keep each change narrow and testable.
3. Preserve existing working behaviour.
4. Add or recommend test scenarios.

Final output:
- Problem summary.
- Root cause or best diagnosis.
- Changes applied or recommended.
- Files, routes, tables, functions, or integrations affected.
- Risk level.
- Test checklist.
- Next recommended step.

Example prompt

Prompt
Use /rls-policy-auditor to review this issue. Do not make changes yet. First explain the diagnosis, risks, and safest next step.

Expected output

Plain-English diagnosis
Risk level
Files, routes, tables, or integrations affected
Safe fix plan
Test checklist
Next recommended step

Related skills

FAQ

Cite this skill: Opazo, F. (2026). RLS Policy Auditor. Frank Opazo Lovable Skills Library. https://www.frankopazo.com/lovable-skills/rls-policy-auditor