@cubis/foundry 0.3.10 → 0.3.12

package/Ai Agent Workflow/powers/semgrep/POWER.md

@@ -0,0 +1,420 @@
+````markdown
+---
+inclusion: manual
+name: semgrep
+description: Run Semgrep static analysis scan on a codebase using parallel subagents. Automatically
+  detects and uses Semgrep Pro for cross-file analysis when available. Use when asked to scan
+  code for vulnerabilities, run a security audit with Semgrep, find bugs, or perform
+  static analysis. Spawns parallel workers for multi-language codebases and triage.
+allowed-tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+  - Write
+  - Task
+  - AskUserQuestion
+  - TaskCreate
+  - TaskList
+  - TaskUpdate
+  - WebFetch
+---
+
+# Semgrep Security Scan
+
+Run a complete Semgrep scan with automatic language detection, parallel execution via Task subagents, and parallel triage. Automatically uses Semgrep Pro for cross-file taint analysis when available.
+
+## Prerequisites
+
+**Required:** Semgrep CLI
+
+```bash
+semgrep --version
+```
+
+If not installed, see [Semgrep installation docs](https://semgrep.dev/docs/getting-started/).
+
+**Optional:** Semgrep Pro (for cross-file analysis and Pro languages)
+
+```bash
+# Check if Semgrep Pro engine is installed
+semgrep --pro --validate --config p/default 2>/dev/null && echo "Pro available" || echo "OSS only"
+
+# If logged in, install/update Pro Engine
+semgrep install-semgrep-pro
+```
+
+Pro enables: cross-file taint tracking, inter-procedural analysis, and additional languages (Apex, C#, Elixir).
+
+## When to Use
+
+- Security audit of a codebase
+- Finding vulnerabilities before code review
+- Scanning for known bug patterns
+- First-pass static analysis
+
+## When NOT to Use
+
+- Binary analysis → Use binary analysis tools
+- Already have Semgrep CI configured → Use existing pipeline
+- Need cross-file analysis but no Pro license → Consider CodeQL as alternative
+- Creating custom Semgrep rules → Use `semgrep-rule-creator` skill
+- Porting existing rules to other languages → Use `semgrep-rule-variant-creator` skill
+
+---
+
+## Orchestration Architecture
+
+This skill uses **parallel Task subagents** for maximum efficiency:
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│ MAIN AGENT                                                      │
+│ 1. Detect languages + check Pro availability                    │
+│ 2. Select rulesets based on detection (ref: rulesets.md)        │
+│ 3. Present plan + rulesets, get approval [⛔ HARD GATE]         │
+│ 4. Spawn parallel scan Tasks (with approved rulesets)           │
+│ 5. Spawn parallel triage Tasks                                  │
+│ 6. Collect and report results                                   │
+└─────────────────────────────────────────────────────────────────┘
+          │ Step 4                           │ Step 5
+          ▼                                  ▼
+┌─────────────────┐              ┌─────────────────┐
+│ Scan Tasks      │              │ Triage Tasks    │
+│ (parallel)      │              │ (parallel)      │
+├─────────────────┤              ├─────────────────┤
+│ Python scanner  │              │ Python triager  │
+│ JS/TS scanner   │              │ JS/TS triager   │
+│ Go scanner      │              │ Go triager      │
+│ Docker scanner  │              │ Docker triager  │
+└─────────────────┘              └─────────────────┘
+```
+
+---
+
+## Workflow Enforcement via Task System
+
+This skill uses the **Task system** to enforce workflow compliance. On invocation, create these tasks:
+
+```
+TaskCreate: "Detect languages and Pro availability" (Step 1)
+TaskCreate: "Select rulesets based on detection" (Step 2) - blockedBy: Step 1
+TaskCreate: "Present plan with rulesets, get approval" (Step 3) - blockedBy: Step 2
+TaskCreate: "Execute scans with approved rulesets" (Step 4) - blockedBy: Step 3
+TaskCreate: "Triage findings" (Step 5) - blockedBy: Step 4
+TaskCreate: "Report results" (Step 6) - blockedBy: Step 5
+```
+
+### Mandatory Gates
+
+| Task | Gate Type | Cannot Proceed Until |
+|------|-----------|---------------------|
+| Step 3: Get approval | **HARD GATE** | User explicitly approves rulesets + plan |
+| Step 5: Triage | **SOFT GATE** | All scan JSON files exist |
+
+**Step 3 is a HARD GATE**: Mark as `completed` ONLY after user says "yes", "proceed", "approved", or equivalent.
+
+### Task Flow Example
+
+```
+1. Create all 6 tasks with dependencies
+2. TaskUpdate Step 1 → in_progress, execute detection
+3. TaskUpdate Step 1 → completed
+4. TaskUpdate Step 2 → in_progress, select rulesets
+5. TaskUpdate Step 2 → completed
+6. TaskUpdate Step 3 → in_progress, present plan with rulesets
+7. STOP: Wait for user response (may modify rulesets)
+8. User approves → TaskUpdate Step 3 → completed
+9. TaskUpdate Step 4 → in_progress (now unblocked)
+... continue workflow
+```
+
+---
+
+## Workflow
+
+### Step 1: Detect Languages and Pro Availability (Main Agent)
+
+```bash
+# Check if Semgrep Pro is available (non-destructive check)
+SEMGREP_PRO=false
+if semgrep --pro --validate --config p/default 2>/dev/null; then
+  SEMGREP_PRO=true
+  echo "Semgrep Pro: AVAILABLE (cross-file analysis enabled)"
+else
+  echo "Semgrep Pro: NOT AVAILABLE (OSS mode, single-file analysis)"
+fi
+
+# Find languages by file extension
+fd -t f -e py -e js -e ts -e jsx -e tsx -e go -e rb -e java -e php -e c -e cpp -e rs | \
+  sed 's/.*\.//' | sort | uniq -c | sort -rn
+
+# Check for frameworks/technologies
+ls -la package.json pyproject.toml Gemfile go.mod Cargo.toml pom.xml 2>/dev/null
+fd -t f "Dockerfile" "docker-compose" ".tf" "*.yaml" "*.yml" | head -20
+```
+
+Map findings to categories:
+
+| Detection | Category |
+|-----------|----------|
+| `.py`, `pyproject.toml` | Python |
+| `.js`, `.ts`, `package.json` | JavaScript/TypeScript |
+| `.go`, `go.mod` | Go |
+| `.rb`, `Gemfile` | Ruby |
+| `.java`, `pom.xml` | Java |
+| `.php` | PHP |
+| `.c`, `.cpp` | C/C++ |
+| `.rs`, `Cargo.toml` | Rust |
+| `Dockerfile` | Docker |
+| `.tf` | Terraform |
+| k8s manifests | Kubernetes |
+
+### Step 2: Select Rulesets Based on Detection
+
+Using the detected languages and frameworks from Step 1, select rulesets by following the **Ruleset Selection Algorithm** in [rulesets.md]({baseDir}/references/rulesets.md).
+
+The algorithm covers:
+1. Security baseline (always included)
+2. Language-specific rulesets
+3. Framework rulesets (if detected)
+4. Infrastructure rulesets
+5. **Required** third-party rulesets (Trail of Bits, 0xdea, Decurity - NOT optional)
+6. Registry verification
+
+**Output:** Structured JSON passed to Step 3 for user review:
+
+```json
+{
+  "baseline": ["p/security-audit", "p/secrets"],
+  "python": ["p/python", "p/django"],
+  "javascript": ["p/javascript", "p/react", "p/nodejs"],
+  "docker": ["p/dockerfile"],
+  "third_party": ["https://github.com/trailofbits/semgrep-rules"]
+}
+```
+
+### Step 3: CRITICAL GATE - Present Plan and Get Approval
+
+> **⛔ MANDATORY CHECKPOINT - DO NOT SKIP**
+>
+> This step requires explicit user approval before proceeding.
+> User may modify rulesets before approving.
+
+Present plan to user with **explicit ruleset listing**:
+
+```
+## Semgrep Scan Plan
+
+**Target:** /path/to/codebase
+**Output directory:** ./semgrep-results-001/
+**Engine:** Semgrep Pro (cross-file analysis) | Semgrep OSS (single-file)
+
+### Detected Languages/Technologies:
+- Python (1,234 files) - Django framework detected
+- JavaScript (567 files) - React detected
+- Dockerfile (3 files)
+
+### Rulesets to Run:
+
+**Security Baseline (always included):**
+- [x] `p/security-audit` - Comprehensive security rules
+- [x] `p/secrets` - Hardcoded credentials, API keys
+
+**Python (1,234 files):**
+- [x] `p/python` - Python security patterns
+- [x] `p/django` - Django-specific vulnerabilities
+
+**JavaScript (567 files):**
+- [x] `p/javascript` - JavaScript security patterns
+- [x] `p/react` - React-specific issues
+- [x] `p/nodejs` - Node.js server-side patterns
+
+**Docker (3 files):**
+- [x] `p/dockerfile` - Dockerfile best practices
+
+**Third-party (auto-included for detected languages):**
+- [x] Trail of Bits rules - https://github.com/trailofbits/semgrep-rules
+
+**Available but not selected:**
+- [ ] `p/owasp-top-ten` - OWASP Top 10 (overlaps with security-audit)
+
+### Execution Strategy:
+- Spawn 3 parallel scan Tasks (Python, JavaScript, Docker)
+- Total rulesets: 9
+- [If Pro] Cross-file taint tracking enabled
+
+**Want to modify rulesets?** Tell me which to add or remove.
+**Ready to scan?** Say "proceed" or "yes".
+```
+
+**⛔ STOP: Await explicit user approval**
+
+After presenting the plan:
+
+1. **If user wants to modify rulesets:**
+   - Add requested rulesets to the appropriate category
+   - Remove requested rulesets
+   - Re-present the updated plan
+   - Return to waiting for approval
+
+2. **Use AskUserQuestion** if user hasn't responded:
+   ```
+   "I've prepared the scan plan with 9 rulesets (including Trail of Bits). Proceed with scanning?"
+   Options: ["Yes, run scan", "Modify rulesets first"]
+   ```
+
+3. **Valid approval responses:**
+   - "yes", "proceed", "approved", "go ahead", "looks good", "run it"
+
+4. **Mark task completed** only after approval with final rulesets confirmed
+
+5. **Do NOT treat as approval:**
+   - User's original request ("scan this codebase")
+   - Silence / no response
+   - Questions about the plan
+
+### Pre-Scan Checklist
+
+Before marking Step 3 complete, verify:
+- [ ] Target directory shown to user
+- [ ] Engine type (Pro/OSS) displayed
+- [ ] Languages detected and listed
+- [ ] **All rulesets explicitly listed with checkboxes**
+- [ ] User given opportunity to modify rulesets
+- [ ] User explicitly approved (quote their confirmation)
+- [ ] **Final ruleset list captured for Step 4**
+
+### Step 4: Spawn Parallel Scan Tasks
+
+Create output directory with run number to avoid collisions, then spawn Tasks with **approved rulesets from Step 3**:
+
+```bash
+# Find next available run number
+LAST=$(ls -d semgrep-results-[0-9][0-9][0-9] 2>/dev/null | sort | tail -1 | grep -o '[0-9]*$' || true)
+NEXT_NUM=$(printf "%03d" $(( ${LAST:-0} + 1 )))
+OUTPUT_DIR="semgrep-results-${NEXT_NUM}"
+mkdir -p "$OUTPUT_DIR"
+echo "Output directory: $OUTPUT_DIR"
+```
+
+**Spawn N Tasks in a SINGLE message** (one per language category) using `subagent_type: Bash`.
+
+Use the scanner task prompt template from [scanner-task-prompt.md]({baseDir}/references/scanner-task-prompt.md).
+
+**Example - 3 Language Scan (with approved rulesets):**
+
+Spawn these 3 Tasks in a SINGLE message:
+
+1. **Task: Python Scanner**
+   - Approved rulesets: p/python, p/django, p/security-audit, p/secrets, https://github.com/trailofbits/semgrep-rules
+   - Output: semgrep-results-001/python-*.json
+
+2. **Task: JavaScript Scanner**
+   - Approved rulesets: p/javascript, p/react, p/nodejs, p/security-audit, p/secrets, https://github.com/trailofbits/semgrep-rules
+   - Output: semgrep-results-001/js-*.json
+
+3. **Task: Docker Scanner**
+   - Approved rulesets: p/dockerfile
+   - Output: semgrep-results-001/docker-*.json
+
+### Step 5: Spawn Parallel Triage Tasks
+
+After scan Tasks complete, spawn triage Tasks using `subagent_type: general-purpose` (triage requires reading code context, not just running commands).
+
+Use the triage task prompt template from [triage-task-prompt.md]({baseDir}/references/triage-task-prompt.md).
+
+### Step 6: Collect Results (Main Agent)
+
+After all Tasks complete, generate merged SARIF and report:
+
+**Generate merged SARIF with only triaged true positives:**
+
+```bash
+uv run {baseDir}/scripts/merge_triaged_sarif.py [OUTPUT_DIR]
+```
+
+This script:
+1. Attempts to use [SARIF Multitool](https://www.npmjs.com/package/@microsoft/sarif-multitool) for merging (if `npx` is available)
+2. Falls back to pure Python merge if Multitool unavailable
+3. Reads all `*-triage.json` files to extract true positive findings
+4. Filters merged SARIF to include only triaged true positives
+5. Writes output to `[OUTPUT_DIR]/findings-triaged.sarif`
+
+**Optional: Install SARIF Multitool for better merge quality:**
+
+```bash
+npm install -g @microsoft/sarif-multitool
+```
+
+**Report to user:**
+
+```
+## Semgrep Scan Complete
+
+**Scanned:** 1,804 files
+**Rulesets used:** 9 (including Trail of Bits)
+**Total raw findings:** 156
+**After triage:** 32 true positives
+
+### By Severity:
+- ERROR: 5
+- WARNING: 18
+- INFO: 9
+
+### By Category:
+- SQL Injection: 3
+- XSS: 7
+- Hardcoded secrets: 2
+- Insecure configuration: 12
+- Code quality: 8
+
+Results written to:
+- semgrep-results-001/findings-triaged.sarif (SARIF, true positives only)
+- semgrep-results-001/*-triage.json (triage details per language)
+- semgrep-results-001/*.json (raw scan results)
+- semgrep-results-001/*.sarif (raw SARIF per ruleset)
+```
+
+---
+
+## Common Mistakes
+
+| Mistake | Correct Approach |
+|---------|------------------|
+| Running without `--metrics=off` | Always use `--metrics=off` to prevent telemetry |
+| Running rulesets sequentially | Run in parallel with `&` and `wait` |
+| Not scoping rulesets to languages | Use `--include="*.py"` for language-specific rules |
+| Reporting raw findings without triage | Always triage to remove false positives |
+| Single-threaded for multi-lang | Spawn parallel Tasks per language |
+| Sequential Tasks | Spawn all Tasks in SINGLE message for parallelism |
+| Using OSS when Pro is available | Check login status; use `--pro` for deeper analysis |
+| Assuming Pro is unavailable | Always check with login detection before scanning |
+
+## Limitations
+
+1. **OSS mode:** Cannot track data flow across files (login with `semgrep login` and run `semgrep install-semgrep-pro` to enable)
+2. **Pro mode:** Cross-file analysis uses `-j 1` (single job) which is slower per ruleset, but parallel rulesets compensate
+3. Triage requires reading code context - parallelized via Tasks
+4. Some false positive patterns require human judgment
+
+## Rationalizations to Reject
+
+| Shortcut | Why It's Wrong |
+|----------|----------------|
+| "User asked for scan, that's approval" | Original request ≠ plan approval; user must confirm specific parameters. Present plan, use AskUserQuestion, await explicit "yes" |
+| "Step 3 task is blocking, just mark complete" | Lying about task status defeats enforcement. Only mark complete after real approval |
+| "I already know what they want" | Assumptions cause scanning wrong directories/rulesets. Present plan with all parameters for verification |
+| "Just use default rulesets" | User must see and approve exact rulesets before scan |
+| "Add extra rulesets without asking" | Modifying approved list without consent breaks trust |
+| "Skip showing ruleset list" | User can't make informed decision without seeing what will run |
+| "Third-party rulesets are optional" | Trail of Bits, 0xdea, Decurity rules catch vulnerabilities not in official registry - they are REQUIRED when language matches |
+| "Skip triage, report everything" | Floods user with noise; true issues get lost |
+| "Run one ruleset at a time" | Wastes time; parallel execution is faster |
+| "Use --config auto" | Sends metrics; less control over rulesets |
+| "Triage later" | Findings without context are harder to evaluate |
+| "One Task at a time" | Defeats parallelism; spawn all Tasks together |
+| "Pro is too slow, skip --pro" | Cross-file analysis catches 250% more true positives; worth the time |
+| "Don't bother checking for Pro" | Missing Pro = missing critical cross-file vulnerabilities |
+| "OSS is good enough" | OSS misses inter-file taint flows; always prefer Pro when available |
+````

package/Ai Agent Workflow/powers/semgrep/SKILL.md

@@ -170,7 +170,7 @@ Map findings to categories:
 
 ### Step 2: Select Rulesets Based on Detection
 
-Using the detected languages and frameworks from Step 1, select rulesets by following the **Ruleset Selection Algorithm** in [rulesets.md]({baseDir}/steering/rulesets.md).
+Using the detected languages and frameworks from Step 1, select rulesets by following the **Ruleset Selection Algorithm** in [rulesets.md]({baseDir}/references/rulesets.md).
 
 The algorithm covers:
 1. Security baseline (always included)
@@ -298,7 +298,7 @@ echo "Output directory: $OUTPUT_DIR"
 
 **Spawn N Tasks in a SINGLE message** (one per language category) using `subagent_type: Bash`.
 
-Use the scanner task prompt template from [scanner-task-prompt.md]({baseDir}/steering/scanner-task-prompt.md).
+Use the scanner task prompt template from [scanner-task-prompt.md]({baseDir}/references/scanner-task-prompt.md).
 
 **Example - 3 Language Scan (with approved rulesets):**
 
@@ -320,7 +320,7 @@ Spawn these 3 Tasks in a SINGLE message:
 
 After scan Tasks complete, spawn triage Tasks using `subagent_type: general-purpose` (triage requires reading code context, not just running commands).
 
-Use the triage task prompt template from [triage-task-prompt.md]({baseDir}/steering/triage-task-prompt.md).
+Use the triage task prompt template from [triage-task-prompt.md]({baseDir}/references/triage-task-prompt.md).
 
 ### Step 6: Collect Results (Main Agent)
 

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

@@ -0,0 +1,235 @@
+````markdown
+---
+inclusion: manual
+name: sentry-automation
+description: "Automate Sentry tasks via Rube MCP (Composio): manage issues/events, configure alerts, track releases, monitor projects and teams. Always search tools first for current schemas."
+requires:
+  mcp: [rube]
+---
+
+# Sentry Automation via Rube MCP
+
+Automate Sentry error tracking and monitoring operations through Composio's Sentry toolkit via Rube MCP.
+
+## Prerequisites
+
+- Rube MCP must be connected (RUBE_SEARCH_TOOLS available)
+- Active Sentry connection via `RUBE_MANAGE_CONNECTIONS` with toolkit `sentry`
+- 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 `sentry`
+3. If connection is not ACTIVE, follow the returned auth link to complete Sentry OAuth
+4. Confirm connection status shows ACTIVE before running any workflows
+
+## Core Workflows
+
+### 1. Investigate Issues
+
+**When to use**: User wants to find, inspect, or triage error issues
+
+**Tool sequence**:
+1. `SENTRY_LIST_AN_ORGANIZATIONS_ISSUES` - List issues across the organization [Required]
+2. `SENTRY_GET_ORGANIZATION_ISSUE_DETAILS` - Get detailed info on a specific issue [Optional]
+3. `SENTRY_LIST_AN_ISSUES_EVENTS` - View individual error events for an issue [Optional]
+4. `SENTRY_RETRIEVE_AN_ISSUE_EVENT` - Get full event details with stack trace [Optional]
+5. `SENTRY_RETRIEVE_ISSUE_TAG_DETAILS` - Inspect tag distribution for an issue [Optional]
+
+**Key parameters**:
+- `organization_id_or_slug`: Organization identifier
+- `issue_id`: Numeric issue ID
+- `query`: Search query (e.g., `is:unresolved`, `assigned:me`, `browser:Chrome`)
+- `sort`: Sort order (`date`, `new`, `freq`, `priority`)
+- `statsPeriod`: Time window for stats (`24h`, `14d`, etc.)
+
+**Pitfalls**:
+- `organization_id_or_slug` is the org slug (e.g., 'my-org'), not the display name
+- Issue IDs are numeric; do not confuse with event IDs which are UUIDs
+- Query syntax uses Sentry's search format: `is:unresolved`, `assigned:me`, `!has:release`
+- Events within an issue can have different stack traces; inspect individual events for details
+
+### 2. Manage Project Issues
+
+**When to use**: User wants to view issues scoped to a specific project
+
+**Tool sequence**:
+1. `SENTRY_RETRIEVE_ORGANIZATION_PROJECTS` - List projects to find project slug [Prerequisite]
+2. `SENTRY_RETRIEVE_PROJECT_ISSUES_LIST` - List issues for a specific project [Required]
+3. `SENTRY_RETRIEVE_ISSUE_EVENTS_BY_ID` - Get events for a specific issue [Optional]
+
+**Key parameters**:
+- `organization_id_or_slug`: Organization identifier
+- `project_id_or_slug`: Project identifier
+- `query`: Search filter string
+- `statsPeriod`: Stats time window
+
+**Pitfalls**:
+- Project slugs are different from project display names
+- Always resolve project names to slugs via RETRIEVE_ORGANIZATION_PROJECTS first
+- Project-scoped issue lists may have different pagination than org-scoped lists
+
+### 3. Configure Alert Rules
+
+**When to use**: User wants to create or manage alert rules for a project
+
+**Tool sequence**:
+1. `SENTRY_RETRIEVE_ORGANIZATION_PROJECTS` - Find project for the alert [Prerequisite]
+2. `SENTRY_RETRIEVE_PROJECT_RULES_BY_ORG_AND_PROJECT_ID` - List existing rules [Optional]
+3. `SENTRY_CREATE_PROJECT_RULE_FOR_ALERTS` - Create a new alert rule [Required]
+4. `SENTRY_CREATE_ORGANIZATION_ALERT_RULE` - Create org-level metric alert [Alternative]
+5. `SENTRY_UPDATE_ORGANIZATION_ALERT_RULES` - Update existing alert rules [Optional]
+6. `SENTRY_RETRIEVE_ALERT_RULE_DETAILS` - Inspect specific alert rule [Optional]
+7. `SENTRY_GET_PROJECT_RULE_DETAILS` - Get project-level rule details [Optional]
+
+**Key parameters**:
+- `name`: Alert rule name
+- `conditions`: Array of trigger conditions
+- `actions`: Array of actions to perform when triggered
+- `filters`: Array of event filters
+- `frequency`: How often to trigger (in minutes)
+- `actionMatch`: 'all', 'any', or 'none' for condition matching
+
+**Pitfalls**:
+- Project-level rules (CREATE_PROJECT_RULE) and org-level metric alerts (CREATE_ORGANIZATION_ALERT_RULE) are different
+- Conditions, actions, and filters use specific JSON schemas; check Sentry docs for valid types
+- `frequency` is in minutes; setting too low causes alert fatigue
+- `actionMatch` defaults may vary; explicitly set to avoid unexpected behavior
+
+### 4. Manage Releases
+
+**When to use**: User wants to create, track, or manage release versions
+
+**Tool sequence**:
+1. `SENTRY_LIST_ORGANIZATION_RELEASES` - List existing releases [Optional]
+2. `SENTRY_CREATE_RELEASE_FOR_ORGANIZATION` - Create a new release [Required]
+3. `SENTRY_UPDATE_RELEASE_DETAILS_FOR_ORGANIZATION` - Update release metadata [Optional]
+4. `SENTRY_CREATE_RELEASE_DEPLOY_FOR_ORG` - Record a deployment for a release [Optional]
+5. `SENTRY_UPLOAD_RELEASE_FILE_TO_ORGANIZATION` - Upload source maps or files [Optional]
+
+**Key parameters**:
+- `version`: Release version string (e.g., '1.0.0', commit SHA)
+- `projects`: Array of project slugs this release belongs to
+- `dateReleased`: Release timestamp (ISO 8601)
+- `environment`: Deployment environment name (e.g., 'production', 'staging')
+
+**Pitfalls**:
+- Release versions must be unique within an organization
+- Releases can span multiple projects; use the `projects` array
+- Deploying a release is separate from creating it; use CREATE_RELEASE_DEPLOY
+- Source map uploads require the release to exist first
+
+### 5. Monitor Organization and Teams
+
+**When to use**: User wants to view org structure, teams, or member lists
+
+**Tool sequence**:
+1. `SENTRY_GET_ORGANIZATION_DETAILS` or `SENTRY_GET_ORGANIZATION_BY_ID_OR_SLUG` - Get org info [Required]
+2. `SENTRY_LIST_TEAMS_IN_ORGANIZATION` - List all teams [Optional]
+3. `SENTRY_LIST_ORGANIZATION_MEMBERS` - List org members [Optional]
+4. `SENTRY_GET_PROJECT_LIST` - List all accessible projects [Optional]
+
+**Key parameters**:
+- `organization_id_or_slug`: Organization identifier
+- `cursor`: Pagination cursor for large result sets
+
+**Pitfalls**:
+- Organization slugs are URL-safe identifiers, not display names
+- Member lists may be paginated; follow cursor pagination
+- Team and member visibility depends on the authenticated user's permissions
+
+### 6. Manage Monitors (Cron Monitoring)
+
+**When to use**: User wants to update cron job monitoring configuration
+
+**Tool sequence**:
+1. `SENTRY_UPDATE_A_MONITOR` - Update monitor configuration [Required]
+
+**Key parameters**:
+- `organization_id_or_slug`: Organization identifier
+- `monitor_id_or_slug`: Monitor identifier
+- `name`: Monitor display name
+- `schedule`: Cron schedule expression or interval
+- `checkin_margin`: Grace period in minutes for late check-ins
+- `max_runtime`: Maximum expected runtime in minutes
+
+**Pitfalls**:
+- Monitor slugs are auto-generated from the name; use slug for API calls
+- Schedule changes take effect immediately
+- Missing check-ins trigger alerts after the margin period
+
+## Common Patterns
+
+### ID Resolution
+
+**Organization name -> Slug**:
+```
+1. Call SENTRY_GET_ORGANIZATION_DETAILS
+2. Extract slug field from response
+```
+
+**Project name -> Slug**:
+```
+1. Call SENTRY_RETRIEVE_ORGANIZATION_PROJECTS
+2. Find project by name, extract slug
+```
+
+### Pagination
+
+- Sentry uses cursor-based pagination with `Link` headers
+- Check response for cursor values
+- Pass cursor in next request until no more pages
+
+### Search Query Syntax
+
+- `is:unresolved` - Unresolved issues
+- `is:resolved` - Resolved issues
+- `assigned:me` - Assigned to current user
+- `assigned:team-slug` - Assigned to a team
+- `!has:release` - Issues without a release
+- `first-release:1.0.0` - Issues first seen in release
+- `times-seen:>100` - Seen more than 100 times
+- `browser:Chrome` - Filter by browser tag
+
+## Known Pitfalls
+
+**ID Formats**:
+- Organization: use slug (e.g., 'my-org'), not display name
+- Project: use slug (e.g., 'my-project'), not display name
+- Issue IDs: numeric integers
+- Event IDs: UUIDs (32-char hex strings)
+
+**Permissions**:
+- API token scopes must match the operations being performed
+- Organization-level operations require org-level permissions
+- Project-level operations require project access
+
+**Rate Limits**:
+- Sentry enforces per-organization rate limits
+- Implement backoff on 429 responses
+- Bulk operations should be staggered
+
+## Quick Reference
+
+| Task | Tool Slug | Key Params |
+|------|-----------|------------|
+| List org issues | SENTRY_LIST_AN_ORGANIZATIONS_ISSUES | organization_id_or_slug, query |
+| Get issue details | SENTRY_GET_ORGANIZATION_ISSUE_DETAILS | organization_id_or_slug, issue_id |
+| List issue events | SENTRY_LIST_AN_ISSUES_EVENTS | issue_id |
+| Get event details | SENTRY_RETRIEVE_AN_ISSUE_EVENT | organization_id_or_slug, event_id |
+| List project issues | SENTRY_RETRIEVE_PROJECT_ISSUES_LIST | organization_id_or_slug, project_id_or_slug |
+| List projects | SENTRY_RETRIEVE_ORGANIZATION_PROJECTS | organization_id_or_slug |
+| Get org details | SENTRY_GET_ORGANIZATION_DETAILS | organization_id_or_slug |
+| List teams | SENTRY_LIST_TEAMS_IN_ORGANIZATION | organization_id_or_slug |
+| List members | SENTRY_LIST_ORGANIZATION_MEMBERS | organization_id_or_slug |
+| Create alert rule | SENTRY_CREATE_PROJECT_RULE_FOR_ALERTS | organization_id_or_slug, project_id_or_slug |
+| Create metric alert | SENTRY_CREATE_ORGANIZATION_ALERT_RULE | organization_id_or_slug |
+| Create release | SENTRY_CREATE_RELEASE_FOR_ORGANIZATION | organization_id_or_slug, version |
+| Deploy release | SENTRY_CREATE_RELEASE_DEPLOY_FOR_ORG | organization_id_or_slug, version |
+| List releases | SENTRY_LIST_ORGANIZATION_RELEASES | organization_id_or_slug |
+| Update monitor | SENTRY_UPDATE_A_MONITOR | organization_id_or_slug, monitor_id_or_slug |
+````