codeforge-dev 1.4.0

package/.devcontainer/plugins/devs-marketplace/plugins/codedirective-skills/skills/skill-building/references/skill-authoring-patterns.md

@@ -0,0 +1,356 @@
+# Skill Authoring Patterns
+
+This reference describes five skill authoring patterns, ordered by complexity. Select the pattern that matches the skill's requirements. Simpler patterns are preferred when they suffice -- complexity should be justified by the task.
+
+---
+
+## Pattern 1: Instruction-Only
+
+### When to Use
+The skill provides knowledge and guidelines without requiring external files, scripts, or templates. Pure procedural knowledge that changes model behavior through instructions alone.
+
+### Characteristics
+- SKILL.md only -- no references/, scripts/, or assets/
+- Typically 800-1,500 words
+- Knowledge the model does not possess by default
+- No deterministic operations required
+
+### Structure
+```
+skill-name/
+└── SKILL.md
+```
+
+### Example: Code Review Standards
+
+```yaml
+---
+name: Code Review Standards
+description: >-
+  This skill should be used when the user asks to "review code",
+  "check this PR", "audit code quality", or discusses code review
+  criteria, review comments, or approval standards.
+version: 0.1.0
+---
+```
+
+```markdown
+# Code Review Standards
+
+This skill establishes code review criteria for consistent, actionable feedback.
+
+## Review Priorities (ordered)
+
+1. **Correctness** -- Does the code do what it claims?
+2. **Security** -- Are there injection, auth, or data exposure risks?
+3. **Maintainability** -- Can another developer understand and modify this?
+4. **Performance** -- Are there obvious inefficiencies? (Do not micro-optimize.)
+
+## Comment Format
+
+Structure every review comment as:
+
+**[Category] File:Line -- Observation**
+> Suggestion with rationale.
+
+Example:
+**[Security] auth.py:42 -- User input passed directly to SQL query**
+> Use parameterized queries to prevent SQL injection. The `execute()`
+> method accepts parameters as a second argument.
+
+## Approval Criteria
+
+Approve when:
+- No correctness or security issues remain
+- All maintainability concerns are either addressed or acknowledged with justification
+- Performance concerns are documented for follow-up if not blocking
+
+Request changes when:
+- Any correctness bug exists
+- Any security vulnerability exists
+- Code is not understandable without the author explaining it verbally
+```
+
+### Guidance
+- Keep it lean. If the body exceeds 1,500 words, consider whether a reference file is warranted, which would promote the skill to Pattern 2.
+- Focus on knowledge the model lacks, not general best practices it already follows.
+- Instruction-Only skills are the easiest to maintain. Prefer this pattern unless the skill genuinely needs external resources.
+
+---
+
+## Pattern 2: Asset Utilization
+
+### When to Use
+The skill requires reference material, documentation, or templates that are too large for the SKILL.md body, or that change independently from the core instructions.
+
+### Characteristics
+- SKILL.md + references/ and/or assets/
+- SKILL.md stays lean (1,500-2,000 words), detail lives in references/
+- Reference material loaded on demand, not on every activation
+- Assets used in output but not loaded into context
+
+### Structure
+```
+skill-name/
+├── SKILL.md
+├── references/
+│   ├── api-schema.md
+│   └── domain-glossary.md
+└── assets/
+    └── template/
+        ├── index.html
+        └── styles.css
+```
+
+### Example: API Integration Skill
+
+**SKILL.md** contains core workflow (authenticate, construct request, handle response) and a table pointing to reference files:
+
+```markdown
+## API Reference
+
+| Endpoint Group | Reference File | Search Pattern |
+|---|---|---|
+| User management | `references/api-users.md` | "POST /users" |
+| Billing | `references/api-billing.md` | "GET /invoices" |
+| Webhooks | `references/api-webhooks.md` | "Event: payment." |
+```
+
+### Guidance
+- Include search patterns for large reference files (>5,000 words) so the model can grep for specific sections.
+- Avoid duplicating reference content in SKILL.md. Summarize and point.
+- Assets are not loaded into context -- they are copied or modified during output generation. Include a manifest or description of assets in SKILL.md so the model knows what is available.
+
+---
+
+## Pattern 3: Few-Shot
+
+### When to Use
+The output format, style, or structure is critical and cannot be reliably specified through rules alone. The model needs to see concrete input-output examples to calibrate.
+
+### Characteristics
+- SKILL.md contains 2-5 high-quality input-output examples
+- Examples demonstrate the full range of expected behaviors
+- Each example illustrates a distinct aspect (not redundant variations)
+- May combine with other patterns (e.g., Few-Shot + Asset Utilization)
+
+### Structure
+```
+skill-name/
+├── SKILL.md          # Contains inline examples
+└── references/
+    └── examples.md   # Additional examples if needed
+```
+
+### Example: Changelog Generator
+
+````markdown
+## Examples
+
+### Example 1: Feature Addition
+
+**Input (commit log):**
+```
+feat(auth): add OAuth2 PKCE flow for mobile clients
+feat(auth): add refresh token rotation
+fix(auth): handle expired tokens during active session
+```
+
+**Output (changelog entry):**
+```markdown
+### Authentication
+- **Added** OAuth2 PKCE flow for mobile clients, enabling secure
+  authentication without client secrets
+- **Added** Refresh token rotation to prevent token replay attacks
+- **Fixed** Expired token handling during active sessions -- users
+  are now seamlessly re-authenticated instead of logged out
+```
+
+### Example 2: Breaking Change
+
+**Input (commit log):**
+```
+feat(api)!: change response envelope from {data} to {result, meta}
+migration(api): add v1-to-v2 response adapter
+docs(api): update API migration guide
+```
+
+**Output (changelog entry):**
+```markdown
+### API (Breaking)
+- **Changed** Response envelope from `{data}` to `{result, meta}`.
+  See migration guide for adapter utilities.
+  **Migration:** Use `v1-to-v2` adapter for backward compatibility.
+```
+````
+
+### Guidance
+- Each example should teach something the others do not. Example 1 shows standard features; Example 2 shows breaking changes. Redundant examples waste tokens.
+- Place the 2-3 most important examples in SKILL.md. Move additional examples to `references/examples.md` if more are needed.
+- Include edge cases in examples: empty inputs, ambiguous inputs, error cases.
+- Few-shot is the most reliable way to enforce output format. Rules like "use bold for action verbs" are less reliably followed than examples that demonstrate the format.
+
+---
+
+## Pattern 4: Procedural Logic
+
+### When to Use
+The skill involves a multi-step deterministic workflow where steps must execute in order and some steps benefit from being implemented as scripts rather than generated each time.
+
+### Characteristics
+- SKILL.md defines the workflow and step ordering
+- scripts/ contains deterministic steps
+- The model orchestrates: deciding when to invoke scripts and handling branching logic
+- References may supplement with documentation
+
+### Structure
+```
+skill-name/
+├── SKILL.md
+├── scripts/
+│   ├── validate-input.sh
+│   ├── transform-data.py
+│   └── generate-report.py
+├── references/
+│   └── format-specification.md
+└── assets/
+    └── report-template.html
+```
+
+### Example: Data Pipeline Skill
+
+**SKILL.md** defines the workflow:
+
+```markdown
+## Workflow
+
+Execute these steps in order:
+
+1. **Validate Input**
+   Run `scripts/validate-input.sh <file>` to verify format and schema.
+   If validation fails, report errors to the user and stop.
+
+2. **Transform Data**
+   Run `scripts/transform-data.py --input <file> --output <temp>`.
+   The script normalizes date formats, deduplicates records, and
+   applies business rules defined in `references/format-specification.md`.
+
+3. **Review Transformation**
+   Read the transformation summary from stdout. Present key statistics
+   to the user: records processed, duplicates removed, format corrections.
+   Await confirmation before proceeding.
+
+4. **Generate Report**
+   Run `scripts/generate-report.py --data <temp> --template assets/report-template.html`.
+   Output the report path to the user.
+
+## Error Recovery
+
+- **Validation failure:** Present the specific validation errors. Suggest corrections. Offer to auto-fix common issues (date formats, encoding).
+- **Transformation failure:** Read the error log. Diagnose whether the issue is data quality or script bug. For data quality issues, present options to the user.
+- **Report failure:** Fall back to plain-text summary if template rendering fails.
+```
+
+### Guidance
+- Scripts should be self-contained and testable independently. Each script handles one step.
+- The model's role is orchestration: deciding branching, handling errors, presenting results. Keep deterministic logic in scripts.
+- Document each script's inputs, outputs, and exit codes in SKILL.md so the model can invoke them correctly.
+- Include error recovery for each step. Multi-step workflows fail at steps, and the model needs to know how to recover.
+
+---
+
+## Pattern 5: Complex Orchestration
+
+### When to Use
+The skill coordinates multiple tools, external services, or sub-workflows with conditional branching, parallel execution, or state management across steps.
+
+### Characteristics
+- Multiple scripts and reference files working together
+- Conditional branching based on intermediate results
+- May involve external tool calls (APIs, databases, file systems)
+- State management across steps
+- Comprehensive error handling and rollback
+
+### Structure
+```
+skill-name/
+├── SKILL.md
+├── scripts/
+│   ├── discover-environment.sh
+│   ├── run-analysis.py
+│   ├── apply-changes.py
+│   └── verify-results.sh
+├── references/
+│   ├── architecture.md
+│   ├── rollback-procedures.md
+│   └── environment-matrix.md
+└── assets/
+    └── config-templates/
+        ├── production.yaml
+        └── staging.yaml
+```
+
+### Example: Deployment Skill
+
+**SKILL.md** defines the orchestration:
+
+```markdown
+## Deployment Workflow
+
+### Phase 1: Environment Discovery
+Run `scripts/discover-environment.sh` to detect:
+- Current branch and latest commit
+- Target environment (from user input or branch convention)
+- Required configuration (from `references/environment-matrix.md`)
+
+### Phase 2: Pre-flight Checks
+Execute in sequence:
+1. Verify all tests pass in CI (check GitHub Actions status)
+2. Run `scripts/run-analysis.py --type security` for vulnerability scan
+3. Run `scripts/run-analysis.py --type compatibility` for breaking change detection
+
+**Branch on results:**
+- All checks pass: proceed to Phase 3
+- Security issues found: present findings, await user decision (fix/accept/abort)
+- Breaking changes detected: present migration requirements, await approval
+
+### Phase 3: Deployment
+1. Select configuration template from `assets/config-templates/`
+2. Run `scripts/apply-changes.py --env <target> --config <template>`
+3. Monitor deployment output for errors
+
+### Phase 4: Verification
+1. Run `scripts/verify-results.sh --env <target>`
+2. Present health check results
+3. If verification fails, consult `references/rollback-procedures.md` and present rollback options
+
+## State Management
+Track deployment state across phases. If interrupted:
+- Phase 1-2: Safe to restart from beginning
+- Phase 3: Check partial deployment state before retrying
+- Phase 4: Do not re-deploy; verify current state first
+
+## Rollback Policy
+Consult `references/rollback-procedures.md` for environment-specific rollback procedures. Present the rollback plan to the user before executing.
+```
+
+### Guidance
+- Complex Orchestration skills are the hardest to maintain. Use this pattern only when the workflow genuinely requires it. Many workflows that seem complex can be decomposed into multiple simpler skills.
+- Define state management explicitly. The model needs to know what happens when the workflow is interrupted at each phase.
+- Include rollback procedures for destructive operations.
+- Test the full workflow end-to-end, not just individual scripts.
+- Consider whether the skill should be split into multiple skills (one per phase) that compose together. Composition often produces better results than monolithic orchestration.
+
+---
+
+## Pattern Selection Guide
+
+| Question | If Yes | If No |
+|---|---|---|
+| Does the skill need external files? | Pattern 2+ | Pattern 1 |
+| Is output format critical? | Pattern 3 | Continue |
+| Are there multi-step deterministic operations? | Pattern 4 | Continue |
+| Are there conditional branches or state management? | Pattern 5 | Continue |
+| Is the scope well-defined and narrow? | Selected pattern is appropriate | Split into multiple skills |
+
+**Default to the simplest pattern that covers the requirements.** Escalate only when a simpler pattern demonstrably fails to capture the skill's needs.

package/.devcontainer/plugins/devs-marketplace/plugins/codedirective-skills/skills/sqlite/SKILL.md

@@ -0,0 +1,329 @@
+---
+name: sqlite
+description: >-
+  This skill should be used when the user asks to "set up a SQLite database",
+  "use WAL mode in SQLite", "query SQLite with Python", "use better-sqlite3",
+  "add full-text search with FTS5", "store JSON in SQLite",
+  "use SQLite with Cloudflare D1", "write CTEs or window functions in SQLite",
+  or discusses SQLite pragmas, schema design, JSON1 extension, FTS5,
+  aiosqlite, or embedded database patterns.
+version: 0.1.0
+---
+
+# SQLite Development
+
+## Mental Model
+
+SQLite is an **embedded database engine**, not a client-server system. The entire database lives in a single file (or `:memory:`), linked directly into the application process. There is no network protocol, no connection pooling daemon, and no separate service to manage.
+
+This architecture gives SQLite properties that eliminate external infrastructure: ACID transactions without a database server, full-text search without Elasticsearch, JSON querying without a document store, and concurrent reads without connection pool tuning. The tradeoff is a single-writer model -- only one connection can write at a time, though WAL mode allows concurrent reads during writes.
+
+SQLite supports these built-in extensions that replace external services:
+- **JSON1** -- query and index JSON columns without a document database
+- **FTS5** -- full-text search with ranking without a search engine
+- **R-Tree** -- spatial indexing without PostGIS
+
+Assume SQLite 3.35+ (2021) for all new code, which includes `RETURNING`, `INSERT ... ON CONFLICT`, and `STRICT` tables.
+
+---
+
+## Core Configuration
+
+Apply these PRAGMAs at connection startup. They control durability, concurrency, and correctness:
+
+```sql
+PRAGMA journal_mode = WAL;          -- concurrent readers, non-blocking writes
+PRAGMA foreign_keys = ON;           -- enforce foreign key constraints
+PRAGMA busy_timeout = 5000;         -- wait 5s on lock instead of failing immediately
+PRAGMA synchronous = NORMAL;        -- safe with WAL, faster than FULL
+PRAGMA cache_size = -64000;         -- 64MB page cache (negative = KB)
+PRAGMA temp_store = MEMORY;         -- temp tables in RAM
+```
+
+**WAL (Write-Ahead Log)** replaces the default rollback journal with an append-only log. Readers see a consistent snapshot while a writer appends to the log. This eliminates read-write contention for most workloads. WAL persists across connections -- set it once per database, not per connection.
+
+`foreign_keys` must be enabled per connection; it does not persist in the database file.
+
+> **Deep dive:** See `references/schema-and-pragmas.md` for all recommended PRAGMAs with rationale, WAL internals, checkpointing, and FTS5 tokenizer configuration.
+
+---
+
+## Schema Design
+
+### Tables and Types
+
+Use `STRICT` tables for new schemas to enforce type checking at the engine level. Without `STRICT`, SQLite uses type affinity -- a column declared `INTEGER` happily stores text:
+
+```sql
+CREATE TABLE users (
+    id INTEGER PRIMARY KEY,          -- alias for rowid, auto-increment
+    email TEXT NOT NULL UNIQUE,
+    display_name TEXT,
+    created_at TEXT NOT NULL DEFAULT (strftime('%Y-%m-%dT%H:%M:%fZ', 'now')),
+    metadata TEXT                     -- JSON stored as text
+) STRICT;
+```
+
+`INTEGER PRIMARY KEY` is an alias for SQLite's internal `rowid`, giving maximum performance for lookups by primary key.
+
+### WITHOUT ROWID
+
+For tables where the primary key is not a single integer (composite keys, text keys), `WITHOUT ROWID` stores rows in primary-key order, eliminating the separate rowid lookup:
+
+```sql
+CREATE TABLE user_roles (
+    user_id INTEGER NOT NULL REFERENCES users(id),
+    role TEXT NOT NULL,
+    PRIMARY KEY (user_id, role)
+) WITHOUT ROWID, STRICT;
+```
+
+### CHECK Constraints
+
+```sql
+CREATE TABLE products (
+    id INTEGER PRIMARY KEY,
+    price REAL NOT NULL CHECK (price > 0),
+    status TEXT NOT NULL CHECK (status IN ('active', 'archived', 'draft'))
+) STRICT;
+```
+
+---
+
+## Parameterized Queries
+
+Always use parameter binding. Never interpolate values into SQL strings -- this prevents SQL injection and allows SQLite to cache prepared statements.
+
+**Python:**
+```python
+cursor.execute("SELECT * FROM users WHERE email = ?", (email,))
+cursor.execute("INSERT INTO users (email, name) VALUES (:email, :name)",
+               {"email": email, "name": name})
+```
+
+**JavaScript (better-sqlite3):**
+```javascript
+const user = db.prepare("SELECT * FROM users WHERE email = ?").get(email);
+const insert = db.prepare("INSERT INTO users (email, name) VALUES (@email, @name)");
+insert.run({ email, name });
+```
+
+`?` placeholders bind by position. Named placeholders (`:name` in Python, `@name` or `$name` in better-sqlite3) bind by key from a dict/object. Named placeholders are clearer for queries with many parameters.
+
+---
+
+## JSON Support (JSON1)
+
+SQLite stores JSON as text but provides functions to query, extract, and index JSON values without parsing in application code.
+
+### Extraction and Querying
+
+```sql
+-- Extract a scalar value
+SELECT json_extract(metadata, '$.theme') FROM users;
+
+-- Arrow operators (SQLite 3.38+)
+SELECT metadata->>'$.theme' FROM users;
+
+-- Iterate over a JSON array
+SELECT u.email, tag.value
+FROM users u, json_each(u.metadata, '$.tags') AS tag;
+
+-- Aggregate into a JSON array
+SELECT json_group_array(json_object('id', id, 'email', email))
+FROM users;
+```
+
+### Indexing JSON Fields
+
+Create a generated column to index a JSON path, enabling indexed lookups on JSON values:
+
+```sql
+ALTER TABLE users ADD COLUMN theme TEXT
+    GENERATED ALWAYS AS (json_extract(metadata, '$.theme')) STORED;
+
+CREATE INDEX idx_users_theme ON users(theme);
+```
+
+Expression indexes provide the same result without a physical column:
+
+```sql
+CREATE INDEX idx_users_theme ON users(json_extract(metadata, '$.theme'));
+```
+
+---
+
+## Full-Text Search (FTS5)
+
+FTS5 provides full-text indexing with BM25 ranking. Create a virtual table backed by the source data:
+
+```sql
+CREATE VIRTUAL TABLE posts_fts USING fts5(
+    title, body,
+    content='posts',
+    content_rowid='id',
+    tokenize='porter unicode61'
+);
+```
+
+### Querying
+
+```sql
+-- Basic search with ranking
+SELECT p.*, rank
+FROM posts_fts
+JOIN posts p ON posts_fts.rowid = p.id
+WHERE posts_fts MATCH 'sqlite AND full-text'
+ORDER BY rank;
+
+-- Highlighted results
+SELECT highlight(posts_fts, 0, '<b>', '</b>') AS title,
+       snippet(posts_fts, 1, '<b>', '</b>', '...', 32) AS body_snippet
+FROM posts_fts WHERE posts_fts MATCH 'search query';
+```
+
+### Keeping FTS in Sync
+
+Maintain the FTS index with triggers on the source table:
+
+```sql
+CREATE TRIGGER posts_ai AFTER INSERT ON posts BEGIN
+    INSERT INTO posts_fts(rowid, title, body) VALUES (new.id, new.title, new.body);
+END;
+CREATE TRIGGER posts_ad AFTER DELETE ON posts BEGIN
+    INSERT INTO posts_fts(posts_fts, rowid, title, body) VALUES ('delete', old.id, old.title, old.body);
+END;
+CREATE TRIGGER posts_au AFTER UPDATE ON posts BEGIN
+    INSERT INTO posts_fts(posts_fts, rowid, title, body) VALUES ('delete', old.id, old.title, old.body);
+    INSERT INTO posts_fts(rowid, title, body) VALUES (new.id, new.title, new.body);
+END;
+```
+
+> **Deep dive:** See `references/schema-and-pragmas.md` for FTS5 tokenizer options, external content tables, prefix indexes, and FTS5 configuration.
+
+---
+
+## Python: sqlite3 and aiosqlite
+
+### Synchronous with sqlite3
+
+```python
+import sqlite3
+
+def get_connection(db_path: str) -> sqlite3.Connection:
+    conn = sqlite3.connect(db_path)
+    conn.row_factory = sqlite3.Row    # dict-like access
+    conn.execute("PRAGMA journal_mode=WAL")
+    conn.execute("PRAGMA foreign_keys=ON")
+    return conn
+
+with get_connection("app.db") as conn:
+    conn.execute("INSERT INTO users (email) VALUES (?)", ("alice@example.com",))
+    users = conn.execute("SELECT * FROM users").fetchall()
+    for user in users:
+        print(user["email"])
+```
+
+`sqlite3.Row` enables column-name access (`row["email"]`) while remaining subscriptable by index. The `with` statement auto-commits on success or rolls back on exception.
+
+### Async with aiosqlite
+
+```python
+import aiosqlite
+
+async def init_db(db_path: str) -> aiosqlite.Connection:
+    db = await aiosqlite.connect(db_path)
+    db.row_factory = aiosqlite.Row
+    await db.execute("PRAGMA journal_mode=WAL")
+    await db.execute("PRAGMA foreign_keys=ON")
+    return db
+
+async def list_users(db: aiosqlite.Connection):
+    async with db.execute("SELECT * FROM users") as cursor:
+        return await cursor.fetchall()
+```
+
+aiosqlite wraps `sqlite3` in a background thread, providing an async interface without blocking the event loop. Each `aiosqlite.Connection` maps to one `sqlite3.Connection` in a dedicated thread.
+
+> **Deep dive:** See `references/python-patterns.md` for connection pooling, custom aggregates, datetime adapters, blob I/O, aiosqlite + FastAPI integration, and migration patterns.
+
+---
+
+## JavaScript: better-sqlite3 and D1
+
+### Node.js with better-sqlite3
+
+```javascript
+const Database = require("better-sqlite3");
+
+const db = new Database("app.db");
+db.pragma("journal_mode = WAL");
+db.pragma("foreign_keys = ON");
+
+// Prepared statement (cached, reusable)
+const getUser = db.prepare("SELECT * FROM users WHERE id = ?");
+const user = getUser.get(42);
+
+// Transaction
+const insertMany = db.transaction((users) => {
+  const insert = db.prepare("INSERT INTO users (email, name) VALUES (@email, @name)");
+  for (const u of users) insert.run(u);
+});
+
+insertMany([
+  { email: "alice@example.com", name: "Alice" },
+  { email: "bob@example.com", name: "Bob" },
+]);
+```
+
+better-sqlite3 is synchronous by design -- it runs in the main thread with no async overhead. This makes it the fastest SQLite binding for Node.js. For CPU-bound queries on large datasets, offload to a worker thread.
+
+### Cloudflare D1
+
+D1 provides SQLite at the edge in Cloudflare Workers. The API is async and batch-oriented:
+
+```javascript
+export default {
+  async fetch(request, env) {
+    const { results } = await env.DB.prepare(
+      "SELECT * FROM users WHERE email = ?"
+    ).bind(email).all();
+
+    // Batch multiple statements in one round-trip
+    const batch = await env.DB.batch([
+      env.DB.prepare("INSERT INTO logs (action) VALUES (?)").bind("login"),
+      env.DB.prepare("UPDATE users SET last_login = ? WHERE id = ?").bind(now, userId),
+    ]);
+
+    return Response.json(results);
+  },
+};
+```
+
+D1 batches execute as a single transaction. Use batching to reduce round-trip latency between the Worker and the database.
+
+> **Deep dive:** See `references/javascript-patterns.md` for better-sqlite3 UDFs, WAL checkpoints, prepared statement caching, D1 migrations, and testing with Miniflare.
+
+---
+
+## Ambiguity Policy
+
+These defaults apply when the user does not specify a preference. State the assumption when making a choice so the user can override:
+
+- **Journal mode:** Default to WAL. Use rollback journal only when WAL is explicitly problematic (network filesystems, single-write-then-close patterns).
+- **Python sync vs async:** Default to `sqlite3` for synchronous code, `aiosqlite` for async/FastAPI/ASGI applications.
+- **JavaScript runtime:** Default to `better-sqlite3` for Node.js, D1 for Cloudflare Workers. Do not use `better-sqlite3` in Workers or D1 outside Workers.
+- **FTS version:** Default to FTS5. Do not use FTS3/FTS4 for new code.
+- **Table strictness:** Default to `STRICT` for new tables. Omit `STRICT` only when interfacing with legacy schemas that rely on type affinity.
+- **Parameter style:** Default to named placeholders (`:name` / `@name`) for queries with 3+ parameters. Use positional (`?`) for simple single-parameter queries.
+
+---
+
+## Reference Files
+
+| File | Contents |
+|------|----------|
+| `references/python-patterns.md` | Connection pooling, custom aggregates and collations, backup API, datetime adapters, blob I/O, aiosqlite + FastAPI integration, migration patterns |
+| `references/javascript-patterns.md` | better-sqlite3 UDFs, WAL checkpoints, prepared statement caching, D1 batch operations, D1 migrations, testing with Miniflare |
+| `references/advanced-queries.md` | CTEs (recursive), window functions (ROW_NUMBER, RANK, LAG/LEAD, running totals), upsert, RETURNING, EXPLAIN QUERY PLAN, covering indexes |
+| `references/schema-and-pragmas.md` | All recommended PRAGMAs with rationale, WAL internals, FTS5 tokenizers, external content tables, FTS5 sync triggers, partial/expression indexes, ANALYZE |