db-context-supabase

Output contract, in brief. This body is over the per-skill re-injection cap, so after a compaction the sections below are truncated away while this summary survives. They remain authoritative in full; re-read this file before emitting if you need them.

• Standard output layout (required): Produce the command output using this structure (English only):
• Artifact changes: Follow ## Global output contract in WORKFLOW_OPERATING_SYSTEM.md for APPLIED / PROPOSED / SKIP rules.
• Command transcript: Brief audit trail (max 4 lines; max 3 in no-op runs with NO_OP_TRACE).
• Handoff: Use the adaptive ending format from WORKFLOW_OPERATING_SYSTEM.md ## Global output contract (Mode A compact or Mode B full per...
• Definition of done (command output): The MCP precondition check is performed first and its result is reported. When it fails, the local CLI path is checked next; when...

Act as a senior/staff engineering database context capture for the active task, scoped to Supabase.

Goal: Validate that a Supabase MCP server is configured and reachable, introspect a user-scoped subset of the database (tables, columns, types, RLS policies, and optionally functions/migrations), and persist the result as DB_CONTEXT.md inside the active task folder so the task has a grounded, point-in-time schema reference for planning, implementation, and review.

When no MCP server is reachable, the command falls back to the local Supabase CLI and produces the same snapshot from CLI output. Only when neither path is available does it end in a no-op.

This command is opt-in. It is not part of the default task initialization flow; run it after task-init only when the task actually touches Supabase data, schema, or RLS.

Mandatory context bootstrap (before any output):

• Read these sections in WORKFLOW_OPERATING_SYSTEM.md first:
  • ## LLM execution contract
  • ## Editor mode policy
  • ## Global output contract (including Adaptive handoff and Mode selection rule)
  • ## Cross-cutting workflow guardrails
  • ## Evidence priority
• Read additional sections only when needed:
  • naming/path setup: ## Naming conventions, ## Repository structure
  • artifact requirements: ## Task files, ## TASK_STATE policy
• Read the active task's TASK_STATE.md to confirm there is an active task to attach the DB context to and to align the requested table/schema scope with the task objective.
• Read the active task's SOURCE_OF_TRUTH.md to detect any prior ## DB context link before proposing a new one.
• Read the commands/ directory command inventory to ensure routing recommendations are current.

Required inputs:

• active task path (or enough context to resolve projects/<client>__<project>/active/YYYY-MM-DD_<task-slug>/)
• scope of introspection, supplied by the user as one or more of:
  • list of table names (qualified schema.table or unqualified for the default public schema)
  • list of schemas to include in full (use sparingly; large schemas should be narrowed to specific tables)
• depth flag (one of):
  • tables-only: tables and columns with types, primary keys, and not-null flags
  • tables+rls (default): tables-only plus row-level security policies for each in-scope table
  • full: tables+rls plus relevant functions, triggers, and the most recent migration filenames touching in-scope tables
• optional: Supabase project ref (if the MCP server is configured for multiple projects); when omitted, use the project the MCP server is currently bound to and record which one was used
• optional: refresh flag (refresh to regenerate an existing DB_CONTEXT.md; default is to fail with NO_OP_TRACE if a non-stale DB_CONTEXT.md already exists for the same scope)
• optional: path to the local Supabase project directory. Needed only on the local CLI path below, where every CLI form runs from that directory. When omitted and the MCP path is unavailable, ask for it once instead of guessing a directory.