Skip to content

Commit 48f0a08

Browse files
chore: update agent skills and gitignore
Add supabase agent skills, update gitignore to exclude screenshots and playwright artifacts from repo. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
1 parent 8b59c93 commit 48f0a08

12 files changed

Lines changed: 395 additions & 139 deletions

File tree

.agents/skills/supabase-postgres-best-practices/AGENTS.md

Lines changed: 0 additions & 68 deletions
This file was deleted.

.agents/skills/supabase-postgres-best-practices/CLAUDE.md

Lines changed: 0 additions & 68 deletions
This file was deleted.

.agents/skills/supabase-postgres-best-practices/SKILL.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@ description: Postgres performance optimization and best practices from Supabase.
44
license: MIT
55
metadata:
66
author: supabase
7-
version: "1.1.0"
7+
version: "1.1.1"
88
organization: Supabase
99
date: January 2026
1010
abstract: Comprehensive Postgres performance optimization guide for developers using Supabase and Postgres. Contains performance rules across 8 categories, prioritized by impact from critical (query performance, connection management) to incremental (advanced features). Each rule includes detailed explanations, incorrect vs. correct SQL examples, query plan analysis, and specific performance metrics to guide automated optimization and code generation.
@@ -43,7 +43,7 @@ Read individual rule files for detailed explanations and SQL examples:
4343

4444
```
4545
references/query-missing-indexes.md
46-
references/schema-partial-indexes.md
46+
references/query-partial-indexes.md
4747
references/_sections.md
4848
```
4949

Lines changed: 170 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,170 @@
1+
# Writing Guidelines for Postgres References
2+
3+
This document provides guidelines for creating effective Postgres best
4+
practice references that work well with AI agents and LLMs.
5+
6+
## Key Principles
7+
8+
### 1. Concrete Transformation Patterns
9+
10+
Show exact SQL rewrites. Avoid philosophical advice.
11+
12+
**Good:** "Use `WHERE id = ANY(ARRAY[...])` instead of
13+
`WHERE id IN (SELECT ...)`" **Bad:** "Design good schemas"
14+
15+
### 2. Error-First Structure
16+
17+
Always show the problematic pattern first, then the solution. This trains agents
18+
to recognize anti-patterns.
19+
20+
```markdown
21+
**Incorrect (sequential queries):** [bad example]
22+
23+
**Correct (batched query):** [good example]
24+
```
25+
26+
### 3. Quantified Impact
27+
28+
Include specific metrics. Helps agents prioritize fixes.
29+
30+
**Good:** "10x faster queries", "50% smaller index", "Eliminates N+1"
31+
**Bad:** "Faster", "Better", "More efficient"
32+
33+
### 4. Self-Contained Examples
34+
35+
Examples should be complete and runnable (or close to it). Include `CREATE TABLE`
36+
if context is needed.
37+
38+
```sql
39+
-- Include table definition when needed for clarity
40+
CREATE TABLE users (
41+
id bigint PRIMARY KEY,
42+
email text NOT NULL,
43+
deleted_at timestamptz
44+
);
45+
46+
-- Now show the index
47+
CREATE INDEX users_active_email_idx ON users(email) WHERE deleted_at IS NULL;
48+
```
49+
50+
### 5. Semantic Naming
51+
52+
Use meaningful table/column names. Names carry intent for LLMs.
53+
54+
**Good:** `users`, `email`, `created_at`, `is_active`
55+
**Bad:** `table1`, `col1`, `field`, `flag`
56+
57+
---
58+
59+
## Code Example Standards
60+
61+
### SQL Formatting
62+
63+
```sql
64+
-- Use lowercase keywords, clear formatting
65+
CREATE INDEX CONCURRENTLY users_email_idx
66+
ON users(email)
67+
WHERE deleted_at IS NULL;
68+
69+
-- Not cramped or ALL CAPS
70+
CREATE INDEX CONCURRENTLY USERS_EMAIL_IDX ON USERS(EMAIL) WHERE DELETED_AT IS NULL;
71+
```
72+
73+
### Comments
74+
75+
- Explain _why_, not _what_
76+
- Highlight performance implications
77+
- Point out common pitfalls
78+
79+
### Language Tags
80+
81+
- `sql` - Standard SQL queries
82+
- `plpgsql` - Stored procedures/functions
83+
- `typescript` - Application code (when needed)
84+
- `python` - Application code (when needed)
85+
86+
---
87+
88+
## When to Include Application Code
89+
90+
**Default: SQL Only**
91+
92+
Most references should focus on pure SQL patterns. This keeps examples portable.
93+
94+
**Include Application Code When:**
95+
96+
- Connection pooling configuration
97+
- Transaction management in application context
98+
- ORM anti-patterns (N+1 in Prisma/TypeORM)
99+
- Prepared statement usage
100+
101+
**Format for Mixed Examples:**
102+
103+
````markdown
104+
**Incorrect (N+1 in application):**
105+
106+
```typescript
107+
for (const user of users) {
108+
const posts = await db.query("SELECT * FROM posts WHERE user_id = $1", [
109+
user.id,
110+
]);
111+
}
112+
```
113+
````
114+
115+
**Correct (batch query):**
116+
117+
```typescript
118+
const posts = await db.query("SELECT * FROM posts WHERE user_id = ANY($1)", [
119+
userIds,
120+
]);
121+
```
122+
123+
---
124+
125+
## Impact Level Guidelines
126+
127+
| Level | Improvement | Use When |
128+
|-------|-------------|----------|
129+
| **CRITICAL** | 10-100x | Missing indexes, connection exhaustion, sequential scans on large tables |
130+
| **HIGH** | 5-20x | Wrong index types, poor partitioning, missing covering indexes |
131+
| **MEDIUM-HIGH** | 2-5x | N+1 queries, inefficient pagination, RLS optimization |
132+
| **MEDIUM** | 1.5-3x | Redundant indexes, query plan instability |
133+
| **LOW-MEDIUM** | 1.2-2x | VACUUM tuning, configuration tweaks |
134+
| **LOW** | Incremental | Advanced patterns, edge cases |
135+
136+
---
137+
138+
## Reference Standards
139+
140+
**Primary Sources:**
141+
142+
- Official Postgres documentation
143+
- Supabase documentation
144+
- Postgres wiki
145+
- Established blogs (2ndQuadrant, Crunchy Data)
146+
147+
**Format:**
148+
149+
```markdown
150+
Reference:
151+
[Postgres Indexes](https://www.postgresql.org/docs/current/indexes.html)
152+
```
153+
154+
---
155+
156+
## Review Checklist
157+
158+
Before submitting a reference:
159+
160+
- [ ] Title is clear and action-oriented
161+
- [ ] Impact level matches the performance gain
162+
- [ ] impactDescription includes quantification
163+
- [ ] Explanation is concise (1-2 sentences)
164+
- [ ] Has at least 1 **Incorrect** SQL example
165+
- [ ] Has at least 1 **Correct** SQL example
166+
- [ ] SQL uses semantic naming
167+
- [ ] Comments explain _why_, not _what_
168+
- [ ] Trade-offs mentioned if applicable
169+
- [ ] Reference links included
170+
- [ ] `mise run test` passes
Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,39 @@
1+
# Section Definitions
2+
3+
This file defines the rule categories for Postgres best practices. Rules are automatically assigned to sections based on their filename prefix.
4+
5+
Take the examples below as pure demonstrative. Replace each section with the actual rule categories for Postgres best practices.
6+
7+
---
8+
9+
## 1. Query Performance (query)
10+
**Impact:** CRITICAL
11+
**Description:** Slow queries, missing indexes, inefficient query plans. The most common source of Postgres performance issues.
12+
13+
## 2. Connection Management (conn)
14+
**Impact:** CRITICAL
15+
**Description:** Connection pooling, limits, and serverless strategies. Critical for applications with high concurrency or serverless deployments.
16+
17+
## 3. Security & RLS (security)
18+
**Impact:** CRITICAL
19+
**Description:** Row-Level Security policies, privilege management, and authentication patterns.
20+
21+
## 4. Schema Design (schema)
22+
**Impact:** HIGH
23+
**Description:** Table design, index strategies, partitioning, and data type selection. Foundation for long-term performance.
24+
25+
## 5. Concurrency & Locking (lock)
26+
**Impact:** MEDIUM-HIGH
27+
**Description:** Transaction management, isolation levels, deadlock prevention, and lock contention patterns.
28+
29+
## 6. Data Access Patterns (data)
30+
**Impact:** MEDIUM
31+
**Description:** N+1 query elimination, batch operations, cursor-based pagination, and efficient data fetching.
32+
33+
## 7. Monitoring & Diagnostics (monitor)
34+
**Impact:** LOW-MEDIUM
35+
**Description:** Using pg_stat_statements, EXPLAIN ANALYZE, metrics collection, and performance diagnostics.
36+
37+
## 8. Advanced Features (advanced)
38+
**Impact:** LOW
39+
**Description:** Full-text search, JSONB optimization, PostGIS, extensions, and advanced Postgres features.

0 commit comments

Comments
 (0)