docs: add error construction analysis guidance to fix-errors skill and prompt

Teach the fix-error workflow to read error construction code before
proposing fixes. Instead of hardcoding knowledge about specific error
types (e.g., listener leak categories), the AI is instructed to:

1. Search for where the error is constructed in the codebase
2. Read the surrounding code to understand conditions, categories, thresholds
3. Use that understanding to determine the correct fix strategy

Includes a listener leak example showing how reading ListenerLeakError
construction in event.ts reveals the dominated/popular classification.

Relates to #289777

.github/prompts/fix-error.prompt.md

@@ -9,10 +9,16 @@ The user has given you a GitHub issue URL for an unhandled error from the VS Cod
 
 Follow the `fix-errors` skill guidelines to fix this error. Key principles:
 
-1. **Do NOT fix at the crash site.** Do not add guards, try/catch, or fallback values at the bottom of the stack trace. That only masks the problem.
-2. **Trace the data flow upward** through the call stack to find the producer of invalid data.
-3. **If the producer is cross-process** (e.g., IPC) and cannot be identified from the stack alone, **enrich the error message** with diagnostic context (data type, truncated value, operation name) so the next telemetry cycle reveals the source. Do NOT silently swallow the error.
-4. **If the producer is identifiable**, fix it directly.
+1. **Read the error construction code first.** Before proposing any fix, search the codebase for where the error is constructed (the `new Error(...)` or custom error class instantiation). Read the surrounding code to understand:
+   - What conditions trigger the error (thresholds, validation checks, categorization logic)
+   - What parameters, classifications, or categories the error encodes
+   - What the intended meaning of each category is and what action each warrants
+   - Whether the error is a symptom of invalid data, a threshold-based warning, or a design-time signal
+   Use this understanding to determine the correct fix strategy. Do NOT assume what the error means from its message alone — the construction code is the source of truth.
+2. **Do NOT fix at the crash site.** Do not add guards, try/catch, or fallback values at the bottom of the stack trace. That only masks the problem.
+3. **Trace the data flow upward** through the call stack to find the producer of invalid data.
+4. **If the producer is cross-process** (e.g., IPC) and cannot be identified from the stack alone, **enrich the error message** with diagnostic context (data type, truncated value, operation name) so the next telemetry cycle reveals the source. Do NOT silently swallow the error.
+5. **If the producer is identifiable**, fix it directly.
 
 After making changes, check for compilation errors via the build task and run relevant unit tests.
 

.github/skills/fix-errors/SKILL.md

@@ -62,6 +62,34 @@ throw new Error(`[UriError]: Scheme contains illegal characters. scheme:"${ret.s
 
 **Right fix (when producer is known)**: Fix the code that sends malformed data. For example, if an authentication provider passes a stringified URI instead of a `UriComponents` object to a logger creation call, fix that call site to pass the proper object.
 
+## Understanding error construction before fixing
+
+Before proposing any fix, **always find and read the code that constructs the error**. Search the codebase for the error class name or a unique substring of the error message. The construction code reveals:
+
+- **What conditions trigger the error** — thresholds, validation checks, state assertions
+- **What classifications or categories the error encodes** — the error may have subtypes that require different fix strategies
+- **What the error's parameters mean** — numeric values, ratios, or flags embedded in the message often encode diagnostic context
+- **Whether the error is actionable** — some errors are threshold-based warnings where the threshold may be legitimately exceeded by design
+
+Use this understanding to determine the correct fix strategy. The construction code is the source of truth — do NOT assume what the error means from its message alone.
+
+### Example: Listener leak errors
+
+Searching for `ListenerLeakError` leads to `src/vs/base/common/event.ts`, where the construction code reveals:
+
+```typescript
+const kind = topCount / listenerCount > 0.3 ? 'dominated' : 'popular';
+const error = new ListenerLeakError(kind, message, topStack);
+```
+
+Reading this code tells you:
+- The error has two categories based on a ratio
+- **Dominated** (ratio > 30%): one code path accounts for most listeners → that code path is the problem, fix its disposal
+- **Popular** (ratio ≤ 30%): many diverse code paths each contribute a few listeners → the identified stack trace is NOT the root cause; it's just the most identical stack among many. Investigate the emitter and its aggregate subscribers instead
+- For popular leaks: do NOT remove caching/pooling/reuse patterns that appear in the top stack — they exist to solve other problems. If the aggregate count is by design (e.g., many menus subscribing to a shared context key service), close the issue as "not planned"
+
+This analysis came from reading the construction code, not from memorized rules about listener leaks.
+
 ## Guidelines
 
 - Prefer enriching error messages over adding try/catch guards