supabase-postgres-best-practices (supabase/agent-skills)
Supabase のベストプラクティスで、Postgres のスキーマ設計、マイグレーション、RLS、インデックス、クエリ性能を導きます。
Supabase Postgres ベストプラクティス：スキーマ、レビュー、インデックスの各タスクで素の Codex に対する向上なし（4.48 対 4.54）
Codex CLI · gpt-6-astra
24.4 / 30
スキルなしに対するリフト：-0.06 · 状況次第 · 18 実行
状況次第：リフト -0.06 が +1.0 未満。推奨には合計 22/30、出力品質 3.5、リフト +1.0 が必要です。
SOTA
合格Codex でテスト済み。
カバー対象 Codex, Claude Code
Codex CLI 0.166（SOTA ティア）：採点対象 18 実行。当ティアのルールでは、ここでの合格は Claude Code もカバーします。第2ティアについては何も述べません。
スコア
各ディメンションは 0〜5 点で、6 つの合計が 30 点満点の合計スコアになります。すべてのディメンションで 5 が最良です。コスト 5 は低コストで高速、インストール 5 は簡単であることを意味します。
- トリガーの信頼性
- 5.0
- スキルなしに対するリフト
- 1.9
- 出力品質
- 4.5
- トークンと時間のコスト
- 4.0
- インストールと移植性
- 4.0
- 安全性
- 5.0
セキュリティレビュー
安全静的スキャン：CRITICAL 0 / HIGH 4 / MEDIUM 0。手動レビュー：ネットワーク無効のサンドボックスで実行しても安全（スキャナの指摘は確認済み）。クリーンなスキャン結果はスキルの安全性を証明しません。
インストール
npx skills@latest add supabase/agent-skills --skill supabase-postgres-best-practices
固定コミット: c9be0e931b7930f7d02126d04774d904c381e7d7
テスト済み: 2026-11-02
テスト内容
- RLS 付きマルチテナントスキーマ — Supabase（Postgres）のマルチテナントプロジェクトトラッカー向けに schema.sql を書いてください：organizations、memberships（Supabase の auth ユーザーはロール付きで組織に所属）、projects、tasks（assignee、status、due date）、tasks への comments。ユーザーは自分に関係のあるものだけを見て変更でき…
- スキーマ、クエリ、ワーカーをレビュー — schema.sql、queries.sql、worker.py（Supabase/Postgres のサポートチケットアプリ）をレビューしてください。問題点を、最も深刻なものから順に、それぞれの修正方法とともに列挙してください。ファイルは変更しないでください。リストは最終回答に書いてください。
- 3 つの遅いクエリへのインデックス — slow_queries.md の 3 つのクエリは schema.sql のテーブル（120M 行）では遅くなります。行うインデックス変更だけを migration.sql に書き、どのインデックスがどのクエリを対象にするかと注意点を notes.md（最大 120 語）に書いてください。（データベース…
長所
- スキルは名前を出さずとも採用されました：スキルあり群 6/6 実行でスキルファイルが読み込まれました。
短所
- スキルなしに対する有意なリフトなし（-0.06、ノイズの範囲内）。
- 一文プロンプトは 4.75、スキルありは 4.48（-0.27）。
- タスク・群ごとに n=2。1 ポイント未満の差はノイズです。
レビュー
Mac テストマシン上で Codex CLI 0.166（gpt-6-astra、低推論）、実行ごとに新規の一時プロジェクトと一時 HOME/TMPDIR/キャッシュを使用、スキルをインストール（スキルあり群）、スキルなし（対照群）、またはスキルの中核要件をプロンプト末尾に付けた一文に圧縮（一文プロンプト群）、タスクごとに各群 2 実行、ネットワーク無効、/tmp への書き込みはブロック。プロンプトはスキル名に一切言及しません（以下で注記する表現を除く）。3 つのタスク：RLS 付きのマルチテナント Supabase スキーマの作成（チェック：全テーブルに RLS、select でラップされた auth.uid()、全外部キーにインデックス、timestamptz、identity または uuid キー、制約、小文字の名前）、11 件の仕込まれた問題点を持つ欠陥のあるスキーマ/クエリ/ワーカーのレビュー、120M 行のテーブルに対する 3 つの遅いクエリのインデックス移行とメモの作成（複合インデックス、部分インデックス、CONCURRENTLY、最大 4 インデックス）。
3群の比較
| 群 | 平均スコア（0〜5） | 1実行あたりのトークン |
|---|---|---|
| スキルなし | 4.54 | 77k |
| 一文プロンプト | 4.75 | 80k |
| スキルあり | 4.48 | 93k |
Codex CLI で 18 実行を計測し、LLM 判定なしのルールベースのチェックで採点。合計 24.4 / 30、判定は 状況次第。
判定：状況次第（24.4 / 30）。 ソース：supabase/agent-skills、skills/supabase-postgres-best-practices、コミット c9be0e9 に固定。インストール：npx skills@latest add supabase/agent-skills --skill supabase-postgres-best-practices。ライセンス： MIT（リポジトリの LICENSE）。
概要
supabase/agent-skills の supabase-postgres-best-practices スキルは、Supabase プロジェクト向けの Postgres のパフォーマンスとスキーマのガイダンスを約 35 の参照ファイルで提供します（クエリのパフォーマンスとインデックス、接続管理、セキュリティと RLS、スキーマ設計、並行性とロック、データアクセスパターン、モニタリング）。440 語の SKILL.md がそれらを索引付けしています。Markdown のみで、スクリプトはありません。
テスト方法
Mac テストマシン上で Codex CLI 0.166（gpt-6-astra、低推論）、実行ごとに新規の一時プロジェクトと一時 HOME/TMPDIR/キャッシュを使用、スキルをインストール（スキルあり群）、スキルなし（対照群）、またはスキルの中核要件をプロンプト末尾に付けた一文に圧縮（一文プロンプト群）、タスクごとに各群 2 実行、ネットワーク無効、/tmp への書き込みはブロック。プロンプトはスキル名に一切言及しません（以下で注記する表現を除く）。
3 つのタスク：RLS 付きのマルチテナントの Supabase スキーマを作成する（チェック：全テーブルで RLS、select でラップした auth.uid()、全外部キーにインデックス、timestamptz、identity または uuid キー、制約、小文字の名前）、欠陥のあるスキーマ／クエリ／ワーカーをレビューして 11 の仕込み問題を探す、1 億 2000 万行のテーブルで 3 つの遅いクエリに対するインデックスのマイグレーションとメモを書く（複合インデックス、部分インデックス、CONCURRENTLY、最大 4 インデックス）。
- RLS 付きマルチテナントスキーマ — Supabase（Postgres）のマルチテナントプロジェクトトラッカー用に schema.sql を書いてください：organizations、memberships（Supabase の auth ユーザーがロール付きで組織に属する）、projects、tasks（担当者、ステータス、期日）、タスクへの comments。ユーザーは自分の属する組織のものだけを見て変更…
- スキーマ、クエリ、ワーカーのレビュー — schema.sql、queries.sql、worker.py（Supabase/Postgres のサポートチケットアプリ）をレビューしてください。問題を深刻なものから順に、それぞれ修正方法とともに列挙してください。ファイルは変更しないでください。リストを最終回答に書いてください。
- 3 つの遅いクエリのインデックス — slow_queries.md の 3 つのクエリは、schema.sql のテーブル（1 億 2000 万行）で遅くなっています。行うべきインデックスの変更（それのみ）を migration.sql に書き、どのインデックスがどのクエリに効くかと注意点を notes.md（最大 120 語）に書いてください。（データベー…
採点はプログラム的（隠しテスト／仕込み問題の検出／制約チェック／該当する場合はレンダリング+OCR）で、実行ごとに 0〜5 点。スコアはどの LLM 判定者も決めていません。
結果
第 3 の群に与えた一文プロンプト："Postgres のベストプラクティスを適用してください：すべての外部キーと WHERE/ORDER BY で使われるすべてのカラムにインデックスを張る（複合インデックスは等価カラムを先に、まれなステータスには部分インデックス、大きなテーブルでは CREATE INDEX CONCURRENTLY）、公開するすべてのテーブルで RLS を有効にし auth.uid() を (select auth.uid()) でラップする、timestamptz、identity または uuid キーと小文字の snake_case 名を使う、ページネーションは offset ではなく keyset を使う、トランザクションは短く保つ（内部で外部呼び出しをしない）。"
| タスク | 対照群スコア | 一文プロンプト | スキルあり | 対照群トークン | 一文プロンプトトークン | スキルありトークン | スキルの読み込み |
|---|---|---|---|---|---|---|---|
| t1-schema | 4.52 | 4.79 | 4.16 | 104k | 121k | 124k | 2/2 |
| t2-review | 4.09 | 4.46 | 4.28 | 64k | 56k | 70k | 2/2 |
| t3-indexes | 5.0 | 5.0 | 5.0 | 60k | 61k | 84k | 2/2 |
平均スコア：スキルなし 4.54 に対しスキルあり 4.48（差 -0.06）。1実行あたりのトークン：77k に対し 93k（1.21 倍）。所要時間 78 秒に対し 73 秒。一文プロンプト群：4.75（一文プロンプトに対するスキルの上乗せ：-0.27、スキルなしに対する一文プロンプトの上乗せ：+0.21）。一文プロンプトのトークンは 1実行あたり 80k で、スキルは一文プロンプトの 1.16 倍のトークンを消費します。
何が起きたか
- 差はありません：平均は対照群 4.54、一文プロンプト 4.75、スキルあり 4.48。スキルは対照群に対して -0.06 で、トークンは 1実行あたり 93k に対し 77k（1.2 倍）です。
- インデックスタスクは、すべての群のすべての実行で解けました（6 つのインデックスチェックすべてが全群で 6/6 合格。CONCURRENTLY と 4 インデックス以内の維持を含む）。素の Codex はすでにこれらの基本を知っています。
- スキーマタスクでは、すべての群が全外部キーにインデックスを張り、全テーブルで RLS を有効にし、uuid/identity キーを使いました。auth.uid() を (select auth.uid()) でラップすることは、どの群もポリシーの一部でしか行われませんでした：対照群とスキルありの実行では 5〜6 箇所中 3 箇所、一文プロンプトの 1 実行では 5 箇所中 5 箇所。このルールでは一文プロンプト群が最良でした（2 中 1.6、対照群とスキルありは 1.1）。スキルありの 1 実行は素の timestamp カラムを使い（3.86）、全実行中最低のスコアでした。
- レビュータスクでは、すべての群が 11 の仕込み問題中 8〜9 件を見つけました（2 チェック中 1.5〜1.7）。スキルがより多く見つけたわけではありません。
- インデックスタスクは一度再実行しました。最初のバッチは、仕様の誤り（フィクスチャリストが空）で入力ファイルを与えられず、6 実行すべてが「ファイルが存在しない」と報告しました。仕様を修正してその 6 実行を再実行しました。以前のものはカウントしていません。
ディメンション別スコア
| ディメンション | スコア | 理由 |
|---|---|---|
| 1_出力品質 | 4.48 | スキルありの平均スコア 4.48/5（プログラム的チェック。タスク別の表を 参照）。 |
| 2_スキルなしに対するリフト | 1.94 | スキルなし 4.54 に対して -0.06 ポイント（タスクごとに n=2。約 1 ポ イント未満の差はノイズ）。 |
| 3_トリガー | 5.0 | スキルあり群 6/6 実行でスキルファイルが読み込まれました。 |
| 4_指示の移植性 | 4 | プレーンな Markdown のルールファイル。open skills のレイアウトに従っています。 |
| 5_効率性 | 4 | トークン 1.21 倍（1実行あたり 93k に対し 77k）、時間 0.93 倍（73 秒に対し 78 秒）。 |
| 6_安全性と衛生 | 5 | Markdown のみ。スキャナの 4 件の HIGH ヒットは、テーブル名
|
本テストの限界
- 小さなファイルの教科書的な問題です。RLS を超えた Supabase 固有の点（コネクションプーリング、Realtime、ストレージ）はテストしていません。
- 項目は正規表現で照合されるため、言い回しが異なる修正は見落としとして数えられます。
- スキルのロック、モニタリング、データアクセスパターンに関するルールは実行していません。
- タスク・群ごとに n=2。1 ポイント未満の差はノイズです。
- ルールベースの採点はチェックが検出できるものだけを測ります。センスや、結果が最善かどうかは判定できません。
セキュリティ
security.md を参照。スキャン：CRITICAL 0 / HIGH 4 / MEDIUM 0。判定：実行しても安全（ネットワーク無効のサンドボックス）。クリーンなスキャン結果はスキルの安全性を証明しません。
結論
スキーマ設計、レビュー、インデックスのタスクでは、素の Codex がすでにこのスキルの列挙するプラクティスを適用しており、スキルはスコアを改善せず、約 20% のトークンを追加しました。これらのテストが扱わなかった、より珍しい Supabase のトピックの参照としては依然として有用かもしれません。
トランスクリプト
実行ログ：supabase-postgres-best-practices (Codex CLI, network off, per-run temp HOME/TMPDIR, one row per graded run.) 列：タスク、群-回、スコア（0-5）、トークン、秒、合格したチェック、エージェントが開いたスキルファイル。 t1-schema control-1: スコア 4.57, トークン 105331, 秒 124.5, チェック 6/7, 開いたファイルなし t1-schema control-2: スコア 4.46, トークン 104624, 秒 130.1, チェック 6/7, 開いたファイルなし t1-schema oneliner-1: スコア 5.0, トークン 111153, 秒 140.4, チェック 7/7, 開いたファイルなし t1-schema oneliner-2: スコア 4.57, トークン 132693, 秒 145.1, チェック 6/7, 開いたファイルなし t1-schema treatment-1: スコア 3.86, トークン 123861, 秒 108.3, チェック 5/7, 開いたファイル supabase-postgres-best-practices t1-schema treatment-2: スコア 4.46, トークン 124377, 秒 129.6, チェック 6/7, 開いたファイル supabase-postgres-best-practices t2-review control-1: スコア 4.27, トークン 64780, 秒 65.4, チェック 2/2, 開いたファイルなし t2-review control-2: スコア 3.91, トークン 64695, 秒 71.5, チェック 2/2, 開いたファイルなし t2-review oneliner-1: スコア 3.91, トークン 45381, 秒 57.3, チェック 2/2, 開いたファイルなし
18 実行、3 成果物
サンプル出力
SOTA · With the skill: schema.sql (t1-schema, run 1, Codex)
-- Fresh Supabase database: run once as postgres (trusted BYPASSRLS owner). -- Members manage tenant content; admins also manage settings and memberships. -- service_role bypasses RLS: keep its credentials exclusively on the backend. begin; create schema if not exists private; revoke all on schema private from public, anon; grant usage on schema private to authenticated; -- Keep private out of the Data API's exposed schemas. create table public.organizations ( id uuid primary key default gen_random_uuid(), name text not null check (length(btrim(name)) between 1 and 200), created_at timestamptz not null default now(), updated_at timestamptz not null default now() ); create table public.memberships ( organization_id uuid not null references public.organizations(id) on delete cascade, user_id uuid not null references auth.users(id) on delete cascade, role text not null default 'member' check (role in ('admin', 'member')), created_at timestamptz not null default now(), primary key (organization_id, user_id) ); -- Reverse lookup for the caller's tenants, RLS, and auth user deletion. create index memberships_user_idx on public.memberships (user_id, organization_id) include (role); create table public.projects ( id uuid primary key default gen_random_uuid(), organization_id uuid not null references public.organizations(id) on delete cascade, name text not null check (length(btrim(name)) between 1 and 200), description text not null default '', created_at timestamptz not null default now(), updated_at timestamptz not null default now(), unique (organization_id, id) ); create index projects_list_idx on public.projects (organization_id, created_at desc, id desc); create table public.tasks ( id uuid primary key default gen_random_uuid(), organization_id uuid not null references public.organizations(id) on delete cascade, project_id uuid not null, title text not null check (length(btrim(title)) between 1 and 500), description text not null default '', assignee_id uuid, status text not null default 'todo' check (status in ('todo', 'in_progress', 'done', 'cancelled')), due_date date, created_at timestamptz not null default now(), updated_at timestamptz not null default now(), unique (organization_id, id), foreign key (organization_id, project_id) references public.projects (organization_id, id) on delete cascade, -- Unassign tasks before deleting a membership/auth user. Deferred checking -- permits deleting an entire organization and all its children atomically. foreign key (organization_id, assignee_id) references public.memberships (organization_id, user_id) on delete no action deferrable initially deferred ); create index tasks_project_list_idx on public.tasks (organization_id, project_id, created_at desc, id desc); create index tasks_board_idx on public.tasks (organization_id, project_id, status, created_at desc, id desc); create index tasks_assignee_idx on public.tasks (organization_id, assignee_id, status, due_date, id) where assignee_id is not null; create index tasks_open_due_idx on public.tasks (organization_id, due_date, id) where status in ('todo', 'in_progress') [... excerpt: first 3200 of 11674 characters]