@@ -5,6 +5,13 @@ language: "en-US"
 
 reviews:
   profile: "chill"
+  tone_instructions: |
+    Pay special attention to performance in hot paths — players, MessagePipeline, 3D and Plot
+    rendering, Web Workers, and frequently re-rendering React components. Flag allocations in
+    render/tick loops, lost reference stability or missing memoization, main-thread work that
+    belongs in a Worker, and buffer copies that should be zero-copy transfers. Follow "measure
+    before you optimize": raise performance concerns only with concrete, high-confidence impact and
+    avoid speculative micro-optimizations.
   request_changes_workflow: false
   high_level_summary: true
   high_level_summary_placeholder: "@coderabbitai summary"
@@ -62,6 +69,47 @@ reviews:
         Type definition files. Check for accurate and comprehensive type definitions.
         Ensure no `any` types are used without justification.
 
+    - path: "packages/suite-base/src/players/**"
+      instructions: |
+        Performance-critical player and data-source code. Flag allocations inside tick loops or
+        per-message hot paths, missing message batching, and subscriptions that iterate topics no
+        panel requested. Verify message-cache/memory budgets are respected and that large buffers
+        are released behind the read head. Flag concrete regressions only — do not restate the
+        generic rules already in .github/instructions/performance.instructions.md.
+
+    - path: "packages/suite-base/src/components/MessagePipeline/**"
+      instructions: |
+        Hot render-state path. Verify renderState fields keep stable references when their data is
+        unchanged (reference equality drives panel re-renders), zustand selectors stay
+        fine-grained, and subscription merging is preserved. Flag changes that would make all
+        panels re-render every frame.
+
+    - path: "packages/suite-base/src/panels/ThreeDeeRender/**"
+      instructions: |
+        GPU/render hot path. Flag per-frame allocations (new THREE objects, arrays, or closures
+        created inside render/update loops), GPU buffers recreated per frame instead of reused or
+        grown, unbounded draw-call growth, and bypassed object pools. Verify temp objects are
+        reused for frequently created/destroyed values.
+
+    - path: "packages/suite-base/src/panels/Plot/**"
+      instructions: |
+        Chart rendering hot path. Verify heavy dataset work stays off the main thread (Workers or
+        OffscreenCanvas), the per-series point cap is respected, and updates are incremental rather
+        than full rebuilds. Flag main-thread processing of large datasets.
+
+    - path: "**/*.worker.ts"
+      instructions: |
+        Web Worker boundary. Verify large ArrayBuffer/TypedArray payloads use zero-copy
+        Comlink.transfer instead of structured-clone copies, and that worker proxies are disposed
+        to avoid leaks. Flag large buffers copied across the worker boundary.
+
+    - path: "**/*.tsx"
+      instructions: |
+        React render path. Raise only clear, high-impact render-performance issues: inline
+        object/array/function literals passed to memoized children, expensive work run directly in
+        render instead of useMemo, or setState called unconditionally inside useEffect. Do not
+        nitpick low-traffic components — respect the project's "measure before you optimize" rule.
+
   auto_review:
     enabled: true
     ignore_title_keywords:
 
@@ -2,6 +2,9 @@
 *.tsbuildinfo
 .DS_Store
 .webpack/
+.caddy-certs/
+.caddy-data/
+.tls/
 dist/
 node_modules/
 Dockerfile
@@ -0,0 +1,80 @@
+name: SDD Feature Request
+description: Propose a feature with explicit specification, acceptance criteria, and definition of done.
+title: "[Feature]: "
+labels:
+  - enhancement
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Use this template to define the feature specification before implementation.
+
+  - type: textarea
+    id: problem
+    attributes:
+      label: Problem statement
+      description: What user or developer problem should be solved?
+      placeholder: Describe the current pain point.
+    validations:
+      required: true
+
+  - type: textarea
+    id: proposed-solution
+    attributes:
+      label: Proposed solution
+      description: What behavior or capability should be added?
+      placeholder: Describe the desired solution at a high level.
+    validations:
+      required: true
+
+  - type: textarea
+    id: acceptance-criteria
+    attributes:
+      label: Acceptance criteria
+      description: Provide measurable criteria that must be true for completion.
+      placeholder: |
+        - [ ] Criterion 1
+        - [ ] Criterion 2
+        - [ ] Criterion 3
+    validations:
+      required: true
+
+  - type: textarea
+    id: definition-of-done
+    attributes:
+      label: Definition of done
+      description: Provide completion checks for implementation quality.
+      placeholder: |
+        - [ ] Required tests added/updated
+        - [ ] Documentation updated
+        - [ ] Lint/type-check/tests pass
+    validations:
+      required: true
+
+  - type: textarea
+    id: scope
+    attributes:
+      label: Scope and non-goals
+      description: Clarify what is in scope and explicitly out of scope.
+      placeholder: |
+        In scope:
+        -
+
+        Out of scope:
+        -
+    validations:
+      required: true
+
+  - type: textarea
+    id: risk
+    attributes:
+      label: Risks and dependencies
+      description: List technical risks, migration concerns, and dependencies.
+      placeholder: |
+        Risks:
+        -
+
+        Dependencies:
+        -
+    validations:
+      required: false
@@ -0,0 +1,71 @@
+---
+description: "Deserialization specialist covering schema parsing and message decoding for protobuf/flatbuffer/ROS/JSON. Use for data format issues, schema resolution, and decoding performance after message bytes are available."
+tools: ["read", "search"]
+---
+
+# Deserialization Agent
+
+You are an expert on the Lichtblick deserialization layer — converting raw binary message data into structured JavaScript objects.
+
+## Architecture
+
+```
+Raw bytes (from source)
+  │
+  ▼
+DeserializingIterableSource (applies parseChannel-based decode)
+    │
+    ▼
+Decoded message objects (ready for panels)
+```
+
+## Schema Encodings Supported
+
+| Encoding | Schema Format | Deserializer |
+|----------|--------------|--------------|
+| `ros1msg` | ROS 1 message definition text | `@lichtblick/rosmsg-serialization` MessageReader |
+| `ros2msg` | ROS 2 message definition text | `@lichtblick/rosmsg2-serialization` MessageReader |
+| `ros2idl` | OMG IDL text | `@lichtblick/omgidl-serialization` MessageReader |
+| `jsonschema` | JSON Schema object | JSON.parse + postprocessValue (base64 decode) |
+| `protobuf` | FileDescriptorSet binary | `protobufjs` Root.fromDescriptor |
+| `flatbuffer` | Binary reflection schema | `flatbuffers_reflection` Parser |
+
+## Core Entry Point: `parseChannel()`
+
+Located in `packages/mcap-support/src/parseChannel.ts`:
+
+```typescript
+function parseChannel(channel: Channel): ParsedChannel {
+  // Returns { deserialize: (data: ArrayBufferView) => unknown, datatypes: Map }
+  // Dispatches based on channel.schema.encoding
+}
+```
+
+This is the single function that resolves any channel's schema into a deserializer.
+
+## DeserializingIterableSource
+
+- Wraps a serialized source (`ISerializedIterableSource`)
+- Applies `parseChannel()` to each channel's schema at initialization
+- Deserializes messages on-the-fly as they're iterated
+- Produces `IDeserializedIterableSource` (messages are JS objects, not raw bytes)
+
+## Key Files
+- `packages/mcap-support/src/parseChannel.ts` — schema → deserializer dispatch
+- `packages/mcap-support/src/parseProtobufSchema.ts` — Protobuf handling
+- `packages/mcap-support/src/parseFlatbufferSchema.ts` — Flatbuffer handling
+- `packages/mcap-support/src/parseJsonSchema.ts` — JSON Schema handling
+- `packages/suite-base/src/players/IterablePlayer/DeserializingIterableSource.ts`
+
+## Performance Considerations
+
+- Deserialization is CPU-bound — runs in Worker via `WorkerIterableSource`
+- Protobuf: `root.lookupType()` is cached after first call
+- JSON: `postprocessValue` handles base64→Uint8Array conversion for `bytes` fields
+- Flatbuffers: zero-copy read from shared buffer (fastest)
+- ROS: `MessageReader` pre-compiles field offsets at schema parse time
+
+## Skills Reference
+- MCAP format, chunk structure, and indexed reading: `read_file(".github/skills/mcap-format/SKILL.md")`
+- Worker/Comlink patterns (offloading decode to SharedWorker): `read_file(".github/skills/web-workers/SKILL.md")`
+- Decode throughput profiling or allocation reduction: `read_file(".github/skills/performance/SKILL.md")`
@@ -0,0 +1,117 @@
+---
+description: "Desktop/Electron platform specialist covering the main process, preload scripts, IPC communication, BrowserWindow management, native menus, and file system access. Use for Electron-specific features and desktop app behavior."
+tools: ["read", "edit", "search", "execute"]
+---
+
+# Desktop Agent
+
+You are an expert on the Lichtblick desktop application built with Electron.
+
+## Ownership
+
+This agent is the designated **writer** for the Electron desktop platform. Only this agent edits files in these paths. All other agents treat them as **read-only**.
+
+**Owned paths:**
+- `desktop/**`
+- `packages/suite-desktop/**`
+
+**Read-only context** (inform decisions but never edit):
+- `packages/suite-base/src/**` — shared application code
+- `web/**` — web platform, owned by `@lb-web`
+
+## Architecture
+
+```text
+Main Process (Node.js)
+    │
+    ├── App lifecycle (single instance, deep links)
+    ├── StudioWindow (BrowserWindow management)
+    ├── Native menus (File, Edit, View, Help)
+    └── File system access (layouts, extensions)
+    │
+    ▼ (IPC via contextBridge)
+Preload Script
+    │
+    ├── desktopBridge (app operations)
+    ├── storageBridge (key-value storage)
+    ├── menuBridge (menu events)
+    └── ctxbridge (OS context)
+    │
+    ▼
+Renderer Process (React app)
+    │
+    ├── DesktopExtensionLoader (filesystem)
+    ├── DesktopLayoutLoader (filesystem)
+    └── NativeAppMenu / NativeWindow
+```
+
+## Core Components
+
+| File | Role |
+|------|------|
+| `packages/suite-desktop/src/main/index.ts` | App entry, single instance, lifecycle |
+| `packages/suite-desktop/src/main/StudioWindow.ts` | BrowserWindow creation, preload config |
+| `packages/suite-desktop/src/preload/index.ts` | contextBridge API exposure |
+| `packages/suite-desktop/src/common/types.ts` | IPC type definitions (Desktop, Storage, etc.) |
+| `packages/suite-desktop/src/renderer/Root.tsx` | Renderer entry with desktop-specific loaders |
+
+## IPC Bridges
+
+### desktopBridge (Desktop interface)
+- `updateNativeColorScheme()` — sync theme with OS
+- `updateLanguage()` — update app language
+- `getDeepLinks()` — retrieve pending deep link URLs
+- `fetchLayouts()` — load layout files from disk
+
+### storageBridge (Storage interface)
+- Key-value storage backed by files on disk
+- Used for app configuration persistence
+- Alternative to localStorage (works across windows)
+
+### menuBridge (NativeMenuBridge)
+- Forwards native menu events to renderer
+- `ForwardedMenuEvent`: open-file, open-connection, preferences, etc.
+
+## Single Instance Enforcement
+
+```typescript
+const gotLock = app.requestSingleInstanceLock();
+if (!gotLock) {
+  app.quit(); // Another instance already running
+}
+app.on("second-instance", (_, argv) => {
+  // Forward deep links to existing window
+});
+```
+
+## Extension & Layout Loading (Desktop-specific)
+
+- `DesktopExtensionLoader`: Reads `.foxe` files from filesystem (type: "filesystem")
+- `DesktopLayoutLoader`: Reads `.json` layout files from configured directory
+- Both communicate via IPC through the preload bridge
+
+## Key Conventions
+
+- All IPC must go through contextBridge (no `remote` module)
+- Type-safe bridges defined in `common/types.ts`
+- Renderer cannot directly access Node.js APIs
+- CSP headers enforced in BrowserWindow webPreferences
+
+## Performance Considerations
+
+1. **Startup time**: Preload script should be minimal — defer heavy imports
+2. **IPC overhead**: Batch related IPC calls where possible
+3. **File watching**: Use efficient OS-level watchers (not polling)
+4. **Window creation**: Lazy — don't create windows until needed
+
+## Key Files
+- `packages/suite-desktop/src/main/index.ts`
+- `packages/suite-desktop/src/main/StudioWindow.ts`
+- `packages/suite-desktop/src/preload/index.ts`
+- `packages/suite-desktop/src/common/types.ts`
+- `packages/suite-desktop/src/renderer/Root.tsx`
+- `packages/suite-desktop/src/renderer/services/DesktopExtensionLoader.ts`
+- `packages/suite-desktop/src/renderer/services/DesktopLayoutLoader.ts`
+
+## Skills Reference
+- Deep Electron IPC, preload scripts, BrowserWindow, or native API patterns: `read_file(".github/skills/electron-internals/SKILL.md")`
@@ -9,8 +9,21 @@ tools: [read, edit, search, browser, todo]
 
 You create Playwright E2E tests for the Lichtblick desktop (Electron) and web apps.
 
+## Ownership
+
+This agent is the designated **writer** for E2E test files. Only this agent edits files in these paths. All other agents treat them as **read-only**.
+
+**Owned paths:**
+- `e2e/**`
+
+**Read-only context** (read source to discover selectors, but never edit source):
+- `packages/suite-base/src/**` — source components for selector discovery
+- `packages/suite-desktop/**` — desktop entry points
+- `packages/suite-web/**` — web entry points
 **Before writing any test**, always:
 
+## Skills Reference
+
 1. **Ask the user to start the application** before proceeding. For web tests, confirm that `yarn web:serve` is running at `http://localhost:8080`. For desktop tests, confirm that the desktop build exists (`yarn desktop:build:dev`). Do not proceed until the user confirms the app is running.
 2. Read the **test-conventions** skill — `read_file(".github/skills/test-conventions/SKILL.md")`
 3. Read the **e2e-playwright-mcp** skill — `read_file(".github/skills/e2e-playwright-mcp/SKILL.md")`