@cubis/foundry 0.3.11 → 0.3.12

package/Ai Agent Workflow/powers/code-review-checklist/SKILL.md

@@ -1,11 +1,109 @@
 ---
 name: code-review-checklist
 description: Code review guidelines covering code quality, security, and best practices.
+allowed-tools: Read, Glob, Grep
 ---
 
-# code-review-checklist
+# Code Review Checklist
 
-This power mirrors the base skill:
-- `Ai Agent Workflow/skills/code-review-checklist/SKILL.md`
+## Quick Review Checklist
 
-When both exist, prefer the base skill as source of truth unless power-specific overrides are added here.
+### Correctness
+- [ ] Code does what it's supposed to do
+- [ ] Edge cases handled
+- [ ] Error handling in place
+- [ ] No obvious bugs
+
+### Security
+- [ ] Input validated and sanitized
+- [ ] No SQL/NoSQL injection vulnerabilities
+- [ ] No XSS or CSRF vulnerabilities
+- [ ] No hardcoded secrets or sensitive credentials
+- [ ] **AI-Specific:** Protection against Prompt Injection (if applicable)
+- [ ] **AI-Specific:** Outputs are sanitized before being used in critical sinks
+
+### Performance
+- [ ] No N+1 queries
+- [ ] No unnecessary loops
+- [ ] Appropriate caching
+- [ ] Bundle size impact considered
+
+### Code Quality
+- [ ] Clear naming
+- [ ] DRY - no duplicate code
+- [ ] SOLID principles followed
+- [ ] Appropriate abstraction level
+
+### Testing
+- [ ] Unit tests for new code
+- [ ] Edge cases tested
+- [ ] Tests readable and maintainable
+
+### Documentation
+- [ ] Complex logic commented
+- [ ] Public APIs documented
+- [ ] README updated if needed
+
+## AI & LLM Review Patterns (2025)
+
+### Logic & Hallucinations
+- [ ] **Chain of Thought:** Does the logic follow a verifiable path?
+- [ ] **Edge Cases:** Did the AI account for empty states, timeouts, and partial failures?
+- [ ] **External State:** Is the code making safe assumptions about file systems or networks?
+
+### Prompt Engineering Review
+```markdown
+// ❌ Vague prompt in code
+const response = await ai.generate(userInput);
+
+// ✅ Structured & Safe prompt
+const response = await ai.generate({
+  system: "You are a specialized parser...",
+  input: sanitize(userInput),
+  schema: ResponseSchema
+});
+```
+
+## Anti-Patterns to Flag
+
+```typescript
+// ❌ Magic numbers
+if (status === 3) { ... }
+
+// ✅ Named constants
+if (status === Status.ACTIVE) { ... }
+
+// ❌ Deep nesting
+if (a) { if (b) { if (c) { ... } } }
+
+// ✅ Early returns
+if (!a) return;
+if (!b) return;
+if (!c) return;
+// do work
+
+// ❌ Long functions (100+ lines)
+// ✅ Small, focused functions
+
+// ❌ any type
+const data: any = ...
+
+// ✅ Proper types
+const data: UserData = ...
+```
+
+## Review Comments Guide
+
+```
+// Blocking issues use 🔴
+🔴 BLOCKING: SQL injection vulnerability here
+
+// Important suggestions use 🟡
+🟡 SUGGESTION: Consider using useMemo for performance
+
+// Minor nits use 🟢
+🟢 NIT: Prefer const over let for immutable variable
+
+// Questions use ❓
+❓ QUESTION: What happens if user is null here?
+```

package/Ai Agent Workflow/powers/code-reviewer/POWER.md

@@ -1,19 +1,11 @@
+````markdown
 ---
-name: code-reviewer
-displayName: Code Reviewer
-description:
-  Use when reviewing pull requests, conducting code quality audits, or
-  identifying security vulnerabilities. Invoke for PR reviews, code quality checks,
-  refactoring suggestions.
-keywords:
-  - code review
-  - PR review
-  - pull request
-  - review code
-  - code quality
-author: OneUp
+inclusion: manual
+name: "code-reviewer"
+description: "Use when reviewing pull requests, conducting code quality audits, or identifying security vulnerabilities. Invoke for PR reviews, code quality checks, refactoring suggestions."
 ---
 
+
 # Code Reviewer
 
 ## Overview
@@ -46,15 +38,15 @@ Load detailed guidance on-demand:
 
 | Topic             | Reference                       | Load When                            |
 | ----------------- | ------------------------------- | ------------------------------------ |
-| Review Checklist  | `steering/review-checklist.md`  | Starting a review, categories        |
-| Common Issues     | `steering/common-issues.md`     | N+1 queries, magic numbers, patterns |
-| Feedback Examples | `steering/feedback-examples.md` | Writing good feedback                |
-| Report Template   | `steering/report-template.md`   | Writing final review report          |
+| Review Checklist  | `references/review-checklist.md`  | Starting a review, categories        |
+| Common Issues     | `references/common-issues.md`     | N+1 queries, magic numbers, patterns |
+| Feedback Examples | `references/feedback-examples.md` | Writing good feedback                |
+| Report Template   | `references/report-template.md`   | Writing final review report          |
 
 <!-- Rows below adapted from obra/superpowers by Jesse Vincent (@obra), MIT License -->
 
-| Spec Compliance | `steering/spec-compliance-review.md` | Reviewing implementations, PR review, spec verification |
-| Receiving Feedback | `steering/receiving-feedback.md` | Responding to review comments, handling feedback |
+| Spec Compliance | `references/spec-compliance-review.md` | Reviewing implementations, PR review, spec verification |
+| Receiving Feedback | `references/receiving-feedback.md` | Responding to review comments, handling feedback |
 
 ## Constraints
 
@@ -98,3 +90,4 @@ SOLID, DRY, KISS, YAGNI, design patterns, OWASP Top 10, language idioms, testing
 - **Security Reviewer** - Deep security analysis
 - **Test Master** - Test quality assessment
 - **Architecture Designer** - Design review
+````

package/Ai Agent Workflow/powers/code-reviewer/SKILL.md

@@ -36,15 +36,15 @@ Load detailed guidance on-demand:
 
 | Topic             | Reference                       | Load When                            |
 | ----------------- | ------------------------------- | ------------------------------------ |
-| Review Checklist  | `steering/review-checklist.md`  | Starting a review, categories        |
-| Common Issues     | `steering/common-issues.md`     | N+1 queries, magic numbers, patterns |
-| Feedback Examples | `steering/feedback-examples.md` | Writing good feedback                |
-| Report Template   | `steering/report-template.md`   | Writing final review report          |
+| Review Checklist  | `references/review-checklist.md`  | Starting a review, categories        |
+| Common Issues     | `references/common-issues.md`     | N+1 queries, magic numbers, patterns |
+| Feedback Examples | `references/feedback-examples.md` | Writing good feedback                |
+| Report Template   | `references/report-template.md`   | Writing final review report          |
 
 <!-- Rows below adapted from obra/superpowers by Jesse Vincent (@obra), MIT License -->
 
-| Spec Compliance | `steering/spec-compliance-review.md` | Reviewing implementations, PR review, spec verification |
-| Receiving Feedback | `steering/receiving-feedback.md` | Responding to review comments, handling feedback |
+| Spec Compliance | `references/spec-compliance-review.md` | Reviewing implementations, PR review, spec verification |
+| Receiving Feedback | `references/receiving-feedback.md` | Responding to review comments, handling feedback |
 
 ## Constraints
 

package/Ai Agent Workflow/powers/database-skills/POWER.md

@@ -1,21 +1,105 @@
+````markdown
 ---
+inclusion: manual
 name: database-skills
-description: Power-oriented database execution pack for PostgreSQL, MySQL, Vitess, Neki, MongoDB, SQLite, Supabase, and Redis.
+description: Unified database skill hub with engine-specific packs for PostgreSQL, MySQL, Vitess, Neki, MongoDB (Mongoose), SQLite, Supabase, and Redis.
+allowed-tools: Read, Write, Edit, Glob, Grep, Bash
+metadata:
+  version: "2.0.0"
+  domain: data
+  triggers: database, sql, postgres, mysql, vitess, neki, mongodb, mongoose, sqlite, supabase, redis, schema, migration, index, query, performance, pagination, replication, pooling, sharding, cache
 ---
 
-# database-skills
+# Database Skills Hub
 
-This is the power-mode entrypoint for database tasks.
+Use this as the primary database hub. Keep `database-design`, `database-optimizer`, and `drift-flutter` available for specialized/legacy-compatible flows. Load the target engine's `SKILL.md` from `skills/<engine>/`, then load relevant `references/*` files.
 
-Primary source files:
-- `Ai Agent Workflow/skills/database-skills/SKILL.md`
-- `Ai Agent Workflow/skills/database-skills/LATEST_VERSIONS.md`
+## Engine selection
 
-Execution policy:
-1. Pick engine wrapper first.
-2. Use measurable optimization methods only.
-3. No schema/data destructive action without explicit confirmation.
-4. Always include rollback.
+| Situation | Engine |
+| --- | --- |
+| Relational OLTP, self-hosted or cloud | Postgres |
+| Relational OLTP, MySQL-compatible managed service | MySQL + Vitess (PlanetScale) |
+| Multi-tenant SaaS needing horizontal Postgres scale | Neki |
+| Document model, flexible schema | MongoDB |
+| Mobile / desktop / edge local storage | SQLite |
+| BaaS with built-in auth, storage & realtime | Supabase |
+| Caching, queues, leaderboards, pub/sub | Redis |
 
-Engine wrappers live in:
-- `Ai Agent Workflow/powers/database-skills/engines/`
+## Structure
+
+```
+skills/
+  postgres/
+    SKILL.md
+    references/
+      schema-indexing.md       ← index types, composite, partial, INCLUDE
+      performance-ops.md       ← EXPLAIN, pg_stat_statements, VACUUM, autovacuum
+      migrations.md            ← zero-downtime DDL, expand/contract, tools
+      connection-pooling.md    ← PgBouncer, pool sizing, serverless patterns
+
+  mysql/
+    SKILL.md
+    references/
+      query-indexing.md        ← EXPLAIN, composite indexes, covering, seek pagination
+      locking-ddl.md           ← INSTANT/INPLACE/COPY, MDL, gh-ost, deadlocks
+      replication.md           ← binlog formats, GTID, lag monitoring, read routing
+
+  vitess/
+    SKILL.md
+    references/
+      sharding-routing.md      ← VSchema, vindexes, sequences, scatter queries
+      operational-safety.md    ← Online DDL strategies, migration lifecycle, VReplication
+
+  neki/
+    SKILL.md
+    references/
+      architecture.md          ← sharded Postgres architecture, pre-sharding checklist
+      operations.md            ← migration planning, validation, provisional pre-GA guidance
+
+  mongodb/
+    SKILL.md
+    references/
+      modeling.md              ← embed vs reference, compound indexes, explain(), pagination
+      mongoose-nestjs.md       ← repository pattern, lean reads, transactions, NestJS setup
+      aggregation.md           ← pipeline stages, $group, $lookup, $facet, performance
+
+  sqlite/
+    SKILL.md
+    references/
+      local-first.md           ← WAL mode, migration patterns, sync/conflict strategies
+      performance.md           ← EXPLAIN QUERY PLAN, indexes, batch writes, checkpoint tuning
+
+  supabase/
+    SKILL.md
+    references/
+      rls-auth.md              ← RLS policies, auth.uid(), index predicates, service_role
+      performance-operations.md ← query optimization, connection modes, pooler selection
+
+  redis/
+    SKILL.md
+    references/
+      data-modeling.md         ← data structure selection, key naming, TTL strategy
+      cache-patterns.md        ← pipelining, SCAN, rate limiting, leaderboards, invalidation
+      operations.md            ← memory management, eviction policies, latency diagnostics
+```
+
+## Required flow
+
+1. Read `LATEST_VERSIONS.md` before proposing version-specific behavior.
+2. Use engine selection table above to pick the target engine.
+3. Load the target engine `SKILL.md` and relevant `references/*` files — read the ones that match the task (indexing, migrations, replication, etc.).
+4. Provide an optimization or implementation plan that includes:
+   - specific change with rationale,
+   - indexing or schema decisions,
+   - migration safety (online vs offline),
+   - rollback path.
+5. For production-impacting changes, include blast-radius assessment and rollout stages.
+
+## Cross-engine performance checklist
+
+- **Indexing**: add indexes only for real predicates and sort patterns. Drop unused indexes — they penalize writes.
+- **Pagination**: prefer keyset/seek for deep or high-throughput pagination. Reserve offset for shallow interactive pages only.
+- **Measurement**: compare before/after plans with engine-native explain tooling (`EXPLAIN ANALYZE`, `VEXPLAIN`, `explain()`). Validate with realistic cardinality.
+- **Safety**: no destructive data/schema operations without explicit user confirmation. Always include rollback/recovery steps.
+````

package/Ai Agent Workflow/powers/database-skills/SKILL.md

@@ -1,33 +1,102 @@
 ---
 name: database-skills
-description: Power bridge for the unified database-skills package with engine-specific wrappers.
+description: Unified database skill hub with engine-specific packs for PostgreSQL, MySQL, Vitess, Neki, MongoDB (Mongoose), SQLite, Supabase, and Redis.
+allowed-tools: Read, Write, Edit, Glob, Grep, Bash
+metadata:
+  version: "2.0.0"
+  domain: data
+  triggers: database, sql, postgres, mysql, vitess, neki, mongodb, mongoose, sqlite, supabase, redis, schema, migration, index, query, performance, pagination, replication, pooling, sharding, cache
 ---
 
-# database-skills
+# Database Skills Hub
 
-Use this power as the routing layer over the database skill pack.
+Use this as the primary database hub. Keep `database-design`, `database-optimizer`, and `drift-flutter` available for specialized/legacy-compatible flows. Load the target engine's `SKILL.md` from `skills/<engine>/`, then load relevant `references/*` files.
 
-Primary source of truth:
-- `Ai Agent Workflow/skills/database-skills/SKILL.md`
-- `Ai Agent Workflow/skills/database-skills/LATEST_VERSIONS.md`
+## Engine selection
+
+| Situation | Engine |
+| --- | --- |
+| Relational OLTP, self-hosted or cloud | Postgres |
+| Relational OLTP, MySQL-compatible managed service | MySQL + Vitess (PlanetScale) |
+| Multi-tenant SaaS needing horizontal Postgres scale | Neki |
+| Document model, flexible schema | MongoDB |
+| Mobile / desktop / edge local storage | SQLite |
+| BaaS with built-in auth, storage & realtime | Supabase |
+| Caching, queues, leaderboards, pub/sub | Redis |
+
+## Structure
+
+```
+skills/
+  postgres/
+    SKILL.md
+    references/
+      schema-indexing.md       ← index types, composite, partial, INCLUDE
+      performance-ops.md       ← EXPLAIN, pg_stat_statements, VACUUM, autovacuum
+      migrations.md            ← zero-downtime DDL, expand/contract, tools
+      connection-pooling.md    ← PgBouncer, pool sizing, serverless patterns
+
+  mysql/
+    SKILL.md
+    references/
+      query-indexing.md        ← EXPLAIN, composite indexes, covering, seek pagination
+      locking-ddl.md           ← INSTANT/INPLACE/COPY, MDL, gh-ost, deadlocks
+      replication.md           ← binlog formats, GTID, lag monitoring, read routing
+
+  vitess/
+    SKILL.md
+    references/
+      sharding-routing.md      ← VSchema, vindexes, sequences, scatter queries
+      operational-safety.md    ← Online DDL strategies, migration lifecycle, VReplication
+
+  neki/
+    SKILL.md
+    references/
+      architecture.md          ← sharded Postgres architecture, pre-sharding checklist
+      operations.md            ← migration planning, validation, provisional pre-GA guidance
+
+  mongodb/
+    SKILL.md
+    references/
+      modeling.md              ← embed vs reference, compound indexes, explain(), pagination
+      mongoose-nestjs.md       ← repository pattern, lean reads, transactions, NestJS setup
+      aggregation.md           ← pipeline stages, $group, $lookup, $facet, performance
+
+  sqlite/
+    SKILL.md
+    references/
+      local-first.md           ← WAL mode, migration patterns, sync/conflict strategies
+      performance.md           ← EXPLAIN QUERY PLAN, indexes, batch writes, checkpoint tuning
+
+  supabase/
+    SKILL.md
+    references/
+      rls-auth.md              ← RLS policies, auth.uid(), index predicates, service_role
+      performance-operations.md ← query optimization, connection modes, pooler selection
+
+  redis/
+    SKILL.md
+    references/
+      data-modeling.md         ← data structure selection, key naming, TTL strategy
+      cache-patterns.md        ← pipelining, SCAN, rate limiting, leaderboards, invalidation
+      operations.md            ← memory management, eviction policies, latency diagnostics
+```
 
 ## Required flow
 
-1. Read the version baseline first.
-2. Choose the engine wrapper in `engines/<engine>/POWER.md`.
-3. Produce decisions with:
-   - indexing strategy,
-   - pagination strategy,
-   - query-plan evidence (`EXPLAIN` or equivalent),
+1. Read `LATEST_VERSIONS.md` before proposing version-specific behavior.
+2. Use engine selection table above to pick the target engine.
+3. Load the target engine `SKILL.md` and relevant `references/*` files — read the ones that match the task (indexing, migrations, replication, etc.).
+4. Provide an optimization or implementation plan that includes:
+   - specific change with rationale,
+   - indexing or schema decisions,
+   - migration safety (online vs offline),
    - rollback path.
+5. For production-impacting changes, include blast-radius assessment and rollout stages.
 
-## Engine wrappers
+## Cross-engine performance checklist
 
-- `engines/postgres/POWER.md`
-- `engines/mysql/POWER.md`
-- `engines/vitess/POWER.md`
-- `engines/neki/POWER.md`
-- `engines/mongodb/POWER.md`
-- `engines/sqlite/POWER.md`
-- `engines/supabase/POWER.md`
-- `engines/redis/POWER.md`
+- **Indexing**: add indexes only for real predicates and sort patterns. Drop unused indexes — they penalize writes.
+- **Pagination**: prefer keyset/seek for deep or high-throughput pagination. Reserve offset for shallow interactive pages only.
+- **Measurement**: compare before/after plans with engine-native explain tooling (`EXPLAIN ANALYZE`, `VEXPLAIN`, `explain()`). Validate with realistic cardinality.
+- **Safety**: no destructive data/schema operations without explicit user confirmation. Always include rollback/recovery steps.

package/Ai Agent Workflow/powers/datadog-automation/POWER.md

@@ -0,0 +1,238 @@
+````markdown
+---
+inclusion: manual
+name: datadog-automation
+description: "Automate Datadog tasks via Rube MCP (Composio): query metrics, search logs, manage monitors/dashboards, create events and downtimes. Always search tools first for current schemas."
+requires:
+  mcp: [rube]
+---
+
+# Datadog Automation via Rube MCP
+
+Automate Datadog monitoring and observability operations through Composio's Datadog toolkit via Rube MCP.
+
+## Prerequisites
+
+- Rube MCP must be connected (RUBE_SEARCH_TOOLS available)
+- Active Datadog connection via `RUBE_MANAGE_CONNECTIONS` with toolkit `datadog`
+- Always call `RUBE_SEARCH_TOOLS` first to get current tool schemas
+
+## Setup
+
+**Get Rube MCP**: Add `https://rube.app/mcp` as an MCP server in your client configuration. No API keys needed — just add the endpoint and it works.
+
+
+1. Verify Rube MCP is available by confirming `RUBE_SEARCH_TOOLS` responds
+2. Call `RUBE_MANAGE_CONNECTIONS` with toolkit `datadog`
+3. If connection is not ACTIVE, follow the returned auth link to complete Datadog authentication
+4. Confirm connection status shows ACTIVE before running any workflows
+
+## Core Workflows
+
+### 1. Query and Explore Metrics
+
+**When to use**: User wants to query metric data or list available metrics
+
+**Tool sequence**:
+1. `DATADOG_LIST_METRICS` - List available metric names [Optional]
+2. `DATADOG_QUERY_METRICS` - Query metric time series data [Required]
+
+**Key parameters**:
+- `query`: Datadog metric query string (e.g., `avg:system.cpu.user{host:web01}`)
+- `from`: Start timestamp (Unix epoch seconds)
+- `to`: End timestamp (Unix epoch seconds)
+- `q`: Search string for listing metrics
+
+**Pitfalls**:
+- Query syntax follows Datadog's metric query format: `aggregation:metric_name{tag_filters}`
+- `from` and `to` are Unix epoch timestamps in seconds, not milliseconds
+- Valid aggregations: `avg`, `sum`, `min`, `max`, `count`
+- Tag filters use curly braces: `{host:web01,env:prod}`
+- Time range should not exceed Datadog's retention limits for the metric type
+
+### 2. Search and Analyze Logs
+
+**When to use**: User wants to search log entries or list log indexes
+
+**Tool sequence**:
+1. `DATADOG_LIST_LOG_INDEXES` - List available log indexes [Optional]
+2. `DATADOG_SEARCH_LOGS` - Search logs with query and filters [Required]
+
+**Key parameters**:
+- `query`: Log search query using Datadog log query syntax
+- `from`: Start time (ISO 8601 or Unix timestamp)
+- `to`: End time (ISO 8601 or Unix timestamp)
+- `sort`: Sort order ('asc' or 'desc')
+- `limit`: Number of log entries to return
+
+**Pitfalls**:
+- Log queries use Datadog's log search syntax: `service:web status:error`
+- Search is limited to retained logs within the configured retention period
+- Large result sets require pagination; check for cursor/page tokens
+- Log indexes control routing and retention; filter by index if known
+
+### 3. Manage Monitors
+
+**When to use**: User wants to create, update, mute, or inspect monitors
+
+**Tool sequence**:
+1. `DATADOG_LIST_MONITORS` - List all monitors with filters [Required]
+2. `DATADOG_GET_MONITOR` - Get specific monitor details [Optional]
+3. `DATADOG_CREATE_MONITOR` - Create a new monitor [Optional]
+4. `DATADOG_UPDATE_MONITOR` - Update monitor configuration [Optional]
+5. `DATADOG_MUTE_MONITOR` - Silence a monitor temporarily [Optional]
+6. `DATADOG_UNMUTE_MONITOR` - Re-enable a muted monitor [Optional]
+
+**Key parameters**:
+- `monitor_id`: Numeric monitor ID
+- `name`: Monitor display name
+- `type`: Monitor type ('metric alert', 'service check', 'log alert', 'query alert', etc.)
+- `query`: Monitor query defining the alert condition
+- `message`: Notification message with @mentions
+- `tags`: Array of tag strings
+- `thresholds`: Alert threshold values (`critical`, `warning`, `ok`)
+
+**Pitfalls**:
+- Monitor `type` must match the query type; mismatches cause creation failures
+- `message` supports @mentions for notifications (e.g., `@slack-channel`, `@pagerduty`)
+- Thresholds vary by monitor type; metric monitors need `critical` at minimum
+- Muting a monitor suppresses notifications but the monitor still evaluates
+- Monitor IDs are numeric integers
+
+### 4. Manage Dashboards
+
+**When to use**: User wants to list, view, update, or delete dashboards
+
+**Tool sequence**:
+1. `DATADOG_LIST_DASHBOARDS` - List all dashboards [Required]
+2. `DATADOG_GET_DASHBOARD` - Get full dashboard definition [Optional]
+3. `DATADOG_UPDATE_DASHBOARD` - Update dashboard layout or widgets [Optional]
+4. `DATADOG_DELETE_DASHBOARD` - Remove a dashboard (irreversible) [Optional]
+
+**Key parameters**:
+- `dashboard_id`: Dashboard identifier string
+- `title`: Dashboard title
+- `layout_type`: 'ordered' (grid) or 'free' (freeform positioning)
+- `widgets`: Array of widget definition objects
+- `description`: Dashboard description
+
+**Pitfalls**:
+- Dashboard IDs are alphanumeric strings (e.g., 'abc-def-ghi'), not numeric
+- `layout_type` cannot be changed after creation; must recreate the dashboard
+- Widget definitions are complex nested objects; get existing dashboard first to understand structure
+- DELETE is permanent; there is no undo
+
+### 5. Create Events and Manage Downtimes
+
+**When to use**: User wants to post events or schedule maintenance downtimes
+
+**Tool sequence**:
+1. `DATADOG_LIST_EVENTS` - List existing events [Optional]
+2. `DATADOG_CREATE_EVENT` - Post a new event [Required]
+3. `DATADOG_CREATE_DOWNTIME` - Schedule a maintenance downtime [Optional]
+
+**Key parameters for events**:
+- `title`: Event title
+- `text`: Event body text (supports markdown)
+- `alert_type`: Event severity ('error', 'warning', 'info', 'success')
+- `tags`: Array of tag strings
+
+**Key parameters for downtimes**:
+- `scope`: Tag scope for the downtime (e.g., `host:web01`)
+- `start`: Start time (Unix epoch)
+- `end`: End time (Unix epoch; omit for indefinite)
+- `message`: Downtime description
+- `monitor_id`: Specific monitor to downtime (optional, omit for scope-based)
+
+**Pitfalls**:
+- Event `text` supports Datadog's markdown format including @mentions
+- Downtimes scope uses tag syntax: `host:web01`, `env:staging`
+- Omitting `end` creates an indefinite downtime; always set an end time for maintenance
+- Downtime `monitor_id` narrows to a single monitor; scope applies to all matching monitors
+
+### 6. Manage Hosts and Traces
+
+**When to use**: User wants to list infrastructure hosts or inspect distributed traces
+
+**Tool sequence**:
+1. `DATADOG_LIST_HOSTS` - List all reporting hosts [Required]
+2. `DATADOG_GET_TRACE_BY_ID` - Get a specific distributed trace [Optional]
+
+**Key parameters**:
+- `filter`: Host search filter string
+- `sort_field`: Sort hosts by field (e.g., 'name', 'apps', 'cpu')
+- `sort_dir`: Sort direction ('asc' or 'desc')
+- `trace_id`: Distributed trace ID for trace lookup
+
+**Pitfalls**:
+- Host list includes all hosts reporting to Datadog within the retention window
+- Trace IDs are long numeric strings; ensure exact match
+- Hosts that stop reporting are retained for a configured period before removal
+
+## Common Patterns
+
+### Monitor Query Syntax
+
+**Metric alerts**:
+```
+avg(last_5m):avg:system.cpu.user{env:prod} > 90
+```
+
+**Log alerts**:
+```
+logs("service:web status:error").index("main").rollup("count").last("5m") > 10
+```
+
+### Tag Filtering
+
+- Tags use `key:value` format: `host:web01`, `env:prod`, `service:api`
+- Multiple tags: `{host:web01,env:prod}` (AND logic)
+- Wildcard: `host:web*`
+
+### Pagination
+
+- Use `page` and `page_size` or offset-based pagination depending on endpoint
+- Check response for total count to determine if more pages exist
+- Continue until all results are retrieved
+
+## Known Pitfalls
+
+**Timestamps**:
+- Most endpoints use Unix epoch seconds (not milliseconds)
+- Some endpoints accept ISO 8601; check tool schema
+- Time ranges should be reasonable (not years of data)
+
+**Query Syntax**:
+- Metric queries: `aggregation:metric{tags}`
+- Log queries: `field:value` pairs
+- Monitor queries vary by type; check Datadog documentation
+
+**Rate Limits**:
+- Datadog API has per-endpoint rate limits
+- Implement backoff on 429 responses
+- Batch operations where possible
+
+## Quick Reference
+
+| Task | Tool Slug | Key Params |
+|------|-----------|------------|
+| Query metrics | DATADOG_QUERY_METRICS | query, from, to |
+| List metrics | DATADOG_LIST_METRICS | q |
+| Search logs | DATADOG_SEARCH_LOGS | query, from, to, limit |
+| List log indexes | DATADOG_LIST_LOG_INDEXES | (none) |
+| List monitors | DATADOG_LIST_MONITORS | tags |
+| Get monitor | DATADOG_GET_MONITOR | monitor_id |
+| Create monitor | DATADOG_CREATE_MONITOR | name, type, query, message |
+| Update monitor | DATADOG_UPDATE_MONITOR | monitor_id |
+| Mute monitor | DATADOG_MUTE_MONITOR | monitor_id |
+| Unmute monitor | DATADOG_UNMUTE_MONITOR | monitor_id |
+| List dashboards | DATADOG_LIST_DASHBOARDS | (none) |
+| Get dashboard | DATADOG_GET_DASHBOARD | dashboard_id |
+| Update dashboard | DATADOG_UPDATE_DASHBOARD | dashboard_id, title, widgets |
+| Delete dashboard | DATADOG_DELETE_DASHBOARD | dashboard_id |
+| List events | DATADOG_LIST_EVENTS | start, end |
+| Create event | DATADOG_CREATE_EVENT | title, text, alert_type |
+| Create downtime | DATADOG_CREATE_DOWNTIME | scope, start, end |
+| List hosts | DATADOG_LIST_HOSTS | filter, sort_field |
+| Get trace | DATADOG_GET_TRACE_BY_ID | trace_id |
+````