@jmylchreest/aide-plugin 0.0.39 → 0.0.42

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jmylchreest/aide-plugin",
-  "version": "0.0.39",
+  "version": "0.0.42",
   "description": "aide plugin for OpenCode — multi-agent orchestration, memory, skills, and persistence",
   "type": "module",
   "main": "./src/opencode/index.ts",

package/skills/assess-findings/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: assess-findings
+description: Triage static analysis findings, assess merit, and accept noise or irrelevant items
+triggers:
+  - assess findings
+  - analyse findings
+  - analyze findings
+  - triage findings
+  - review findings
+  - accept findings
+  - dismiss findings
+  - clean up findings
+---
+
+# Assess Findings
+
+**Recommended model tier:** balanced (sonnet) - this skill requires reading code and making judgement calls
+
+Triage static analysis findings by reading the actual code, assessing whether each finding
+is genuine or noise, and accepting (dismissing) irrelevant ones using `findings_accept`.
+Accepted findings are hidden from future output by default.
+
+## Prerequisites
+
+- Findings must already exist. If `findings_stats` returns zero counts, tell the user to run:
+  ```bash
+  ./.aide/bin/aide findings run --path .
+  ```
+- The `findings_accept` tool must be available (provided by the aide MCP server).
+
+## Available Tools
+
+### Read-only (shared with `patterns` skill)
+
+| Tool              | Purpose                                                 |
+| ----------------- | ------------------------------------------------------- |
+| `findings_stats`  | Counts by analyzer and severity — start here            |
+| `findings_list`   | Browse findings with filters (analyzer, severity, file) |
+| `findings_search` | Full-text search across finding titles and details      |
+
+### Write (unique to this skill)
+
+| Tool              | Purpose                                             |
+| ----------------- | --------------------------------------------------- |
+| `findings_accept` | Mark findings as accepted/dismissed by ID or filter |
+
+### Code inspection
+
+| Tool           | Purpose                                             |
+| -------------- | --------------------------------------------------- |
+| `code_outline` | Get collapsed file structure to understand context  |
+| `Read`         | Read specific line ranges to evaluate finding merit |
+
+## Workflow
+
+### 1. Get the Landscape
+
+Call `findings_stats` to understand the scope:
+
+```
+findings_stats
+-> Returns: counts per analyzer (complexity, coupling, secrets, clones) and severity
+```
+
+If the user asked to focus on a specific analyzer or severity, note that and filter accordingly.
+Otherwise, work through all findings systematically.
+
+### 2. Prioritise Review Order
+
+Work through findings in this order:
+
+1. **Secrets** (critical first) — these need immediate attention; false positives are common in test fixtures
+2. **Complexity** (critical, then warning) — assess whether high complexity is inherent or decomposable
+3. **Clones** (all) — determine if duplication is extractable or structural boilerplate
+4. **Coupling** (all) — assess whether high fan-in/fan-out is expected for the file's role
+
+### 3. Assess Each Finding
+
+For each finding or group of related findings:
+
+1. **Read the finding details** — note the file, line range, and metric values
+2. **Read the actual code** — use `code_outline` first, then `Read` with offset/limit on the flagged section
+3. **Make a judgement call** using these criteria:
+
+#### Accept (dismiss) when:
+
+- **Complexity**: The function is inherently complex (CLI dispatch, protocol handling, state machines) and cannot be meaningfully decomposed without harming readability
+- **Clones**: The duplication is structural boilerplate (e.g., CLI subcommand wiring, store method patterns) where extraction would require framework-level abstraction
+- **Coupling**: High fan-in/fan-out is expected for the file's architectural role (e.g., a main entry point, a facade, a registry)
+- **Secrets**: The flagged string is a test fixture, example config, documentation placeholder, or env var name (not an actual secret)
+
+#### Keep (do NOT accept) when:
+
+- The finding points to a genuine problem that should be fixed
+- Complexity can be reduced by extracting helper functions
+- Duplication can be resolved by creating a shared utility
+- A coupling cycle exists that indicates poor module boundaries
+- A string looks like it could be a real secret or credential
+
+### 4. Accept Findings
+
+Use `findings_accept` to dismiss noise. You can accept:
+
+- **By IDs** — for individual findings after assessment:
+  ```
+  findings_accept ids=["finding-id-1", "finding-id-2"]
+  ```
+- **By filter** — for bulk dismissal of an entire category:
+  ```
+  findings_accept analyzer="clones" file="cmd/"
+  ```
+
+Always explain **why** each finding is being accepted before calling the tool.
+
+### 5. Report Summary
+
+After completing the triage, produce a summary:
+
+```markdown
+## Findings Triage Summary
+
+### Before
+
+- Total: X findings (Y critical, Z warnings, W info)
+
+### Accepted (Dismissed)
+
+- N findings accepted as noise/irrelevant
+  - Complexity: X (inherent complexity in [files])
+  - Clones: Y (structural boilerplate in [area])
+  - Coupling: Z (expected for [role])
+  - Secrets: W (test fixtures / placeholders)
+
+### Remaining (Genuine)
+
+- M findings require attention
+  - [List each with file:line and brief description]
+
+### Recommendations
+
+1. [Prioritised action items for genuine findings]
+```
+
+## Decision Criteria Reference
+
+| Analyzer   | Accept If                                                                                                                            | Keep If                                                         |
+| ---------- | ------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------- |
+| complexity | Cyclomatic complexity is inherent to the problem domain; function handles unavoidable branching (CLI dispatch, protocol negotiation) | Function can be decomposed into smaller, testable units         |
+| clones     | Duplication is cross-cutting boilerplate (CLI wiring, store CRUD patterns)                                                           | A shared utility or abstraction would reduce maintenance burden |
+| coupling   | File is an intentional integration point (main, facade, registry)                                                                    | Circular dependencies or unexpected transitive coupling exists  |
+| secrets    | Test fixture, documentation example, env var name, or placeholder                                                                    | Looks like a real credential, API key, or connection string     |
+
+## Failure Handling
+
+1. **No findings** — Tell user to run `./.aide/bin/aide findings run --path .` first
+2. **`findings_accept` not available** — The aide MCP server may not expose this tool; tell the user to update aide
+3. **Uncertain about a finding** — When in doubt, **keep it**. It's better to flag a false positive for human review than to dismiss a real issue
+4. **Large number of findings** — Work in batches by analyzer. Accept obvious noise first, then do detailed code review for borderline cases
+
+## Verification
+
+- [ ] Called `findings_stats` for baseline counts
+- [ ] Reviewed each finding category (secrets, complexity, clones, coupling)
+- [ ] Read actual code for every finding before accepting
+- [ ] Provided rationale for each acceptance
+- [ ] Produced summary with before/after counts
+- [ ] Remaining findings are genuinely actionable

package/skills/code-search/SKILL.md

@@ -86,6 +86,18 @@ Is the code indexed?
 → Returns: file count, symbol count, reference count
 ```
 
+### 6. Search Findings (`mcp__plugin_aide_aide__findings_search`)
+
+Search static analysis findings (complexity hotspots, secrets, code clones, coupling issues).
+
+**Example usage:**
+
+```
+Any complexity issues in src/auth?
+→ Uses findings_search tool with query "auth" or file filter
+→ Returns: findings with file, line, severity, description
+```
+
 ## Workflow
 
 1. **First, check if codebase is indexed:**

package/skills/git/SKILL.md

@@ -156,6 +156,16 @@ git worktree list | grep <worktree-path>
 git branch -a | grep <branch-name>
 ```
 
+## Change Context with Findings
+
+When reviewing diffs or preparing commits, use findings tools to understand the quality context of changed code:
+
+- `mcp__plugin_aide_aide__findings_search` — Search for known issues (complexity, secrets, clones) in changed files
+- `mcp__plugin_aide_aide__findings_list` — List all findings for a specific file to understand its health
+- `mcp__plugin_aide_aide__findings_stats` — Quick overview of finding counts across the project
+
+This helps surface pre-existing issues in files you're touching, and can inform whether a commit should also address nearby problems.
+
 ## Parallel Work Pattern
 
 For swarm mode or parallel features:

package/skills/memorise/SKILL.md

@@ -52,25 +52,31 @@ Use the `./.aide/bin/aide memory add` CLI command via Bash:
 ### Simple preference (global - injected at session start)
 
 ```bash
-./.aide/bin/aide memory add --category=learning --tags=preferences,colour,scope:global "User's favourite colour is blue"
+./.aide/bin/aide memory add --category=learning --tags=preferences,colour,scope:global,source:user "User's favourite colour is blue"
 ```
 
-### Technical learning (project-specific)
+### Technical learning (project-specific, verified)
 
 ```bash
-./.aide/bin/aide memory add --category=learning --tags=testing,vitest,project:myapp,session:abc12345 "Vitest requires .js extensions for ESM imports even for .ts files. Configure moduleResolution: NodeNext in tsconfig."
+./.aide/bin/aide memory add --category=learning --tags=testing,vitest,project:myapp,session:abc12345,source:discovered,verified:true "Vitest requires .js extensions for ESM imports even for .ts files. Configure moduleResolution: NodeNext in tsconfig."
 ```
 
 ### Session summary
 
 ```bash
-./.aide/bin/aide memory add --category=session --tags=auth,api,project:myapp,session:abc12345 "Implemented JWT auth with 15min access tokens, 7day refresh tokens in httpOnly cookies. Files: src/auth/jwt.ts, src/middleware/auth.ts, src/routes/auth.ts"
+./.aide/bin/aide memory add --category=session --tags=auth,api,project:myapp,session:abc12345,source:discovered "Implemented JWT auth with 15min access tokens, 7day refresh tokens in httpOnly cookies. Files: src/auth/jwt.ts, src/middleware/auth.ts, src/routes/auth.ts"
 ```
 
 ### Gotcha (global - applies everywhere)
 
 ```bash
-./.aide/bin/aide memory add --category=gotcha --tags=hooks,claude-code,scope:global "Hooks must not write to stderr - Claude Code interprets any stderr as error. Debug logging must go to files only."
+./.aide/bin/aide memory add --category=gotcha --tags=hooks,claude-code,scope:global,source:discovered,verified:true "Hooks must not write to stderr - Claude Code interprets any stderr as error. Debug logging must go to files only."
+```
+
+### Unverified external claim
+
+```bash
+./.aide/bin/aide memory add --category=learning --tags=api,stripe,project:myapp,source:user,verified:false "Stripe webhook signatures use HMAC-SHA256 with the whsec_ prefix."
 ```
 
 ## Instructions
@@ -78,18 +84,90 @@ Use the `./.aide/bin/aide memory add` CLI command via Bash:
 When the user invokes `/aide:memorise <something>`:
 
 1. Parse what they want to remember
-2. Determine the scope:
+2. **Verify factual claims before storing** (see [Verification Before Storage](#verification-before-storage-anti-poison) below)
+3. Determine the scope:
    - **User preference** (colour, style, etc.) → add `scope:global`
    - **Project-specific learning** → add `project:<project-name>,session:${CLAUDE_SESSION_ID:0:8}`
    - **Session summary** → add `project:<project-name>,session:${CLAUDE_SESSION_ID:0:8}`
-3. Choose appropriate category and descriptive tags
-4. Format the content concisely but completely
-5. Call `./.aide/bin/aide memory add` via Bash to store it
-6. **Verify success** - check exit code is 0 and output contains the memory ID
-7. Confirm what was stored
+4. Choose appropriate category and descriptive tags
+5. **Add provenance tags** (see [Provenance Tags](#provenance-tags) below)
+6. Format the content concisely but completely
+7. Call `./.aide/bin/aide memory add` via Bash to store it
+8. **Verify success** - check exit code is 0 and output contains the memory ID
+9. Confirm what was stored, including verification outcome
 
 Keep content concise - aim for 1-3 sentences unless it's a complex session summary.
 
+## Verification Before Storage (Anti-Poison)
+
+Memories persist across sessions and influence future behaviour. Storing incorrect information is **worse than storing nothing** — it creates compounding errors. Before storing any memory, verify its claims.
+
+### What to Verify
+
+| Claim Type                | Verification Method                                   | Example                                        |
+| ------------------------- | ----------------------------------------------------- | ---------------------------------------------- |
+| **File exists**           | Use Glob or Read to confirm                           | "Config is in src/config.ts"                   |
+| **Function/class exists** | Use Grep or code search                               | "Use `parseToken()` from auth.ts"              |
+| **Function signature**    | Read the file, check the actual signature             | "parseToken takes a string and returns Claims" |
+| **API behaviour**         | Check the implementation or tests                     | "The /users endpoint requires auth"            |
+| **Dependency/version**    | Check package.json, go.mod, etc.                      | "Project uses Vitest v2"                       |
+| **Build/test command**    | Confirm the script exists in package.json or Makefile | "Run `npm run test:e2e` for integration tests" |
+
+### What Does NOT Need Verification
+
+- **User preferences** — The user is the authority ("I prefer tabs over spaces")
+- **Session summaries** — Recap of what just happened in the current session
+- **Opinions/decisions** — Architectural choices made by the user ("We chose Postgres")
+- **External facts** — Things not checkable against the codebase ("React 19 uses...")
+
+### Verification Workflow
+
+```
+Is it a codebase claim (file, function, path, command, behaviour)?
+├── No → Store directly with source:user or source:stated
+└── Yes → Can you verify it right now?
+          ├── Yes → Verify it
+          │         ├── Correct → Store with verified:true
+          │         └── Wrong → Inform user, do NOT store. Offer corrected version.
+          └── No (e.g., external service, runtime behaviour)
+                    → Store with verified:false, note unverified
+```
+
+### Verification Rules
+
+1. **NEVER store a codebase claim without checking** — If the user says "the auth middleware is in src/middleware/auth.ts", confirm the file exists before memorising.
+2. **If verification fails, do NOT store** — Tell the user what you found instead and offer to store the corrected version.
+3. **If you cannot verify** (e.g., claim about runtime behaviour, external API), store it but tag with `verified:false`.
+4. **Err on the side of not storing** — A missing memory is recoverable; a wrong memory causes future errors.
+
+### Example: Verified vs Rejected
+
+**User says:** "Remember that the database schema is defined in db/schema.sql"
+
+**Verification steps:**
+
+1. Check: does `db/schema.sql` exist? → Use Glob to search
+2. If yes → Store with `verified:true`
+3. If no → "I checked and `db/schema.sql` doesn't exist. I found `database/migrations/` instead. Would you like me to store that instead?"
+
+## Provenance Tags
+
+Always include provenance tags to track the origin and verification status of memories:
+
+| Tag                 | Meaning                                  | When to Use                                      |
+| ------------------- | ---------------------------------------- | ------------------------------------------------ |
+| `source:user`       | User explicitly stated this              | User preferences, direct instructions            |
+| `source:discovered` | Agent discovered this by examining code  | File paths, function signatures, patterns found  |
+| `source:inferred`   | Agent inferred this from context         | Behaviour deduced from code, not directly stated |
+| `verified:true`     | Codebase claim was checked and confirmed | After successful verification                    |
+| `verified:false`    | Claim could not be verified against code | External facts, runtime behaviour                |
+
+### Provenance Rules
+
+- Every memory MUST have exactly one `source:` tag
+- Codebase claims MUST have a `verified:` tag
+- User preferences and opinions do NOT need `verified:` tags (user is authoritative)
+
 ## Failure Handling
 
 If `./.aide/bin/aide memory add` fails:

package/skills/patterns/SKILL.md

@@ -0,0 +1,182 @@
+---
+name: patterns
+description: Analyze codebase patterns, detect anti-patterns, and surface static analysis findings
+triggers:
+  - find patterns
+  - anti-patterns
+  - code smells
+  - complexity
+  - duplicated code
+  - clones
+  - secrets
+  - coupling
+  - static analysis
+  - code health
+---
+
+# Pattern Analysis
+
+**Recommended model tier:** balanced (sonnet) - this skill combines search with structured analysis
+
+Analyze codebase patterns using static analysis findings. Surface complexity hotspots, code
+duplication, coupling issues, and potential secrets. Use this skill to understand code health
+and identify areas that need attention.
+
+## Prerequisites
+
+Findings must be generated first by running analyzers via the CLI:
+
+```bash
+# Run all analyzers
+./.aide/bin/aide findings run --path .
+
+# Run specific analyzers
+./.aide/bin/aide findings run --path . --analyzer complexity
+./.aide/bin/aide findings run --path . --analyzer coupling
+./.aide/bin/aide findings run --path . --analyzer secrets
+./.aide/bin/aide findings run --path . --analyzer clones
+```
+
+**Binary location:** The aide binary is at `.aide/bin/aide`. If it's on your `$PATH`, you can use `aide` directly.
+
+## Available Tools
+
+### 1. Search Findings (`mcp__plugin_aide_aide__findings_search`)
+
+Full-text search across all findings. Supports Bleve query syntax for advanced searches.
+
+**Parameters:**
+
+- `query` (required) — Search term or Bleve query
+- `analyzer` (optional) — Filter to one analyzer: `complexity`, `coupling`, `secrets`, `clones`
+- `severity` (optional) — Filter by severity: `info`, `warning`, `critical`
+- `file` (optional) — Filter by file path substring
+- `limit` (optional) — Max results (default 20)
+
+**Example usage:**
+
+```
+Search for: "high complexity"
+-> findings_search query="complexity" severity="warning"
+-> Returns: functions with high cyclomatic complexity, with file:line
+```
+
+### 2. List Findings (`mcp__plugin_aide_aide__findings_list`)
+
+List findings with filters. Use when you want to browse rather than search.
+
+**Parameters:**
+
+- `analyzer` (optional) — Filter to one analyzer
+- `severity` (optional) — Filter by severity
+- `file` (optional) — Filter by file path substring
+- `limit` (optional) — Max results (default 20)
+- `offset` (optional) — Pagination offset
+
+**Example usage:**
+
+```
+List all critical findings
+-> findings_list severity="critical"
+-> Returns: all critical-severity findings across all analyzers
+```
+
+### 3. Findings Statistics (`mcp__plugin_aide_aide__findings_stats`)
+
+Get aggregate counts by analyzer and severity. Use as a starting point to understand overall
+code health before drilling into specifics.
+
+**Example usage:**
+
+```
+How healthy is the codebase?
+-> findings_stats
+-> Returns: counts per analyzer, counts per severity, total findings
+```
+
+## Workflow
+
+### Quick Health Check
+
+1. **Get overview** — Use `findings_stats` to see counts by analyzer and severity
+2. **Triage critical** — Use `findings_list severity="critical"` to review highest-priority items
+3. **Drill into areas** — Use `findings_search` with file or query filters for specific concerns
+
+### Complexity Analysis
+
+1. Run `findings_search analyzer="complexity" severity="critical"` to find the most complex functions
+2. Use `code_outline` on flagged files to understand structure
+3. Use `Read` with offset/limit to examine the specific functions
+4. Recommend decomposition strategies
+
+### Duplication Analysis
+
+1. Run `findings_list analyzer="clones"` to see detected code clones
+2. Each finding includes the clone pair — both file locations and line ranges
+3. Use `Read` to compare the duplicated sections
+4. Recommend extraction into shared functions or modules
+
+### Coupling Analysis
+
+1. Run `findings_search analyzer="coupling"` to see import fan-out/fan-in issues
+2. High fan-out means a file imports too many things (potential god module)
+3. High fan-in means many files depend on one (fragile dependency)
+4. Cycle findings indicate circular dependency chains
+
+### Secret Detection
+
+1. Run `findings_list analyzer="secrets" severity="critical"` for confirmed secrets
+2. Run `findings_list analyzer="secrets"` for all potential secrets (including unverified)
+3. Each finding includes the secret category (e.g., AWS, GitHub, generic API key)
+4. Snippets are redacted for safety — use `Read` to examine context around the finding
+
+## Anti-Pattern Identification
+
+Beyond the automated analyzers, look for these patterns using findings as starting points:
+
+| Finding         | Likely Anti-Pattern    | Action                           |
+| --------------- | ---------------------- | -------------------------------- |
+| Complexity > 20 | God function           | Decompose into smaller functions |
+| Fan-out > 15    | Kitchen sink module    | Split responsibilities           |
+| Fan-in > 20     | Fragile dependency     | Consider interface/abstraction   |
+| Multiple clones | Copy-paste programming | Extract shared utility           |
+| Import cycle    | Circular dependency    | Restructure module boundaries    |
+
+## Output Format
+
+```markdown
+## Code Health Report
+
+### Overview
+
+- Total findings: X (Y critical, Z warnings)
+- Top concern: [area/file with most issues]
+
+### Hotspots
+
+1. **`file:line`** - [description] (severity)
+   - Impact: [why this matters]
+   - Recommendation: [what to do]
+
+### Patterns Detected
+
+- [List of anti-patterns found with evidence]
+
+### Recommendations
+
+1. [Prioritized action items]
+```
+
+## Failure Handling
+
+1. **No findings data** — Tell user to run analyzers first: `./.aide/bin/aide findings run --path .`
+2. **Stale findings** — Findings reflect the state at last analyzer run; recommend re-running if code changed significantly
+3. **False positives** — Secret detection may flag test fixtures or example configs; note when findings appear to be in test/example code
+
+## Verification Criteria
+
+- [ ] Checked `findings_stats` for overall picture
+- [ ] Reviewed critical findings
+- [ ] Cross-referenced findings with actual code (used `Read` or `code_outline`)
+- [ ] Provided actionable recommendations with file:line references
+- [ ] Noted any false positives or findings that need manual verification

package/skills/plan-swarm/SKILL.md

@@ -113,6 +113,11 @@ Output a structured story list. Each story must be:
 
 4. **Instruct the user**: Run `/aide:swarm` to execute the plan
 
+**Note on task materialization:** The plan is stored as a decision, not as tasks. The `/aide:swarm` skill reads the plan and materializes tasks at execution time:
+
+- **Claude Code**: Each story agent creates native tasks (`TaskCreate`) with `blockedBy` dependency chaining for SDLC stages.
+- **OpenCode**: The orchestrator creates aide tasks (`task_create` MCP tool) for all SDLC stages upfront, and story agents claim them.
+
 ## Output Format
 
 The stored `swarm-plan` decision should be a JSON object:

package/skills/ralph/SKILL.md

@@ -34,6 +34,15 @@ You are now in **Ralph Wiggum mode** - an iterative development methodology that
 
 All state is managed through aide. Use MCP tools for reads, CLI for writes:
 
+### Task System Roles
+
+| System                      | Role                                                    | How                                                                   |
+| --------------------------- | ------------------------------------------------------- | --------------------------------------------------------------------- |
+| **aide tasks** (MCP or CLI) | Durable task backlog, claiming, persistence enforcement | `task_create`/`task_claim`/`task_complete` (MCP) or `aide task` (CLI) |
+| **Native todowrite**        | Personal progress tracking within current iteration     | `todowrite` tool — tracks sub-steps of current task                   |
+
+aide tasks are the source of truth for ralph — they survive session restarts and are checked by persistence hooks to block premature stopping. Use native `todowrite` for your own step-by-step checklist within each task iteration.
+
 ### Reads (MCP Tools)
 
 | Tool                                   | Purpose              |
@@ -43,14 +52,18 @@ All state is managed through aide. Use MCP tools for reads, CLI for writes:
 | `mcp__plugin_aide_aide__decision_get`  | Get decisions        |
 | `mcp__plugin_aide_aide__decision_list` | List all decisions   |
 | `mcp__plugin_aide_aide__memory_search` | Search discoveries   |
+| `task_list`                            | List aide tasks      |
+| `task_get`                             | Get task by ID       |
 
-### Writes (CLI via Bash)
+### Writes (CLI via Bash or MCP)
 
 ```bash
 # Phase tracking
 ./.aide/bin/aide state set ralph:phase planning   # or "building"
 
-# Task management (use Claude's native TaskCreate/TaskUpdate/TaskList)
+# Task management — use aide tasks (persistent, claimable)
+# Via MCP: task_create, task_claim, task_complete
+# Via CLI: ./.aide/bin/aide task create/claim/complete
 
 # Decisions
 ./.aide/bin/aide decision set <topic> "<decision>" --rationale="<why>"
@@ -168,12 +181,6 @@ Claim it:
 ./.aide/bin/aide task claim <task-id> --agent=ralph
 ```
 
-Claim it:
-
-```bash
-./.aide/bin/aide task claim <task-id> --agent=ralph
-```
-
 #### 3. Verify Gap Still Exists (Don't Assume!)
 
 Before implementing, RE-VERIFY:

package/skills/review/SKILL.md

@@ -88,6 +88,9 @@ Use these tools during review:
 - `mcp__plugin_aide_aide__code_symbols` - List all symbols in a file being reviewed
 - `mcp__plugin_aide_aide__code_references` - Find all callers/usages of a modified symbol
 - `mcp__plugin_aide_aide__memory_search` - Check for related past decisions or issues
+- `mcp__plugin_aide_aide__findings_search` - Search static analysis findings (complexity, secrets, clones) related to changed code
+- `mcp__plugin_aide_aide__findings_list` - List findings filtered by file, severity, or analyzer
+- `mcp__plugin_aide_aide__findings_stats` - Overview of finding counts by analyzer and severity
 
 ## Output Format