port-nuker 1.0.0 → 1.0.3

package/.agent/skills/skills/postgres-best-practices/README.md

@@ -1,119 +0,0 @@
-# Postgres Best Practices - Contributor Guide
-
-This repository contains Postgres performance optimization rules optimized for
-AI agents and LLMs.
-
-## Quick Start
-
-```bash
-# Install dependencies
-cd packages/postgres-best-practices-build
-npm install
-
-# Validate existing rules
-npm run validate
-
-# Build AGENTS.md
-npm run build
-```
-
-## Creating a New Rule
-
-1. **Choose a section prefix** based on the category:
-   - `query-` Query Performance (CRITICAL)
-   - `conn-` Connection Management (CRITICAL)
-   - `security-` Security & RLS (CRITICAL)
-   - `schema-` Schema Design (HIGH)
-   - `lock-` Concurrency & Locking (MEDIUM-HIGH)
-   - `data-` Data Access Patterns (MEDIUM)
-   - `monitor-` Monitoring & Diagnostics (LOW-MEDIUM)
-   - `advanced-` Advanced Features (LOW)
-
-2. **Copy the template**:
-   ```bash
-   cp rules/_template.md rules/query-your-rule-name.md
-   ```
-
-3. **Fill in the content** following the template structure
-
-4. **Validate and build**:
-   ```bash
-   npm run validate
-   npm run build
-   ```
-
-5. **Review** the generated `AGENTS.md`
-
-## Repository Structure
-
-```
-skills/postgres-best-practices/
-├── SKILL.md           # Agent-facing skill manifest
-├── AGENTS.md          # [GENERATED] Compiled rules document
-├── README.md          # This file
-├── metadata.json      # Version and metadata
-└── rules/
-    ├── _template.md      # Rule template
-    ├── _sections.md      # Section definitions
-    ├── _contributing.md  # Writing guidelines
-    └── *.md              # Individual rules
-
-packages/postgres-best-practices-build/
-├── src/               # Build system source
-├── package.json       # NPM scripts
-└── test-cases.json    # [GENERATED] Test artifacts
-```
-
-## Rule File Structure
-
-See `rules/_template.md` for the complete template. Key elements:
-
-````markdown
----
-title: Clear, Action-Oriented Title
-impact: CRITICAL|HIGH|MEDIUM-HIGH|MEDIUM|LOW-MEDIUM|LOW
-impactDescription: Quantified benefit (e.g., "10-100x faster")
-tags: relevant, keywords
----
-
-## [Title]
-
-[1-2 sentence explanation]
-
-**Incorrect (description):**
-
-```sql
--- Comment explaining what's wrong
-[Bad SQL example]
-```
-````
-
-**Correct (description):**
-
-```sql
--- Comment explaining why this is better
-[Good SQL example]
-```
-
-```
-## Writing Guidelines
-
-See `rules/_contributing.md` for detailed guidelines. Key principles:
-
-1. **Show concrete transformations** - "Change X to Y", not abstract advice
-2. **Error-first structure** - Show the problem before the solution
-3. **Quantify impact** - Include specific metrics (10x faster, 50% smaller)
-4. **Self-contained examples** - Complete, runnable SQL
-5. **Semantic naming** - Use meaningful names (users, email), not (table1, col1)
-
-## Impact Levels
-
-| Level | Improvement | Examples |
-|-------|-------------|----------|
-| CRITICAL | 10-100x | Missing indexes, connection exhaustion |
-| HIGH | 5-20x | Wrong index types, poor partitioning |
-| MEDIUM-HIGH | 2-5x | N+1 queries, RLS optimization |
-| MEDIUM | 1.5-3x | Redundant indexes, stale statistics |
-| LOW-MEDIUM | 1.2-2x | VACUUM tuning, config tweaks |
-| LOW | Incremental | Advanced patterns, edge cases |
-```

package/.agent/skills/skills/postgres-best-practices/SKILL.md

@@ -1,57 +0,0 @@
----
-name: supabase-postgres-best-practices
-description: Postgres performance optimization and best practices from Supabase. Use this skill when writing, reviewing, or optimizing Postgres queries, schema designs, or database configurations.
-license: MIT
-metadata:
-  author: supabase
-  version: "1.0.0"
----
-
-# Supabase Postgres Best Practices
-
-Comprehensive performance optimization guide for Postgres, maintained by Supabase. Contains rules across 8 categories, prioritized by impact to guide automated query optimization and schema design.
-
-## When to Apply
-
-Reference these guidelines when:
-- Writing SQL queries or designing schemas
-- Implementing indexes or query optimization
-- Reviewing database performance issues
-- Configuring connection pooling or scaling
-- Optimizing for Postgres-specific features
-- Working with Row-Level Security (RLS)
-
-## Rule Categories by Priority
-
-| Priority | Category | Impact | Prefix |
-|----------|----------|--------|--------|
-| 1 | Query Performance | CRITICAL | `query-` |
-| 2 | Connection Management | CRITICAL | `conn-` |
-| 3 | Security & RLS | CRITICAL | `security-` |
-| 4 | Schema Design | HIGH | `schema-` |
-| 5 | Concurrency & Locking | MEDIUM-HIGH | `lock-` |
-| 6 | Data Access Patterns | MEDIUM | `data-` |
-| 7 | Monitoring & Diagnostics | LOW-MEDIUM | `monitor-` |
-| 8 | Advanced Features | LOW | `advanced-` |
-
-## How to Use
-
-Read individual rule files for detailed explanations and SQL examples:
-
-```
-rules/query-missing-indexes.md
-rules/schema-partial-indexes.md
-rules/_sections.md
-```
-
-Each rule file contains:
-- Brief explanation of why it matters
-- Incorrect SQL example with explanation
-- Correct SQL example with explanation
-- Optional EXPLAIN output or metrics
-- Additional context and references
-- Supabase-specific notes (when applicable)
-
-## Full Compiled Document
-
-For the complete guide with all rules expanded: `AGENTS.md`

package/.agent/skills/skills/postgres-best-practices/metadata.json

@@ -1,13 +0,0 @@
-{
-	"version": "1.0.0",
-	"organization": "Supabase",
-	"date": "January 2026",
-	"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.",
-	"references": [
-		"https://www.postgresql.org/docs/current/",
-		"https://supabase.com/docs",
-		"https://wiki.postgresql.org/wiki/Performance_Optimization",
-		"https://supabase.com/docs/guides/database/overview",
-		"https://supabase.com/docs/guides/auth/row-level-security"
-	]
-}

package/.agent/skills/skills/postgres-best-practices/rules/_contributing.md

@@ -1,171 +0,0 @@
-# Writing Guidelines for Postgres Rules
-
-This document provides guidelines for creating effective Postgres best
-practice rules that work well with AI agents and LLMs.
-
-## Key Principles
-
-### 1. Concrete Transformation Patterns
-
-Show exact SQL rewrites. Avoid philosophical advice.
-
-**Good:** "Use `WHERE id = ANY(ARRAY[...])` instead of
-`WHERE id IN (SELECT ...)`" **Bad:** "Design good schemas"
-
-### 2. Error-First Structure
-
-Always show the problematic pattern first, then the solution. This trains agents
-to recognize anti-patterns.
-
-```markdown
-**Incorrect (sequential queries):** [bad example]
-
-**Correct (batched query):** [good example]
-```
-
-### 3. Quantified Impact
-
-Include specific metrics. Helps agents prioritize fixes.
-
-**Good:** "10x faster queries", "50% smaller index", "Eliminates N+1" 
-**Bad:** "Faster", "Better", "More efficient"
-
-### 4. Self-Contained Examples
-
-Examples should be complete and runnable (or close to it). Include `CREATE TABLE`
-if context is needed.
-
-```sql
--- Include table definition when needed for clarity
-CREATE TABLE users (
-  id bigint PRIMARY KEY,
-  email text NOT NULL,
-  deleted_at timestamptz
-);
-
--- Now show the index
-CREATE INDEX users_active_email_idx ON users(email) WHERE deleted_at IS NULL;
-```
-
-### 5. Semantic Naming
-
-Use meaningful table/column names. Names carry intent for LLMs.
-
-**Good:** `users`, `email`, `created_at`, `is_active`
-**Bad:** `table1`, `col1`, `field`, `flag`
-
----
-
-## Code Example Standards
-
-### SQL Formatting
-
-```sql
--- Use lowercase keywords, clear formatting
-CREATE INDEX CONCURRENTLY users_email_idx
-  ON users(email)
-  WHERE deleted_at IS NULL;
-
--- Not cramped or ALL CAPS
-CREATE INDEX CONCURRENTLY USERS_EMAIL_IDX ON USERS(EMAIL) WHERE DELETED_AT IS NULL;
-```
-
-### Comments
-
-- Explain _why_, not _what_
-- Highlight performance implications
-- Point out common pitfalls
-
-### Language Tags
-
-- `sql` - Standard SQL queries
-- `plpgsql` - Stored procedures/functions
-- `typescript` - Application code (when needed)
-- `python` - Application code (when needed)
-
----
-
-## When to Include Application Code
-
-**Default: SQL Only**
-
-Most rules should focus on pure SQL patterns. This keeps examples portable.
-
-**Include Application Code When:**
-
-- Connection pooling configuration
-- Transaction management in application context
-- ORM anti-patterns (N+1 in Prisma/TypeORM)
-- Prepared statement usage
-
-**Format for Mixed Examples:**
-
-````markdown
-**Incorrect (N+1 in application):**
-
-```typescript
-for (const user of users) {
-  const posts = await db.query("SELECT * FROM posts WHERE user_id = $1", [
-    user.id,
-  ]);
-}
-```
-````
-
-**Correct (batch query):**
-
-```typescript
-const posts = await db.query("SELECT * FROM posts WHERE user_id = ANY($1)", [
-  userIds,
-]);
-```
-
----
-
-## Impact Level Guidelines
-
-| Level | Improvement | Use When |
-|-------|-------------|----------|
-| **CRITICAL** | 10-100x | Missing indexes, connection exhaustion, sequential scans on large tables |
-| **HIGH** | 5-20x | Wrong index types, poor partitioning, missing covering indexes |
-| **MEDIUM-HIGH** | 2-5x | N+1 queries, inefficient pagination, RLS optimization |
-| **MEDIUM** | 1.5-3x | Redundant indexes, query plan instability |
-| **LOW-MEDIUM** | 1.2-2x | VACUUM tuning, configuration tweaks |
-| **LOW** | Incremental | Advanced patterns, edge cases |
-
----
-
-## Reference Standards
-
-**Primary Sources:**
-
-- Official Postgres documentation
-- Supabase documentation
-- Postgres wiki
-- Established blogs (2ndQuadrant, Crunchy Data)
-
-**Format:**
-
-```markdown
-Reference:
-[Postgres Indexes](https://www.postgresql.org/docs/current/indexes.html)
-```
-
----
-
-## Review Checklist
-
-Before submitting a rule:
-
-- [ ] Title is clear and action-oriented
-- [ ] Impact level matches the performance gain
-- [ ] impactDescription includes quantification
-- [ ] Explanation is concise (1-2 sentences)
-- [ ] Has at least 1 **Incorrect** SQL example
-- [ ] Has at least 1 **Correct** SQL example
-- [ ] SQL uses semantic naming
-- [ ] Comments explain _why_, not _what_
-- [ ] Trade-offs mentioned if applicable
-- [ ] Reference links included
-- [ ] `npm run validate` passes
-- [ ] `npm run build` generates correct output

package/.agent/skills/skills/postgres-best-practices/rules/_sections.md

@@ -1,39 +0,0 @@
-# Section Definitions
-
-This file defines the rule categories for Postgres best practices. Rules are automatically assigned to sections based on their filename prefix.
-
-Take the examples below as pure demonstrative. Replace each section with the actual rule categories for Postgres best practices.
-
----
-
-## 1. Query Performance (query)
-**Impact:** CRITICAL
-**Description:** Slow queries, missing indexes, inefficient query plans. The most common source of Postgres performance issues.
-
-## 2. Connection Management (conn)
-**Impact:** CRITICAL
-**Description:** Connection pooling, limits, and serverless strategies. Critical for applications with high concurrency or serverless deployments.
-
-## 3. Security & RLS (security)
-**Impact:** CRITICAL
-**Description:** Row-Level Security policies, privilege management, and authentication patterns.
-
-## 4. Schema Design (schema)
-**Impact:** HIGH
-**Description:** Table design, index strategies, partitioning, and data type selection. Foundation for long-term performance.
-
-## 5. Concurrency & Locking (lock)
-**Impact:** MEDIUM-HIGH
-**Description:** Transaction management, isolation levels, deadlock prevention, and lock contention patterns.
-
-## 6. Data Access Patterns (data)
-**Impact:** MEDIUM
-**Description:** N+1 query elimination, batch operations, cursor-based pagination, and efficient data fetching.
-
-## 7. Monitoring & Diagnostics (monitor)
-**Impact:** LOW-MEDIUM
-**Description:** Using pg_stat_statements, EXPLAIN ANALYZE, metrics collection, and performance diagnostics.
-
-## 8. Advanced Features (advanced)
-**Impact:** LOW
-**Description:** Full-text search, JSONB optimization, PostGIS, extensions, and advanced Postgres features.

package/.agent/skills/skills/postgres-best-practices/rules/_template.md

@@ -1,34 +0,0 @@
----
-title: Clear, Action-Oriented Title (e.g., "Use Partial Indexes for Filtered Queries")
-impact: MEDIUM
-impactDescription: 5-20x query speedup for filtered queries
-tags: indexes, query-optimization, performance
----
-
-## [Rule Title]
-
-[1-2 sentence explanation of the problem and why it matters. Focus on performance impact.]
-
-**Incorrect (describe the problem):**
-
-```sql
--- Comment explaining what makes this slow/problematic
-CREATE INDEX users_email_idx ON users(email);
-
-SELECT * FROM users WHERE email = 'user@example.com' AND deleted_at IS NULL;
--- This scans deleted records unnecessarily
-```
-
-**Correct (describe the solution):**
-
-```sql
--- Comment explaining why this is better
-CREATE INDEX users_active_email_idx ON users(email) WHERE deleted_at IS NULL;
-
-SELECT * FROM users WHERE email = 'user@example.com' AND deleted_at IS NULL;
--- Only indexes active users, 10x smaller index, faster queries
-```
-
-[Optional: Additional context, edge cases, or trade-offs]
-
-Reference: [Postgres Docs](https://www.postgresql.org/docs/current/)

package/.agent/skills/skills/postgres-best-practices/rules/advanced-full-text-search.md

@@ -1,55 +0,0 @@
----
-title: Use tsvector for Full-Text Search
-impact: MEDIUM
-impactDescription: 100x faster than LIKE, with ranking support
-tags: full-text-search, tsvector, gin, search
----
-
-## Use tsvector for Full-Text Search
-
-LIKE with wildcards can't use indexes. Full-text search with tsvector is orders of magnitude faster.
-
-**Incorrect (LIKE pattern matching):**
-
-```sql
--- Cannot use index, scans all rows
-select * from articles where content like '%postgresql%';
-
--- Case-insensitive makes it worse
-select * from articles where lower(content) like '%postgresql%';
-```
-
-**Correct (full-text search with tsvector):**
-
-```sql
--- Add tsvector column and index
-alter table articles add column search_vector tsvector
-  generated always as (to_tsvector('english', coalesce(title,'') || ' ' || coalesce(content,''))) stored;
-
-create index articles_search_idx on articles using gin (search_vector);
-
--- Fast full-text search
-select * from articles
-where search_vector @@ to_tsquery('english', 'postgresql & performance');
-
--- With ranking
-select *, ts_rank(search_vector, query) as rank
-from articles, to_tsquery('english', 'postgresql') query
-where search_vector @@ query
-order by rank desc;
-```
-
-Search multiple terms:
-
-```sql
--- AND: both terms required
-to_tsquery('postgresql & performance')
-
--- OR: either term
-to_tsquery('postgresql | mysql')
-
--- Prefix matching
-to_tsquery('post:*')
-```
-
-Reference: [Full Text Search](https://supabase.com/docs/guides/database/full-text-search)

package/.agent/skills/skills/postgres-best-practices/rules/advanced-jsonb-indexing.md

@@ -1,49 +0,0 @@
----
-title: Index JSONB Columns for Efficient Querying
-impact: MEDIUM
-impactDescription: 10-100x faster JSONB queries with proper indexing
-tags: jsonb, gin, indexes, json
----
-
-## Index JSONB Columns for Efficient Querying
-
-JSONB queries without indexes scan the entire table. Use GIN indexes for containment queries.
-
-**Incorrect (no index on JSONB):**
-
-```sql
-create table products (
-  id bigint primary key,
-  attributes jsonb
-);
-
--- Full table scan for every query
-select * from products where attributes @> '{"color": "red"}';
-select * from products where attributes->>'brand' = 'Nike';
-```
-
-**Correct (GIN index for JSONB):**
-
-```sql
--- GIN index for containment operators (@>, ?, ?&, ?|)
-create index products_attrs_gin on products using gin (attributes);
-
--- Now containment queries use the index
-select * from products where attributes @> '{"color": "red"}';
-
--- For specific key lookups, use expression index
-create index products_brand_idx on products ((attributes->>'brand'));
-select * from products where attributes->>'brand' = 'Nike';
-```
-
-Choose the right operator class:
-
-```sql
--- jsonb_ops (default): supports all operators, larger index
-create index idx1 on products using gin (attributes);
-
--- jsonb_path_ops: only @> operator, but 2-3x smaller index
-create index idx2 on products using gin (attributes jsonb_path_ops);
-```
-
-Reference: [JSONB Indexes](https://www.postgresql.org/docs/current/datatype-json.html#JSON-INDEXING)

package/.agent/skills/skills/postgres-best-practices/rules/conn-idle-timeout.md

@@ -1,46 +0,0 @@
----
-title: Configure Idle Connection Timeouts
-impact: HIGH
-impactDescription: Reclaim 30-50% of connection slots from idle clients
-tags: connections, timeout, idle, resource-management
----
-
-## Configure Idle Connection Timeouts
-
-Idle connections waste resources. Configure timeouts to automatically reclaim them.
-
-**Incorrect (connections held indefinitely):**
-
-```sql
--- No timeout configured
-show idle_in_transaction_session_timeout;  -- 0 (disabled)
-
--- Connections stay open forever, even when idle
-select pid, state, state_change, query
-from pg_stat_activity
-where state = 'idle in transaction';
--- Shows transactions idle for hours, holding locks
-```
-
-**Correct (automatic cleanup of idle connections):**
-
-```sql
--- Terminate connections idle in transaction after 30 seconds
-alter system set idle_in_transaction_session_timeout = '30s';
-
--- Terminate completely idle connections after 10 minutes
-alter system set idle_session_timeout = '10min';
-
--- Reload configuration
-select pg_reload_conf();
-```
-
-For pooled connections, configure at the pooler level:
-
-```ini
-# pgbouncer.ini
-server_idle_timeout = 60
-client_idle_timeout = 300
-```
-
-Reference: [Connection Timeouts](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-IDLE-IN-TRANSACTION-SESSION-TIMEOUT)

package/.agent/skills/skills/postgres-best-practices/rules/conn-limits.md

@@ -1,44 +0,0 @@
----
-title: Set Appropriate Connection Limits
-impact: CRITICAL
-impactDescription: Prevent database crashes and memory exhaustion
-tags: connections, max-connections, limits, stability
----
-
-## Set Appropriate Connection Limits
-
-Too many connections exhaust memory and degrade performance. Set limits based on available resources.
-
-**Incorrect (unlimited or excessive connections):**
-
-```sql
--- Default max_connections = 100, but often increased blindly
-show max_connections;  -- 500 (way too high for 4GB RAM)
-
--- Each connection uses 1-3MB RAM
--- 500 connections * 2MB = 1GB just for connections!
--- Out of memory errors under load
-```
-
-**Correct (calculate based on resources):**
-
-```sql
--- Formula: max_connections = (RAM in MB / 5MB per connection) - reserved
--- For 4GB RAM: (4096 / 5) - 10 = ~800 theoretical max
--- But practically, 100-200 is better for query performance
-
--- Recommended settings for 4GB RAM
-alter system set max_connections = 100;
-
--- Also set work_mem appropriately
--- work_mem * max_connections should not exceed 25% of RAM
-alter system set work_mem = '8MB';  -- 8MB * 100 = 800MB max
-```
-
-Monitor connection usage:
-
-```sql
-select count(*), state from pg_stat_activity group by state;
-```
-
-Reference: [Database Connections](https://supabase.com/docs/guides/platform/performance#connection-management)

package/.agent/skills/skills/postgres-best-practices/rules/conn-pooling.md

@@ -1,41 +0,0 @@
----
-title: Use Connection Pooling for All Applications
-impact: CRITICAL
-impactDescription: Handle 10-100x more concurrent users
-tags: connection-pooling, pgbouncer, performance, scalability
----
-
-## Use Connection Pooling for All Applications
-
-Postgres connections are expensive (1-3MB RAM each). Without pooling, applications exhaust connections under load.
-
-**Incorrect (new connection per request):**
-
-```sql
--- Each request creates a new connection
--- Application code: db.connect() per request
--- Result: 500 concurrent users = 500 connections = crashed database
-
--- Check current connections
-select count(*) from pg_stat_activity;  -- 487 connections!
-```
-
-**Correct (connection pooling):**
-
-```sql
--- Use a pooler like PgBouncer between app and database
--- Application connects to pooler, pooler reuses a small pool to Postgres
-
--- Configure pool_size based on: (CPU cores * 2) + spindle_count
--- Example for 4 cores: pool_size = 10
-
--- Result: 500 concurrent users share 10 actual connections
-select count(*) from pg_stat_activity;  -- 10 connections
-```
-
-Pool modes:
-
-- **Transaction mode**: connection returned after each transaction (best for most apps)
-- **Session mode**: connection held for entire session (needed for prepared statements, temp tables)
-
-Reference: [Connection Pooling](https://supabase.com/docs/guides/database/connecting-to-postgres#connection-pooler)