cotera

Supabase User Data Manager

Look up users, onboard new signups, and keep user properties current without writing queries. Manage your Supabase user table from a conversation.

User managementRecord creationProfile updatesData enrichment

The Challenge

Managing user data in Supabase means switching between the dashboard, writing SQL for one-off lookups, and building admin scripts for batch updates. When a new cohort signs up, someone has to create their records. When enrichment data comes back from a third party, someone has to match it to the right users and update their profiles. Each task is simple on its own but they add up to hours of context-switching every week.

What This Prompt Does

Look Up Users

Searches your users table by email, ID, or any field and returns full profile records

Create Records

Inserts new user rows with duplicate checking so you never accidentally create two records for the same person

Update Properties

Modifies plan tiers, activity timestamps, enrichment fields, and status flags on existing user records

Batch Process

Handles multiple users in one pass with a summary of what was created, updated, or skipped

The Prompt

The Prompt

Task

Use @Supabase/Read RecordsName it "Supabase/Read Records" and call it with @Supabase/Read Records to look up existing user records by email, ID, or other identifiers, @Supabase/Create RecordName it "Supabase/Create Record" and call it with @Supabase/Create Record to insert new user entries for signups or imports, and @Supabase/Update RecordName it "Supabase/Update Record" and call it with @Supabase/Update Record to modify user properties based on activity data, enrichment results, or manual corrections.

Input

The user provides:

  1. The action to perform: lookup, create, update, or a combination
  2. User identifiers (email, user ID, name) for lookups
  3. User data for creation (name, email, role, plan, metadata)
  4. Fields and values to update for existing users
  5. The Supabase table name (defaults to "users" if not specified)

Example: "Look up the user with email alice@exampleName it "example" and call it with @example.com. If they exist, update their plan to 'pro' and set last_active to today. If they do not exist, create a new user record with that email, name Alice, and plan set to 'free'."

Context

User Lookup

  1. Use @Supabase/Read RecordsName it "Supabase/Read Records" and call it with @Supabase/Read Records to search for users by email, ID, or other fields
  2. Apply filters to narrow results (e.g., filter by org_id, role, status)
  3. Return the full user profile with all relevant columns
  4. If no user is found, report that clearly so the user can decide to create one

Creating New Users

  1. Use @Supabase/Create RecordName it "Supabase/Create Record" and call it with @Supabase/Create Record to insert a new row into the users table
  2. Include all required fields: email, name, and any default values (created_at, status, plan)
  3. Check for duplicates first by reading existing records with the same email
  4. If a duplicate exists, warn the user instead of creating a second record
  5. Return the created record with its generated ID

Updating User Properties

  1. Use @Supabase/Read RecordsName it "Supabase/Read Records" and call it with @Supabase/Read Records to find the user to update
  2. Use @Supabase/Update RecordName it "Supabase/Update Record" and call it with @Supabase/Update Record to modify specific fields
  3. Common update scenarios:
    • Plan or subscription tier changes
    • Profile updates (name, avatar, bio)
    • Activity tracking (last_active, login_count)
    • Enrichment data (company, title, LinkedIn URL)
    • Status changes (active, suspended, churned)
  4. Always confirm the update was applied by reading the record again

Batch Operations

If the user provides multiple users to process:

  1. Process each user sequentially
  2. Report results for each: created, updated, skipped (duplicate), or not found
  3. Provide a summary at the end with counts

Safety Guidelines

  • Always check for existing records before creating to prevent duplicates
  • Show the current record state before applying updates
  • Never modify auth-sensitive fields (password_hash, tokens) without explicit instructions
  • Log every change with the before and after values

Output

User Data Operation Results:

Lookups: | Email | Found | User ID | Plan | Status | |-------|-------|---------|------|--------| | [email] | Yes/No | [id] | [plan] | [status] |

Records Created: | Email | Name | Plan | User ID | |-------|------|------|---------| | [email] | [name] | [plan] | [generated_id] |

Records Updated: | User ID | Field | Previous Value | New Value | |---------|-------|----------------|-----------| | [id] | [field] | [old] | [new] |

Summary:

  • Looked up: [n] users
  • Created: [n] new records
  • Updated: [n] existing records
  • Skipped: [n] (duplicates or not found)

Example Usage

Try asking:

  • →"Look up the user with email bob@acme.com and update their plan to enterprise and set their company to Acme Corp."
  • →"Create new user records for these three signups: alice@test.com (Alice, free plan), bob@test.com (Bob, pro plan), carol@test.com (Carol, free plan)."
  • →"Find all users where last_active is older than 60 days and update their status to inactive."