Adding some claude skills for working with intellij plugins

Author: cj-radcliff

.claude/skills/intellij-plugin-dev-workspace/iteration-1/benchmark.json

@@ -0,0 +1,13 @@
+# Skill Benchmark: intellij-plugin-dev
+
+**Model**: <model-name>
+**Date**: 2026-03-16T04:00:26Z
+**Evals**: 1, 2, 3 (3 runs each per configuration)
+
+## Summary
+
+| Metric | With Skill | Without Skill | Delta |
+|--------|------------|---------------|-------|
+| Pass Rate | 89% ± 19% | 61% ± 54% | +0.28 |
+| Time | 209.9s ± 69.1s | 78.2s ± 14.8s | +131.7s |
+| Tokens | 73574 ± 22663 | 27185 ± 709 | +46390 |

.claude/skills/intellij-plugin-dev-workspace/iteration-1/benchmark.md

@@ -0,0 +1,27 @@
+{
+  "eval_id": 1,
+  "eval_name": "windows-debug-errors",
+  "prompt": "In the flutter-intellij plugin, I'm seeing that when I run a Flutter Windows desktop app in debug mode, exceptions thrown by the Flutter framework are not appearing in the IntelliJ console. The same app works fine on Chrome. What's the code path responsible for showing these errors, and where is the most likely failure point on Windows? Walk me through the relevant classes and show where you'd add a fix.",
+  "assertions": [
+    {
+      "id": "mentions-structured-errors",
+      "text": "Mentions ext.flutter.inspector.structuredErrors or structured errors being enabled as the reason Chrome differs from Windows"
+    },
+    {
+      "id": "mentions-flutter-console-log-manager",
+      "text": "Mentions FlutterConsoleLogManager or handleFlutterErrorEvent as the handler for Flutter.Error events"
+    },
+    {
+      "id": "identifies-silent-catch",
+      "text": "Identifies the silent exception catch (try/catch that only logs a warning) in processFlutterErrorEvent as the failure point"
+    },
+    {
+      "id": "proposes-concrete-fix",
+      "text": "Proposes a concrete fix — either a fallback to display raw error text on exception, or adds error visibility when processFlutterErrorEvent throws"
+    },
+    {
+      "id": "explains-chrome-difference",
+      "text": "Explains why Chrome works differently (extension not available on web, so app.log path is used instead)"
+    }
+  ]
+}

.claude/skills/intellij-plugin-dev-workspace/iteration-1/eval-1-windows-debug-errors/eval_metadata.json

@@ -0,0 +1,129 @@
+# Flutter Windows Desktop: Missing Debug Console Errors
+
+## The error display code path (structured errors enabled)
+
+When `isShowStructuredErrors()` is true, the plugin enables `ext.flutter.inspector.structuredErrors`
+via `FlutterApp.getFlutterConsoleLogManager()`. Once enabled, Flutter **suppresses** `app.log`
+error events and instead sends `Flutter.Error` VM service extension events on the `Extension` stream.
+
+The full chain:
+
+```
+Flutter framework error → FlutterError.presentError()
+      ↓
+Flutter.Error VM service extension event (Extension stream)
+      ↓
+VMServiceManager.onVmServiceReceived("Flutter.Error")   [VMServiceManager.java:207]
+      ↓
+app.getFlutterConsoleLogManager().handleFlutterErrorEvent(event)
+      ↓
+queue.add(() -> processFlutterErrorEvent(diagnosticsNode))  [FlutterConsoleLogManager.java:133]
+      ↓
+processFlutterErrorEvent() → console.print(header/properties/footer)
+```
+
+## Why Chrome works but Windows does not
+
+On Chrome/web, `ext.flutter.inspector.structuredErrors` is **not available**, so the callback
+in `hasServiceExtension(...)` never fires, structured errors stay disabled, and Flutter errors
+come through the normal `app.log` daemon event path which works reliably.
+
+On Windows desktop, the extension IS available, so:
+1. Structured errors get enabled
+2. `app.log` error events are suppressed by Flutter
+3. Errors must flow through `processFlutterErrorEvent()` — and that's where they die silently
+
+## The specific failure point
+
+**`DiagnosticsNode.getStyleMember()` at line 504 of `DiagnosticsNode.java`:**
+
+```java
+private DiagnosticsTreeStyle getStyleMember(String memberName, DiagnosticsTreeStyle defaultValue) {
+    if (!json.has(memberName)) {
+        return defaultValue;
+    }
+    final JsonElement value = json.get(memberName);
+    if (value instanceof JsonNull) {
+        return defaultValue;
+    }
+    return DiagnosticsTreeStyle.valueOf(value.getAsString());  // ← NO try/catch
+}
+```
+
+Compare with the safe `getLevelMember()` just above it, which has:
+
+```java
+catch (IllegalArgumentException ignore) {
+    return defaultValue;
+}
+```
+
+If the Windows Flutter SDK emits a `style` value not present in the plugin's `DiagnosticsTreeStyle`
+enum, `valueOf()` throws `IllegalArgumentException`. This propagates out of `processFlutterErrorEvent()`
+and is caught by the queue lambda's `catch (Throwable t)` at line 137:
+
+```java
+catch (Throwable t) {
+    if (FlutterSettings.getInstance().isVerboseLogging()) {
+        LOG.warn(t);
+    } else {
+        LOG.warn("Error processing FlutterErrorEvent: " + t.getMessage());
+    }
+}
+```
+
+The error goes to `idea.log` only. Nothing appears in the console.
+
+## The fix — two parts
+
+### Part 1: Fix `getStyleMember()` to match `getLevelMember()`
+
+In `src/io/flutter/logging/DiagnosticsNode.java`, line 496–505:
+
+```java
+private DiagnosticsTreeStyle getStyleMember(String memberName, DiagnosticsTreeStyle defaultValue) {
+    if (!json.has(memberName)) {
+        return defaultValue;
+    }
+    final JsonElement value = json.get(memberName);
+    if (value instanceof JsonNull) {
+        return defaultValue;
+    }
+    try {
+        return DiagnosticsTreeStyle.valueOf(value.getAsString());
+    }
+    catch (IllegalArgumentException ignore) {
+        return defaultValue;
+    }
+}
+```
+
+### Part 2: Add fallback console output in the queue catch block
+
+In `FlutterConsoleLogManager.java`, line 133–151, change the catch to also emit a raw error:
+
+```java
+queue.add(() -> {
+    try {
+        processFlutterErrorEvent(diagnosticsNode);
+    }
+    catch (Throwable t) {
+        // Fallback: show the raw error text so it's never silently swallowed
+        final String rawError = diagnosticsNode.getDescription();
+        if (rawError != null && !rawError.isEmpty()) {
+            console.print(rawError + "\n", ConsoleViewContentType.ERROR_OUTPUT);
+        }
+        LOG.warn("Error processing FlutterErrorEvent: " + t.getMessage());
+    }
+    finally { ... }
+});
+```
+
+## Key files
+
+| File | Location | Role |
+|------|----------|------|
+| `DiagnosticsNode.java` | `src/io/flutter/logging/` | **Fix site** — `getStyleMember()` line 504 |
+| `FlutterConsoleLogManager.java` | `src/io/flutter/logging/` | Silent swallow site — line 137 |
+| `VMServiceManager.java` | `src/io/flutter/vmService/` | Routes `Flutter.Error` events |
+| `FlutterApp.java` | `src/io/flutter/run/daemon/` | Enables `structuredErrors` — lines 633–649 |

.claude/skills/intellij-plugin-dev-workspace/iteration-1/eval-1-windows-debug-errors/with_skill/outputs/response.md

@@ -0,0 +1,37 @@
+{
+  "eval_id": 1,
+  "run_type": "with_skill",
+  "expectations": [
+    {
+      "text": "Mentions ext.flutter.inspector.structuredErrors or structured errors being enabled as the reason Chrome differs from Windows",
+      "passed": true,
+      "evidence": "The response explicitly states 'When isShowStructuredErrors() is true, the plugin enables ext.flutter.inspector.structuredErrors via FlutterApp.getFlutterConsoleLogManager()' and explains that 'On Chrome/web, ext.flutter.inspector.structuredErrors is not available, so the callback in hasServiceExtension(...) never fires, structured errors stay disabled'"
+    },
+    {
+      "text": "Mentions FlutterConsoleLogManager or handleFlutterErrorEvent as the handler for Flutter.Error events",
+      "passed": true,
+      "evidence": "The response shows the full chain including 'app.getFlutterConsoleLogManager().handleFlutterErrorEvent(event)' and 'queue.add(() -> processFlutterErrorEvent(diagnosticsNode))  [FlutterConsoleLogManager.java:133]'"
+    },
+    {
+      "text": "Identifies the silent exception catch (try/catch that only logs a warning) in processFlutterErrorEvent as the failure point",
+      "passed": true,
+      "evidence": "The response shows the catch block at line 137: 'catch (Throwable t) { if (FlutterSettings.getInstance().isVerboseLogging()) { LOG.warn(t); } else { LOG.warn(\"Error processing FlutterErrorEvent: \" + t.getMessage()); } }' and notes 'The error goes to idea.log only. Nothing appears in the console.'"
+    },
+    {
+      "text": "Proposes a concrete fix \u00e2\u20ac\u201d either a fallback to display raw error text on exception, or adds error visibility when processFlutterErrorEvent throws",
+      "passed": true,
+      "evidence": "The response proposes two concrete fixes: Part 1 fixes getStyleMember() to add a try/catch matching getLevelMember(), and Part 2 adds a fallback console.print(rawError, ERROR_OUTPUT) in the catch block so errors are never silently swallowed."
+    },
+    {
+      "text": "Explains why Chrome works differently (extension not available on web, so app.log path is used instead)",
+      "passed": true,
+      "evidence": "The response states 'On Chrome/web, ext.flutter.inspector.structuredErrors is not available, so the callback in hasServiceExtension(...) never fires, structured errors stay disabled, and Flutter errors come through the normal app.log daemon event path which works reliably.'"
+    }
+  ],
+  "summary": {
+    "passed": 5,
+    "failed": 0,
+    "total": 5,
+    "pass_rate": 1.0
+  }
+}

.claude/skills/intellij-plugin-dev-workspace/iteration-1/eval-1-windows-debug-errors/with_skill/run-1/grading.json

@@ -0,0 +1,5 @@
+{
+  "total_tokens": 99378,
+  "duration_ms": 230008,
+  "total_duration_seconds": 230.0
+}

.claude/skills/intellij-plugin-dev-workspace/iteration-1/eval-1-windows-debug-errors/with_skill/run-1/timing.json

@@ -0,0 +1,114 @@
+# Flutter Windows Desktop Debug Exceptions Not Appearing in IntelliJ Console
+
+## Overview
+
+When a Flutter Windows desktop app runs in debug mode via the flutter-intellij plugin, exceptions thrown by the Flutter framework should appear in the IntelliJ "Run" or "Debug" console. The fact that Chrome works but Windows does not points to a platform-specific divergence in how the plugin launches the process, attaches the debugger, or routes stderr/stdout from the running process.
+
+## The Error Display Pipeline
+
+### 1. Process Launch — `FlutterApp` / `FlutterLaunchTask`
+
+The entry point is the run configuration execution chain. When the user hits "Debug", IntelliJ calls the plugin's `RunProfileState`, which delegates to a `FlutterLaunchTask`. This task builds the `flutter run` command line, starts the process via `GeneralCommandLine` / `OSProcessHandler`, and returns a `ProcessHandler` that IntelliJ attaches to the console.
+
+For Chrome the device ID is `chrome`; for Windows desktop it is `windows`. Both call `flutter run`, but output handling diverges.
+
+### 2. Process Handler — `OSProcessHandler` / `FlutterApp`
+
+`OSProcessHandler` reads stdout and stderr from the child process and broadcasts `ProcessEvent`s to registered `ProcessListener`s. IntelliJ's console view is one such listener. Key plugin classes involved:
+
+- **`FlutterApp`** — wraps the running `flutter run` process and acts as central coordinator.
+- **`DaemonApi` / `FlutterDaemonService`** — communicates with the Flutter tool daemon (JSON-RPC over stdin/stdout). The daemon sends structured events including `app.log`, `app.progress`, and error events.
+- **`FlutterConsoleFilter`** — post-processes console lines (e.g., makes Dart file URIs clickable) but does not suppress them.
+
+### 3. Daemon vs. Direct Output — the Critical Branch
+
+- **Chrome**: Flutter's web tooling often emits errors directly to **stderr** of the `flutter run` process, which flows straight through `OSProcessHandler` to the console.
+- **Windows desktop**: Framework-level exceptions (the `FlutterError.onError` red-box output) travel through a **`app.log` daemon event** — a structured JSON message that the plugin must explicitly listen for and forward to the console.
+
+If the `app.log` listener is not registered, the errors are silently dropped even though the Flutter tool is emitting them correctly.
+
+## Most Likely Failure Points on Windows
+
+### Failure Point A: `app.log` listener not wired up for desktop targets
+
+The listener registration code may have a device-type guard that inadvertently excludes desktop:
+
+```java
+if (device.isWeb()) {
+    // handle raw stderr
+} else if (device.isMobile()) {
+    // register app.log listener
+}
+// desktop falls through — no listener registered!
+```
+
+This is the highest-probability cause. The fix is ensuring the `app.log` registration runs for all device types, including desktop.
+
+### Failure Point B: `ConsoleView` reference is null for the desktop debug session
+
+After the debug session starts, the plugin attaches an `XDebugSession`. The `ConsoleView` used during the pre-debug launch phase may differ from the one shown in the Debug tool window. If the plugin resolves the console by looking up the `RunContentDescriptor` and that lookup fails for the desktop configuration, `console` is null. The handler then silently no-ops:
+
+```java
+if (console != null) {
+    console.print(log, contentType);
+}
+// else: message is lost with no warning
+```
+
+### Failure Point C: CRLF line-ending differences on Windows
+
+Windows uses CRLF. If the `OSProcessHandler` or the daemon JSON parser does not handle `\r\n` correctly, daemon messages may fail to parse, causing `app.log` events to be missed entirely. Less likely than A or B for JSON payloads, but worth ruling out.
+
+## Where to Add the Fix
+
+### Step 1: Locate daemon event registration
+
+Find the method that registers `app.log` listeners — likely in `FlutterApp.java` in a method called after the app process starts (e.g., `onAppStarted`, `start`), or in the `LaunchState`/`FlutterLaunchTask` `execute()` override.
+
+### Step 2: Register the listener unconditionally for all device types
+
+```java
+daemonApi.listenForAppLog(appId, (String log, boolean isError) -> {
+    ConsoleView console = getConsoleView();
+    if (console == null) {
+        logger.warn("FlutterApp: ConsoleView null on app.log for device: "
+            + device.deviceId());
+        return;
+    }
+    console.print(log + "\n",
+        isError ? ConsoleViewContentType.ERROR_OUTPUT
+                : ConsoleViewContentType.NORMAL_OUTPUT);
+});
+```
+
+Remove any `device.isWeb()` or `device.isMobile()` guard that wraps this registration.
+
+### Step 3: Verify ConsoleView resolution for desktop
+
+If the diagnostic log in Step 2 fires (console is null), trace how the `ConsoleView` is passed to `FlutterApp` for desktop vs. mobile/web configurations. The desktop run configuration likely takes a different code path during `RunContentDescriptor` creation and does not inject the console reference.
+
+### Step 4: Cross-check the event name
+
+Add a temporary catch-all to confirm what event names the Flutter tool actually emits on Windows:
+
+```java
+daemonApi.listenForAllEvents(event -> {
+    if (event.method.contains("log") || event.method.contains("error")) {
+        logger.info("Daemon event: " + event.method + " / " + event.params);
+    }
+});
+```
+
+Check `idea.log` after triggering an exception on Windows to confirm the event name matches what the listener is registered for.
+
+## Summary
+
+| Component | Role | Failure risk on Windows |
+|---|---|---|
+| `FlutterLaunchTask.execute()` | Builds command, starts process | Low |
+| `OSProcessHandler` | Reads raw stdout/stderr | Medium (CRLF) |
+| `AppDaemonApi` / `app.log` listener | Forwards errors to console | **High — most likely root cause** |
+| `FlutterApp.getConsoleView()` | Resolves active `ConsoleView` | **High** |
+| `FlutterConsoleFilter` | Hyperlink post-processing | Low |
+
+The most actionable fix is to audit where `app.log` daemon event listeners are registered, ensure registration is not gated on device type in a way that excludes desktop, and add null-safety diagnostics on the `ConsoleView` resolution path.

.claude/skills/intellij-plugin-dev-workspace/iteration-1/eval-1-windows-debug-errors/without_skill/outputs/response.md

@@ -0,0 +1,37 @@
+{
+  "eval_id": 1,
+  "run_type": "without_skill",
+  "expectations": [
+    {
+      "text": "Mentions ext.flutter.inspector.structuredErrors or structured errors being enabled as the reason Chrome differs from Windows",
+      "passed": false,
+      "evidence": "The response does not mention ext.flutter.inspector.structuredErrors or the structured errors extension at all. It incorrectly attributes the Chrome vs Windows difference to Chrome using stderr directly while Windows uses app.log daemon events, without identifying the actual structured errors mechanism."
+    },
+    {
+      "text": "Mentions FlutterConsoleLogManager or handleFlutterErrorEvent as the handler for Flutter.Error events",
+      "passed": false,
+      "evidence": "The response does not mention FlutterConsoleLogManager or handleFlutterErrorEvent anywhere. It references DaemonApi, FlutterApp, and app.log listeners generically but never identifies the specific class responsible for handling Flutter.Error events."
+    },
+    {
+      "text": "Identifies the silent exception catch (try/catch that only logs a warning) in processFlutterErrorEvent as the failure point",
+      "passed": false,
+      "evidence": "The response does not identify processFlutterErrorEvent or any silent catch block as the failure point. It speculates about an app.log listener not being registered for desktop targets or a null ConsoleView reference, which are hypothetical failure points not grounded in the actual code."
+    },
+    {
+      "text": "Proposes a concrete fix \u00e2\u20ac\u201d either a fallback to display raw error text on exception, or adds error visibility when processFlutterErrorEvent throws",
+      "passed": false,
+      "evidence": "The response proposes registering an app.log listener unconditionally for all device types, which is not the actual fix needed. It does not address the real failure point (the silent catch in processFlutterErrorEvent) and does not propose adding fallback console output when an exception is thrown."
+    },
+    {
+      "text": "Explains why Chrome works differently (extension not available on web, so app.log path is used instead)",
+      "passed": false,
+      "evidence": "The response incorrectly explains the Chrome difference as Chrome emitting errors directly to stderr of the flutter run process. It does not mention that the structuredErrors extension is unavailable on web, which is the actual reason the app.log path is used on Chrome."
+    }
+  ],
+  "summary": {
+    "passed": 0,
+    "failed": 5,
+    "total": 5,
+    "pass_rate": 0.0
+  }
+}

.claude/skills/intellij-plugin-dev-workspace/iteration-1/eval-1-windows-debug-errors/without_skill/run-1/grading.json

@@ -0,0 +1,5 @@
+{
+  "total_tokens": 26606,
+  "duration_ms": 93572,
+  "total_duration_seconds": 93.6
+}