supabase

Supabase データベース操作

Supabase でデータベース操作を実行します。クエリ、書き込み、マイグレーション、診断に対応しています。

MCP は任意です。 このスキルは MCP（自動）、Supabase CLI、psql、または Dashboard で動作します。実行方法については BACKENDS.md を参照してください。

対象範囲

対象：

• Supabase のデータベース操作：クエリ／統計／エクスポート、書き込み（確認後）、マイグレーション（DDL）、型生成、クエリログ／アドバイザー

対象外：

• プロジェクト側の統合（環境変数／クライアントコード／データアクセスレイヤー）
  → プロジェクトのセットアップには workflow-ship-faster（Step 6）を使用してください。このスキルは DB 側の操作のみを扱います。

呼び出し元：

• workflow-ship-faster は、このスキルを DB 操作の基盤として使用します。

Postgres のベストプラクティス（組み込み）

Ship Faster では、Supabase の Postgres のベストプラクティスを references/postgres-best-practices/ 配下にベンダー提供の資料として収録しています。

次の場合に参照してください。

• SQL クエリの作成／レビュー／最適化
• インデックス、スキーマ変更、RLS ポリシーの設計
• パフォーマンス、ロック、接続の問題の診断

信頼できる情報源：

• ガイド全文：references/postgres-best-practices/AGENTS.md
• 個別ルール：references/postgres-best-practices/rules/*.md

変更を提案する場合は、該当するルールファイルのパス（例：references/postgres-best-practices/rules/query-missing-indexes.md）を示し、変更は最小限にしてください。

セキュリティルール（必須）

1. 最初に読み取る：操作の前に必ずスキーマを確認してください
2. デフォルトの LIMIT は 50：ユーザーが明示的により多くの件数を要求しない限り、すべての SELECT クエリにデフォルトで LIMIT 50 を指定してください
3. 書き込み操作の確認：INSERT／UPDATE／DELETE は実行前に以下を行ってください。
   • 実行する SQL を表示する
   • 影響を受ける行数の予測を示す
   • ユーザーの明示的な確認を待つ
4. 条件のない書き込みは禁止：WHERE 条件のない UPDATE／DELETE は即座に拒否し、実行しないでください
5. 一括操作のしきい値：100 行を超える行に影響する場合は、必ず二重確認を求め、先に SELECT count(*) を実行するよう提案してください
6. DDL はマイグレーション経由：スキーマの変更には直接 DDL を実行せず、マイグレーションを使用してください
7. 本番環境：書き込みはデフォルトで無効です。ユーザーが「execute on prod」と明示し、さらに二重確認した場合にのみ許可してください
8. 機密フィールド：ユーザーが明示的に要求しない限り、email／phone／token／password はデフォルトでマスキングするか、返却しないでください

操作フロー

1. Parse requirements → restate objective
2. Unsure about tables/fields → first query schema (information_schema or list_tables)
3. Plan SQL → present to user
4. Read-only → execute directly
5. Write operation → confirm before execution → verify affected rows → report result

ファイルベースのパイプライン

複数ステップのワークフローに統合する場合は、成果物をディスクに保存してください。

runs/<workflow>/active/<run_id>/
├── proposal.md                # Requirements / objective
├── context.json               # Known tables/fields/IDs
├── tasks.md                   # Checklist + approval gate
├── evidence/sql.md            # SQL to execute (write ops written here first)
├── evidence/result.md         # Conclusion + SQL + results
└── logs/events.jsonl          # Optional tool call summary (no sensitive data)

出力形式

• 言語：英語
• 構成：結論 → 主要な数値 → 実行した SQL → 結果テーブル（最大 50 行）
• 超過時の処理：切り詰め、総件数を表示し、必要に応じてエクスポート／ページネーションを提供

例：

✅ Query complete: 142 new users in the last 7 days

Executed SQL:
SELECT DATE(created_at) as date, COUNT(*) as count 
FROM user_profiles 
WHERE created_at > NOW() - INTERVAL '7 days'
GROUP BY DATE(created_at) ORDER BY date DESC;

| date       | count |
|------------|-------|
| 2025-01-09 | 23    |
| 2025-01-08 | 31    |
| ...        | ...   |

エラー処理

状況	対応
SQL 構文エラー	エラーの概要と修正案を返す
権限不足	必要な権限と代替手段を説明する
データが返されない	考えられる理由を説明する（条件が厳しすぎる？ データが存在しない？）
RLS によるブロック	RLS ポリシーの確認、または service_role の使用を提案する

ワークフローの例

読み取り：シンプルなクエリ

User: Get registered user count for the last 7 days, by day

1. Confirm table user_profiles, field created_at
2. Execute aggregation SQL
3. Return: conclusion + numbers + SQL + table

読み取り：複雑なクエリ

User: Find projects that have runs but all failed

1. Confirm projects, runs tables and status field
2. Present JOIN + aggregation SQL
3. Execute and return results (mask email)

書き込み：挿入

User: Create a new run for project xxx

1. First check if project exists
2. Present INSERT SQL + expected impact: 1 row
3. Await confirmation → execute → return new record id

書き込み：更新

User: Change run abc's status to completed

1. First SELECT to verify current state
2. Present UPDATE SQL + WHERE id = 'abc'
3. Confirm → execute → SELECT again to verify

危険な操作：削除

User: Delete all runs where status = 'failed'

1. First SELECT count(*) WHERE status = 'failed'
2. Present count + DELETE SQL
3. If > 100 rows, force double confirmation
4. After confirmation execute → report deleted row count

危険な操作：WHERE 条件のない DELETE

User: Clear the runs table

❌ Refuse to execute
→ Prompt: DELETE without WHERE condition, this will delete all data
→ Suggest: Use TRUNCATE (requires migration) or add explicit condition

スキーマの確認

実行時に最新のスキーマを取得します。

-- List all tables
SELECT table_name FROM information_schema.tables 
WHERE table_schema = 'public';

-- View table structure
SELECT column_name, data_type, is_nullable 
FROM information_schema.columns 
WHERE table_name = '<table_name>';

プロジェクト固有のスキーマ（古くなっている可能性があります）については、schema.md を参照してください。

関連ファイル

• BACKENDS.md — 実行方法（MCP／CLI／コンソール）
• SETUP.md — MCP の設定（任意）
• schema.md — プロジェクト固有のスキーマリファレンス