@gagik.co/snippet-agent 0.1.0

package/skills/mongodb-connection.md

@@ -0,0 +1,208 @@
+---
+name: mongodb-connection
+description: Optimize MongoDB client connection configuration (pools, timeouts, patterns) for any supported driver language. Use this skill when working/updating/reviewing functions that instantiate or configure a MongoDB client (eg, when calling `connect()`), configuring connection pools, troubleshooting connection errors (ECONNREFUSED, timeouts, pool exhaustion), optimizing performance issues related to connections.
+disable-model-invocation: false
+---
+
+# MongoDB Connection Optimizer
+
+You are an expert in MongoDB connection management across all officially supported driver languages (Node.js, Python, Java, Go, C#, Ruby, PHP, etc.).
+
+**Note:** This skill is for application/driver connection configuration, not for the current mongosh session. For the current mongosh connection, use `db.getMongo()` to inspect connection state.
+
+## Core Principle: Context Before Configuration
+
+**NEVER add connection pool parameters or timeout settings without first understanding the application's context.** Arbitrary values without justification lead to performance issues and harder-to-debug problems.
+
+## Understanding Connection Pools
+
+- Connection pooling exists because establishing a MongoDB connection is expensive (TCP + TLS + auth = 50-500ms)
+- Open connections consume ~1 MB of RAM on the MongoDB server per connection
+- Each MongoClient establishes 2 monitoring connections per replica set member
+
+**Connection Lifecycle:** Borrow from pool → Execute operation → Return to pool → Prune idle connections exceeding `maxIdleTimeMS`.
+
+**Formula:** `Total Connections = (minPoolSize + 2) × replica members × app instances`
+
+Example: 10 instances, minPoolSize 5, 3-member set = 210 server connections.
+
+## Configuration Design
+
+**Before suggesting any configuration changes**, gather context about the application environment:
+
+- Deployment type (serverless vs traditional server)
+- Workload type (OLTP vs OLAP)
+- Concurrency patterns (steady vs bursty)
+- Server version and driver version
+- Memory limits on application and database servers
+
+### Configuration Scenarios
+
+#### Scenario: Serverless Environments (Lambda, Cloud Functions)
+
+**Critical pattern**: Initialize client OUTSIDE handler/function scope to enable connection reuse across warm invocations.
+
+**Recommended configuration**:
+
+| Parameter | Value | Reasoning |
+|-----------|-------|-----------|
+| `maxPoolSize` | 3-5 | Each serverless function instance has its own pool |
+| `minPoolSize` | 0 | Prevent maintaining unused connections |
+| `maxIdleTimeMS` | 10000-30000 | Release unused connections quickly (10-30s) |
+| `connectTimeoutMS` | 5000 | Fail fast on connection issues |
+| `socketTimeoutMS` | 5000 | Use timeouts to ensure sockets are closed |
+
+**Node.js Example:**
+```javascript
+// OUTSIDE handler (reused across invocations)
+const client = new MongoClient(uri, {
+  maxPoolSize: 3,
+  minPoolSize: 0,
+  maxIdleTimeMS: 10000,
+  connectTimeoutMS: 5000,
+  socketTimeoutMS: 5000
+});
+
+export const handler = async (event) => {
+  // Reuse existing connection
+  const db = client.db("mydb");
+  const result = await db.collection("items").find({});
+  return result;
+};
+```
+
+#### Scenario: Traditional Long-Running Servers (OLTP Workload)
+
+**Recommended configuration**:
+
+| Parameter | Value | Reasoning |
+|-----------|-------|-----------|
+| `maxPoolSize` | 50-100 | Based on peak concurrent requests |
+| `minPoolSize` | 10-20 | Pre-warmed connections for traffic spikes |
+| `maxIdleTimeMS` | 300000-600000 | 5-10 minutes for stable servers |
+| `connectTimeoutMS` | 5000-10000 | Fail fast on connection issues |
+| `socketTimeoutMS` | 30000 | Prevent hanging queries |
+| `serverSelectionTimeoutMS` | 5000 | Quick failover for replica set changes |
+
+**Node.js Example:**
+```javascript
+const client = new MongoClient(uri, {
+  maxPoolSize: 50,
+  minPoolSize: 10,
+  maxIdleTimeMS: 300000,
+  connectTimeoutMS: 5000,
+  socketTimeoutMS: 30000,
+  serverSelectionTimeoutMS: 5000
+});
+```
+
+#### Scenario: OLAP / Analytical Workloads
+
+**Recommended configuration**:
+
+| Parameter | Value | Reasoning |
+|-----------|-------|-----------|
+| `maxPoolSize` | 10-20 | Fewer concurrent operations |
+| `minPoolSize` | 0-5 | Queries are infrequent |
+| `socketTimeoutMS` | 300000+ | Allow long-running queries |
+| `maxIdleTimeMS` | 600000 | Minimize connection churn |
+
+**Node.js Example:**
+```javascript
+const client = new MongoClient(uri, {
+  maxPoolSize: 15,
+  minPoolSize: 2,
+  socketTimeoutMS: 300000, // 5 minutes for slow queries
+  maxIdleTimeMS: 600000
+});
+```
+
+#### Scenario: High-Traffic / Bursty Workloads
+
+**Recommended configuration**:
+
+| Parameter | Value | Reasoning |
+|-----------|-------|-----------|
+| `maxPoolSize` | 100+ | Higher ceiling for traffic spikes |
+| `minPoolSize` | 20-30 | More pre-warmed connections |
+| `maxConnecting` | 2 | Prevent thundering herd |
+| `waitQueueTimeoutMS` | 2000-5000 | Fail fast when pool exhausted |
+| `maxIdleTimeMS` | 300000 | Balance reuse and cleanup |
+
+## Troubleshooting Connection Issues
+
+### Pool Exhaustion
+
+**Symptoms:** `MongoWaitQueueTimeoutError`, increased latency, operations waiting.
+
+**Diagnosis via mongosh (server-side):**
+```javascript
+// Check current connections
+db.serverStatus().connections
+
+// Check active operations
+db.currentOp({ active: true })
+```
+
+**Solutions:**
+- **Increase `maxPoolSize`** when: Server shows low utilization but clients are waiting
+- **Don't increase** when: Server is at capacity (suggest query optimization instead)
+
+### Connection Timeouts
+
+**Symptoms:** `ECONNREFUSED`, `SocketTimeoutError`
+
+**Check:**
+- Network connectivity: Can you connect via mongosh from the same host?
+- Firewall/VPC settings
+- DNS resolution for SRV connections
+- TLS certificate validity
+
+### Connection Churn
+
+**Symptoms:** Rapidly increasing `connections.totalCreated` server metric
+
+**Causes:**
+- Not reusing clients (creating new MongoClient per request)
+- Not caching in serverless
+- `maxIdleTimeMS` too low
+
+**Solution:** Ensure single MongoClient instance reused across application lifecycle
+
+## Monitoring Connections
+
+```javascript
+// In mongosh - check server-side connection metrics
+db.serverStatus().connections
+// Returns:
+// {
+//   current: 42,      // Current open connections
+//   available: 838858, // Available connection slots
+//   totalCreated: 1523 // Total connections created since startup
+// }
+
+// Check active operations
+db.currentOp({ active: true }).inprog.length
+
+// Check slow operations (if profiling enabled)
+db.system.profile.find().sort({ ts: -1 }).limit(5)
+```
+
+## Best Practices Summary
+
+1. **Create client once, reuse everywhere** - Never create new MongoClient per request
+2. **Initialize outside serverless handlers** - Enable warm-start connection reuse
+3. **Size pools based on concurrency** - Monitor and adjust based on actual load
+4. **Use appropriate timeouts** - Match socketTimeoutMS to expected query duration
+5. **Don't manually close connections** - Let the driver manage connection lifecycle
+6. **Monitor connection metrics** - Watch `connections.current` and creation rate
+
+## Action Policy
+
+**I will NEVER suggest configuration changes without understanding your context first.**
+
+Before recommending connection settings:
+1. I'll ask about your deployment type and workload
+2. I'll inquire about current issues you're experiencing
+3. I'll suggest specific values **with explanations** of why they fit your scenario
+4. You can then apply the configuration and test

package/skills/mongodb-natural-language-querying.md

@@ -0,0 +1,202 @@
+---
+name: mongodb-natural-language-querying
+description: Generate read-only MongoDB queries (find) or aggregation pipelines using natural language, with collection schema context and sample documents. Use this skill whenever the user asks to write, create, or generate MongoDB queries, wants to filter/query/aggregate data in MongoDB, asks "how do I query...", needs help with query syntax, or discusses finding/filtering/grouping MongoDB documents. Also use for translating SQL-like requests to MongoDB syntax. Does NOT handle Atlas Search ($search operator), vector/semantic search ($vectorSearch operator), fuzzy matching, autocomplete indexes, or relevance scoring - use mongodb-search-and-ai for those. Does NOT analyze or optimize existing queries - use mongodb-query-optimizer for that. Does NOT handle aggregation pipelines that involve write operations.
+disable-model-invocation: false
+---
+
+# MongoDB Natural Language Querying
+
+You are an expert MongoDB read-only query and aggregation pipeline generator. You have access to the `mongosh_eval` tool to execute shell commands and inspect the database.
+
+## Query Generation Process
+
+### 1. Gather Context Using mongosh_eval
+
+**Required Information:**
+- Database name and collection name (use `show dbs`, `show collections`, or ask user)
+- User's natural language description of the query
+
+**Fetch in this order using mongosh_eval:**
+
+1. **Indexes** (for query optimization):
+   ```javascript
+   db.collection.getIndexes()
+   ```
+
+2. **Sample documents** (for understanding data patterns):
+   ```javascript
+   db.collection.find().limit(4)
+   ```
+   - Shows actual data values and formats
+   - Reveals common patterns (enums, ranges, etc.)
+
+3. **Collection stats** (optional, for context):
+   ```javascript
+   db.collection.stats()
+   db.collection.countDocuments()
+   ```
+
+### 2. Analyze Context and Validate Fields
+
+Before generating a query, always validate field names against the sample documents you fetched. MongoDB won't error on nonexistent field names - it will simply return no results or behave unexpectedly, making bugs hard to diagnose. By checking the sample documents first, you catch these issues before the user tries to run the query.
+
+Also review the available indexes to understand which query patterns will perform best.
+
+### 3. Choose Query Type: Find vs Aggregation
+
+Prefer find queries over aggregation pipelines because find queries are simpler and easier for other developers to understand.
+
+**Use Find Query when:**
+- Simple filtering on one or more fields
+- Basic sorting, limiting, or projecting specific fields
+- No need for grouping, complex transformations, or multi-stage processing
+
+**Use Aggregation Pipeline when the request requires:**
+- Grouping or aggregation functions (sum, count, average, etc.)
+- Multiple transformation stages
+- Joins with other collections ($lookup)
+- Array unwinding or complex array operations
+
+### 4. Format Your Response
+
+Output queries using mongosh shell syntax for readability and compatibility with the current mongosh session.
+
+**Find Query Response:**
+```javascript
+// Filter: users aged 25+
+// Projection: name and age only
+// Sort: by age descending, limit 10
+db.users.find(
+  { age: { $gte: 25 } },
+  { name: 1, age: 1, _id: 0 }
+).sort({ age: -1 }).limit(10)
+```
+
+**Aggregation Pipeline Response:**
+```javascript
+db.orders.aggregate([
+  { $match: { status: 'active' } },
+  { $group: { _id: '$category', total: { $sum: '$amount' } } },
+  { $sort: { total: -1 } }
+])
+```
+
+## Best Practices
+
+### Query Quality
+1. **Generate correct queries** - Build queries that match user requirements, then check index coverage:
+   - Generate the query to correctly satisfy all user requirements
+   - After generating the query, check if existing indexes can support it
+   - If no appropriate index exists, mention this in your response (user may want to create one)
+   - Never use `$where` because it prevents index usage
+   - Do not use `$text` without a text index
+   - `$expr` should only be used when necessary (use sparingly)
+
+2. **Avoid redundant operators** - Never add operators that are already implied by other conditions:
+   - Don't add `$exists` when you already have an equality or inequality check (e.g., `status: "active"` or `age: { $gt: 25 }` already implies the field exists)
+   - Don't add overlapping range conditions (e.g., don't use both `$gte: 0` and `$gt: -1`)
+   - Each condition should add meaningful filtering that isn't already covered
+
+3. **Project only needed fields** - Reduce data transfer with projections
+   - Add `_id: 0` to the projection when `_id` field is not needed
+
+4. **Validate field names** against the sample documents before using them
+
+5. **Use appropriate operators** - Choose the right MongoDB operator for the task:
+   - `$eq`, `$ne`, `$gt`, `$gte`, `$lt`, `$lte` for comparisons
+   - `$in`, `$nin` for matching against a list of possible values (equivalent to multiple $eq/$ne conditions OR'ed together)
+   - `$and`, `$or`, `$not`, `$nor` for logical operations
+   - `$regex` for case-sensitive text pattern matching (prefer left-anchored patterns like `/^prefix/` when possible, as they can use indexes efficiently)
+   - `$exists` for field existence checks (prefer `a: {$ne: null}` to `a: {$exists: true}` to leverage available indexes)
+   - `$type` for type matching
+
+6. **Optimize array field checks** - Use efficient patterns for array operations:
+   - To check if an array is non-empty: use `"arrayField.0": {$exists: true}` instead of `arrayField: {$exists: true, $type: "array", $ne: []}`
+   - Checking for the first element's existence is simpler, more readable, and more efficient than combining existence, type, and inequality checks
+   - For matching array elements with multiple conditions, use `$elemMatch`
+   - For array length checks, use `$size` when you need an exact count
+
+### Aggregation Pipeline Quality
+1. **Filter early** - Use `$match` as early as possible to reduce documents
+2. **Project at the end** - Use `$project` at the end to correctly shape returned documents to the client
+3. **Limit when possible** - Add `$limit` after `$sort` when appropriate
+4. **Use indexes** - Ensure `$match` and `$sort` stages can use indexes:
+   - Place `$match` stages at the beginning of the pipeline
+   - Initial `$match` and `$sort` stages can use indexes if they precede any stage that modifies documents
+   - After generating `$match` filters, check if indexes can support them
+   - Minimize stages that transform documents before first `$match`
+5. **Optimize `$lookup`** - Consider denormalization for frequently joined data
+
+### Error Prevention
+1. **Validate all field references** against the sample documents
+2. **Quote field names correctly** - Use dot notation for nested fields
+3. **Escape special characters** in regex patterns
+4. **Check data types** - Ensure field values match field types from sample documents
+5. **Geospatial coordinates** - MongoDB's GeoJSON format requires longitude first, then latitude (e.g., `[longitude, latitude]` or `{type: "Point", coordinates: [lng, lat]}`). This is opposite to how coordinates are often written in plain English, so double-check this when generating geo queries.
+
+## Schema Analysis
+
+When provided with sample documents, analyze:
+1. **Field types** - String, Number, Boolean, Date, ObjectId, Array, Object
+2. **Field patterns** - Required vs optional fields (check multiple samples)
+3. **Nested structures** - Objects within objects, arrays of objects
+4. **Array elements** - Homogeneous vs heterogeneous arrays
+5. **Special types** - Dates, ObjectIds, Binary data, GeoJSON
+
+## Sample Document Usage
+
+Use sample documents to:
+- Understand actual data values and ranges
+- Identify field naming conventions (camelCase, snake_case, etc.)
+- Detect common patterns (e.g., status enums, category values)
+- Estimate cardinality for grouping operations
+- Validate that your query will work with real data
+
+## Error Handling
+
+If you cannot generate a query:
+1. **Explain why** - Missing schema, ambiguous request, impossible query
+2. **Ask for clarification** - Request more details about requirements
+3. **Suggest alternatives** - Propose different approaches if available
+4. **Provide examples** - Show similar queries that could work
+
+## Example Workflow
+
+**User Input:** "Find all active users over 25 years old, sorted by registration date"
+
+**Your Process:**
+1. Use mongosh_eval to check schema: `db.users.find().limit(3)`
+2. Use mongosh_eval to check indexes: `db.users.getIndexes()`
+3. Verify field names: `status`, `age`, `registrationDate` or similar
+4. Verify field types match the query requirements
+5. Generate query based on user requirements
+6. Check if available indexes can support the query
+7. Suggest creating an index if no appropriate index exists for the query filters
+
+**Generated Query:**
+```javascript
+db.users.find(
+  { status: 'active', age: { $gt: 25 } }
+).sort({ registrationDate: -1 })
+```
+
+## Managing Context Size
+
+Fetching large or numerous sample documents wastes context and can degrade query quality.
+
+**Adjust sample count by schema width:**
+- < 30 fields: `limit: 4` (default)
+- 30-80 fields: `limit: 2`
+- 80-150 fields: `limit: 1`
+- 150+ fields: `limit: 1` with a projection of only the fields relevant to the user's query
+
+**Preview large array fields and strings:**
+- If schema documents contains arrays, use `$slice: 3` in the sample projection to cap array size. Limit string fields to 100 characters with `$substr` in the sample projection to prevent excessively long values from consuming context.
+
+## Executing Queries
+
+When executing queries via mongosh_eval:
+1. Start with a small limit to preview results: `.limit(5)`
+2. Check that field names and values match expectations
+3. For aggregation pipelines, test incrementally by adding one stage at a time
+4. Use `.explain("executionStats")` to verify index usage for slow queries

package/skills/mongodb-query-optimizer.md

@@ -0,0 +1,265 @@
+---
+name: mongodb-query-optimizer
+description: Help with MongoDB query optimization and indexing. Use only when the user asks for optimization or performance - "How do I optimize this query?", "How do I index this?", "Why is this query slow?", "Can you fix my slow queries?", "What are the slow queries on my cluster?", etc. Do not invoke for general MongoDB query writing unless user asks for performance or index help. Prefer indexing as optimization strategy.
+disable-model-invocation: false
+---
+
+# MongoDB Query Optimizer
+
+## When this skill is invoked
+
+Invoke **only** when the user wants:
+
+- Query/index **optimization** or **performance** help 
+- **Why** a query is slow or **how to speed it up** 
+- **How to index** a specific query
+- **Slow queries** on their cluster and/or **how to optimize them**
+
+Do **not** invoke for routine query authoring unless the user has requested help with optimization, slow queries, or indexing.
+
+## High Level Workflow
+
+### General Performance Help
+
+If the user wants to examine slow queries, or is looking for general performance suggestions (not regarding any particular query):
+
+1. Check the profiling level and slow query log using mongosh_eval:
+   ```javascript
+   // Enable profiling level 1 (slow ops only, >100ms)
+   db.setProfilingLevel(1, { slowms: 100 })
+   
+   // View recent slow queries
+   db.system.profile.find().sort({ ts: -1 }).limit(10)
+   
+   // Check server status for metrics
+   db.serverStatus()
+   ```
+
+2. Check index usage stats across collections:
+   ```javascript
+   // For a specific collection
+   db.collection.aggregate([{ $indexStats: {} }])
+   ```
+
+### Help with a Specific Query
+
+If the user is asking about a particular query:
+
+1. **Get existing indexes** using mongosh_eval:
+   ```javascript
+   db.collection.getIndexes()
+   ```
+
+2. **Run explain** to analyze the query plan:
+   ```javascript
+   // Basic explain
+   db.collection.find({...}).explain()
+   
+   // Execution stats for detailed analysis
+   db.collection.find({...}).explain("executionStats")
+   
+   // All plans execution to compare different approaches
+   db.collection.find({...}).explain("allPlansExecution")
+   ```
+
+3. **Get a sample document** to understand the schema:
+   ```javascript
+   db.collection.find().limit(1)
+   ```
+
+## Using Explain Output
+
+### Key Fields in explain("executionStats")
+
+```javascript
+{
+  executionStats: {
+    nReturned: 5,              // Documents returned
+    totalDocsExamined: 1000,   // Documents scanned
+    totalKeysExamined: 5,      // Index keys examined
+    executionTimeMillis: 2,    // Time in milliseconds
+    stage: "IXSCAN",           // COLLSCAN, IXSCAN, FETCH, etc.
+    inputStage: {
+      stage: "IXSCAN",
+      indexName: "field_1",
+      keyPattern: { field: 1 }
+    }
+  }
+}
+```
+
+### What to Look For
+
+**Good signs:**
+- `stage: "IXSCAN"` with `totalKeysExamined` close to `nReturned`
+- `totalDocsExamined` equals `nReturned` (covered query)
+- `executionTimeMillis` is low
+
+**Bad signs:**
+- `stage: "COLLSCAN"` (collection scan)
+- `totalDocsExamined` much higher than `nReturned` (inefficient index)
+- High `executionTimeMillis`
+
+## Example Workflow 1 (help with specific query)
+
+**User:** "Why is this query slow? `db.orders.find({status: 'shipped', region: 'US'}).sort({date: -1})`"
+
+1. **Check existing collection indexes:**
+   ```javascript
+   db.orders.getIndexes()
+   ```
+   - Result shows: `{_id: 1}`, `{status: 1}`, `{date: -1}`
+
+2. **Run explain:**
+   ```javascript
+   db.orders.find(
+     {status: 'shipped', region: 'US'}
+   ).sort({date: -1}).explain("executionStats")
+   ```
+   - Result: Uses `{status: 1}` index, then in-memory SORT
+   - `totalKeysExamined: 50000`, `nReturned: 100`
+
+3. **Diagnose:** The query targets 100 docs but scans 50K index entries. In-memory sort adds overhead. Index doesn't support both filter fields or sort.
+
+4. **Recommend:** Create compound index `{status: 1, region: 1, date: -1}` following ESR (two equality fields, then sort).
+
+## Indexing Best Practices
+
+### Creating Indexes Safely
+
+```javascript
+// Check index doesn't exist first
+db.collection.getIndexes()
+
+// Create index in background (recommended for production)
+db.collection.createIndex(
+  { field: 1 },
+  { background: true }
+)
+
+// Compound index following ESR rule
+// Equality → Sort → Range
+db.orders.createIndex({
+  status: 1,        // Equality
+  createdAt: -1,    // Sort
+  age: 1            // Range
+})
+```
+
+### Common Index Candidates
+- Fields in `find()` queries (especially equality matches)
+- Fields in `sort()` operations
+- Fields in aggregation `$match` stages
+- Foreign key-like fields used in `$lookup`
+
+### When Queries Use Indexes
+- Equality matches on index prefix
+- Range queries on index fields (use bounded ranges)
+- Sorting on indexed fields
+- Covered queries (all fields in index)
+
+### When Indexes Are Ignored
+- `$nin`, `$ne`, `$not` often can't use indexes effectively
+- Regex without prefix anchor `/^pattern/`
+- `$where` clauses
+- Large `$in` arrays (threshold varies)
+
+### Specialized Index Types
+
+```javascript
+// Partial index (only index active users)
+db.users.createIndex(
+  { email: 1 },
+  { partialFilterExpression: { status: "active" } }
+)
+
+// Sparse index (only index documents where field exists)
+db.collection.createIndex(
+  { optionalField: 1 },
+  { sparse: true }
+)
+
+// TTL index (auto-delete old documents)
+db.logs.createIndex(
+  { createdAt: 1 },
+  { expireAfterSeconds: 2592000 }  // 30 days
+)
+```
+
+## Query Patterns to Avoid
+
+1. **Unbounded queries**: Always use limits
+   ```javascript
+   // BAD
+   db.logs.find({ level: "error" })
+   // GOOD
+   db.logs.find({ level: "error" }).limit(100)
+   ```
+
+2. **Large skip values**: Use cursor-based pagination
+   ```javascript
+   // BAD: skip 1000000 is slow
+   db.collection.find().skip(1000000).limit(10)
+   // GOOD: cursor-based
+   db.collection.find({ _id: { $gt: lastId } }).limit(10)
+   ```
+
+3. **$lookup without index on foreign field**
+
+4. **Updating large arrays**: Consider separate collection
+
+5. **Unnecessary projections**: Project only needed fields
+
+## Server Metrics to Monitor
+
+```javascript
+// Key metrics from serverStatus
+db.serverStatus().opcounters     // CRUD operation counts
+db.serverStatus().connections    // Current connections
+db.serverStatus().mem            // Memory usage
+db.serverStatus().globalLock     // Lock contention
+
+// WiredTiger cache metrics
+db.serverStatus().wiredTiger.cache
+// Look for:
+// - "bytes currently in the cache" vs available RAM
+// - "pages evicted by application threads" (high = pressure)
+```
+
+## Aggregation Pipeline Optimization
+
+### Stage Ordering
+```javascript
+// GOOD: Filter early
+db.orders.aggregate([
+  { $match: { status: "shipped", date: { $gte: startDate } } },
+  { $group: { _id: "$customerId", total: { $sum: "$amount" } } },
+  { $sort: { total: -1 } },
+  { $limit: 10 }
+])
+
+// BAD: Sort before filtering
+db.orders.aggregate([
+  { $sort: { date: -1 } },
+  { $match: { status: "shipped" } }
+])
+```
+
+### Memory Optimization
+```javascript
+// Allow disk use for large aggregations
+db.collection.aggregate([...], { allowDiskUse: true })
+
+// Use $project to reduce document size early
+{ $project: { neededField: 1, computed: { $add: ["$a", "$b"] } } }
+```
+
+## Output Guidelines
+
+- Keep answers short and clear: a few sentences on index and optimization suggestions
+- Focus on highest impact indexes or optimizations
+- Do not use strong language like "this will definitely improve performance"
+- Explain they are suggestions and give the reasoning behind them
+- Consider how many indexes already exist on the collection (shouldn't generally be more than 20)
+- Suggest removing indexes only if they are clearly unused (check `$indexStats`)
+- Never create indexes without user approval - show the command and wait for confirmation