Immutable. This exact content is served forever at /api/v1/blob/12a23dba3a24b3f9.
---
description: "When the user types /discovery or requests quality analysis, code audit, or issue detection"
globs: ""
alwaysApply: false
---
# Discovery — Quality Analysis & Issue Detection
Systematic quality discovery that runs modular probes adapted to the project's tech stack, presents findings interactively, and creates VCS issues for confirmed problems.
## Invocation
- **Standalone** (`/discovery [scope]`): Full flow with interactive triage
- **Embedded** (from session-end): Phases 0-3 only, return structured findings
Scope accepts: `all` (default), `code`, `infra`, `ui`, `arch`, `session`, or comma-separated like `code,session`.
## Phase 1: Stack Detection
Detect the project's tech stack via marker file checks:
| Marker File(s) | Activates |
|----------------|-----------|
| `package.json` | JS/TS probes |
| `tsconfig.json` | TypeScript probes |
| `requirements.txt` / `pyproject.toml` | Python probes |
| `Dockerfile` / `docker-compose.yml` | Container probes |
| `.github/workflows/` | GitHub CI probes |
| `.gitlab-ci.yml` | GitLab CI probes |
| `next.config.*` / `nuxt.config.*` | SSR probes |
| `tailwind.config.*` | Tailwind probes |
Report: "Discovery: [N] probes active across [categories]. Stack: [detected]."
### Exclude Paths (always apply)
`node_modules/`, `.git/`, `dist/`, `build/`, `.next/`, `.nuxt/`, `coverage/`
## Phase 2: Probe Execution
Run probes **sequentially** (Cursor has no parallel agents). Group by category.
### Available Probe Categories
**Code probes** (any project with source files):
- `hardcoded-values` — Secrets, hardcoded URLs, magic numbers
- `orphaned-annotations` — TODO/FIXME/HACK without linked VCS issues
- `dead-code` — Unused exports, unused dependencies (JS/TS)
- `ai-slop` — Filler phrases, over-documentation, hallucinated imports
- `type-safety-gaps` — `any` types, `@ts-ignore`, non-null assertions (TypeScript)
- `test-coverage-gaps` — Source files without corresponding test files
- `test-anti-patterns` — Empty assertions, excessive mocking, snapshot abuse
- `security-basics` — eval(), dangerouslySetInnerHTML, SQL injection, permissive CORS
**Infra probes** (when CI/Docker markers found):
- CI configuration issues, Dockerfile anti-patterns, deployment health
**UI probes** (when frontend frameworks detected):
- Accessibility gaps, responsive design issues, component anti-patterns
**Arch probes** (any project):
- Circular dependencies, complexity hotspots, deep nesting
**Session probes** (when `.orchestrator/` exists):
- Session metric anomalies, recurring failures, stale learnings
### Probe Execution Pattern
For each active probe:
1. Run the detection commands (Grep, Glob, Bash read-only)
2. For each match, record a finding:
```
FINDING:
probe: <probe_name>
category: <category>
severity: <critical|high|medium|low>
file_path: <absolute path>
line_number: <number>
matched_text: <exact text from tool output>
title: <short title>
description: <1-2 sentence description>
recommended_fix: <concrete fix suggestion>
```
3. If a probe's activation condition is not met, skip with note
4. If a probe command fails, skip gracefully and continue
**CRITICAL**: Do NOT fabricate findings. Only report what tool output confirms.
### Key Detection Patterns
| Probe | Severity | Pattern |
|-------|----------|---------|
| Hardcoded secrets | Critical | `(password\|api_key\|secret\|token)\s*[:=]\s*["'][^"']+["']` (exclude test/env/fixtures) |
| eval usage | High | `eval\s*\(` |
| XSS (React) | High | `dangerouslySetInnerHTML` |
| XSS (DOM) | High | `innerHTML\s*=` |
| SQL injection | High | `` `[^`]*SELECT[^`]*\$\{`` |
| any type | Medium | `:\s*any\b` or `as\s+any\b` |
| TS suppression | Medium | `@ts-ignore` |
| AI filler | Medium | `(as you can see\|it's worth noting\|needless to say)` |
| Over-documented params | Medium | `@param\s+(\w+)\s+[-]\s*(the\s+)?\1` |
## Phase 3: Verification & Scoring
After all probes complete:
### 3.1 Verify Each Finding
For EACH finding:
1. Read the file at `file_path:line_number`
2. Confirm `matched_text` appears at or near that line (+/-3 lines tolerance)
3. If NOT confirmed, discard as false positive
Report: "Verification: N confirmed, M discarded as false positives"
### 3.2 Confidence Scoring
Score each finding (0-100):
| Factor | Low (+0) | Medium (+10) | High (+20) |
|--------|----------|-------------|------------|
| Pattern specificity | Generic (URL, TODO) | Moderate (orphaned annotation) | Specific (API key regex, eval()) |
| File context | Test/example/docs | Utility/config/scripts | Production source/API handler |
| Historical signal | Previously dismissed | No prior data | Recurring issue |
Start at 40 baseline, add factor scores. Critical severity findings get minimum 70.
### 3.3 Deduplication
Two findings are duplicates if: same `file_path` AND overlapping line range (+/-5 lines) AND different probes. Keep the higher severity finding.
### 3.4 Apply Thresholds
Remove findings below configured severity and confidence thresholds (default confidence: 60).
## Phase 4: Interactive Triage (Standalone Only)
### Step 1: Summary Table
```
## Discovery Results
Probes run: [N] | Findings verified: [N] | False positives discarded: [N]
| Category | Critical | High | Medium | Low | Total |
|----------|----------|------|--------|-----|-------|
| Code | ... | ... | ... | ... | ... |
| Infra | ... | ... | ... | ... | ... |
```
### Step 2: Critical + High Findings — Review Individually
For each Critical or High finding, present to the user:
```
[CRITICAL] (confidence: 85) hardcoded-values: API key found in src/config.ts:42
<file context with +/-3 lines>
Recommended fix: <suggestion>
Options:
1. Create issue (critical)
2. Adjust priority
3. Dismiss — intentional
4. Dismiss — false positive
```
### Step 3: Medium + Low Findings — Review Batched
Group by category, present summary:
```
[N] medium/low findings in [category]:
1. [title] — [file_path]:[line] ([severity])
2. [title] — [file_path]:[line] ([severity])
Options:
1. Accept all (Recommended) — create issues for all
2. Review individually
3. Dismiss all
```
### Step 4: Batch Confirmation
Before creating issues, confirm the total count with the user.
## Phase 5: Issue Creation
For each approved finding:
1. Format issue with: title, description, severity, file location, recommended fix
2. Detect VCS platform (GitLab: `glab`, GitHub: `gh`)
3. Create issue:
- **GitLab**: `glab issue create --title "[Discovery] <title>" --label "type:discovery,priority:<level>" --description "<body>"`
- **GitHub**: `gh issue create --title "[Discovery] <title>" --label "type:discovery,priority:<level>" --body "<body>"`
4. Brief pause between creations for rate limiting
### Final Report
```
## Discovery Report
- Probes run: [N] across [categories]
- Verified: [N] (false positives: [M])
- User approved: [N]
- Issues created: [N]
| # | Title | Priority | Probe |
|---|-------|----------|-------|
| <IID> | <title> | <priority> | <probe> |
```
## Critical Rules
- **NEVER** fabricate findings — every finding must come from tool output with verifiable evidence
- **NEVER** create issues without user approval (standalone mode)
- **ALWAYS** verify findings by re-reading the file at the reported line
- **ALWAYS** present evidence (file path, line number, actual content) with every finding
- If a probe command fails, skip gracefully, continue with others
- If in embedded mode, stop after Phase 3, return findings as structured data
- Default exclude paths always apply