From 4e46848e0b8be373ce1e356eba739194e07a7b43 Mon Sep 17 00:00:00 2001
From: Gallay Lajos <gallay.lajos@gmail.com>
Date: Sun, 1 Feb 2026 08:19:54 +0100
Subject: [PATCH] cursor rule updates

---
 .cursor/agents/reviewer-changelog.md    | 122 +++++++++
 .cursor/agents/reviewer-dependencies.md | 142 +++++++++++
 .cursor/agents/reviewer-eslint.md       |  29 +++
 .cursor/agents/reviewer-prettier.md     |  27 ++
 .cursor/agents/reviewer-tests.md        | 112 +++++++++
 .cursor/agents/reviewer-typescript.md   |  28 +++
 .cursor/agents/reviewer-versioning.md   | 104 ++++++++
 .cursor/rules/CODE_STYLE.mdc            | 315 ++++++++++++++++++++++++
 .cursor/rules/TESTING_GUIDELINES.mdc    | 234 ++++++++++++++++++
 .cursor/rules/TYPESCRIPT_GUIDELINES.mdc | 266 ++++++++++++++++++++
 .cursor/rules/rules-index.mdc           |  11 +
 .cursor/skills/fill-changelog/SKILL.md  | 146 +++++++++++
 .cursor/skills/review-changes/SKILL.md  | 206 ++++++++++++++++
 .yarn/versions/d87e5b12.yml             |   2 +
 14 files changed, 1744 insertions(+)
 create mode 100644 .cursor/agents/reviewer-changelog.md
 create mode 100644 .cursor/agents/reviewer-dependencies.md
 create mode 100644 .cursor/agents/reviewer-eslint.md
 create mode 100644 .cursor/agents/reviewer-prettier.md
 create mode 100644 .cursor/agents/reviewer-tests.md
 create mode 100644 .cursor/agents/reviewer-typescript.md
 create mode 100644 .cursor/agents/reviewer-versioning.md
 create mode 100644 .cursor/rules/CODE_STYLE.mdc
 create mode 100644 .cursor/rules/TESTING_GUIDELINES.mdc
 create mode 100644 .cursor/rules/TYPESCRIPT_GUIDELINES.mdc
 create mode 100644 .cursor/rules/rules-index.mdc
 create mode 100644 .cursor/skills/fill-changelog/SKILL.md
 create mode 100644 .cursor/skills/review-changes/SKILL.md
 create mode 100644 .yarn/versions/d87e5b12.yml

diff --git a/.cursor/agents/reviewer-changelog.md b/.cursor/agents/reviewer-changelog.md
new file mode 100644
index 0000000..e3efc2b
--- /dev/null
+++ b/.cursor/agents/reviewer-changelog.md
@@ -0,0 +1,122 @@
+---
+name: reviewer-changelog
+description: Validates changelog entries during code reviews. Use proactively during code reviews to verify changelog drafts are present and high quality.
+inputs:
+  - id: branch
+    type: currentBranch
+    description: The branch to review
+---
+
+You are a changelog validator for code reviews using Yarn's deferred versioning with changelog drafts.
+
+## When Invoked
+
+**IMPORTANT:** Run each command exactly ONCE. Do NOT re-run commands for verification.
+
+### Step 1: Run Changelog Check Command
+
+1. Run `yarn changelog check` once
+2. If command fails → **Critical Issue** (missing/invalid changelog)
+
+The command validates:
+
+- Every release in `.yarn/versions/*.yml` has a corresponding changelog file in `.yarn/changelogs/`
+- Major releases have filled "💥 Breaking Changes" section
+- At least one section has content (no empty changelogs)
+- Version type in changelog matches the version manifest
+
+### Step 2: Semantic Content Review
+
+If the command passes, perform a deeper quality review of the changelog content:
+
+#### 2.1 Load Changelog Drafts
+
+Use **Glob** tool to find `.yarn/changelogs/*.md` files, then **Read** tool to load them.
+
+#### 2.2 Load Branch Changes
+
+Run:
+
+```bash
+git diff master...HEAD --stat
+git log master...HEAD --oneline
+```
+
+Use **Read** tool on key changed files to understand what was actually changed.
+
+#### 2.3 Validate Content Matches Changes
+
+Compare changelog content against actual changes:
+
+**For Major Versions:**
+
+- [ ] All breaking changes are documented with descriptive titles
+- [ ] Each breaking change explains WHAT changed and WHY
+- [ ] Before/after code examples are provided for API changes
+- [ ] Migration guide is included with step-by-step instructions
+- [ ] Impact is explained (who is affected)
+
+**For Minor Versions:**
+
+- [ ] New features are documented with descriptive titles
+- [ ] Usage examples are provided
+- [ ] Benefits/use cases are explained
+
+**For Patch Versions:**
+
+- [ ] Bug fixes are specific (not vague "fixed bugs")
+- [ ] Each fix describes what was broken
+
+**For All Versions:**
+
+- [ ] Content is written as documentation, not git log
+- [ ] No vague terms like "improved", "updated", "refactored"
+
+#### 2.4 Check for Missing Documentation
+
+Flag if:
+
+- Breaking changes exist in code but not documented in changelog
+- New exports/features exist but not documented
+- Bug fixes are present but not mentioned
+
+## Output Format
+
+### If Changelog Check Fails
+
+Report as **Critical Issue**:
+
+- The specific error from the command
+- How to fix it (e.g., "Run `yarn changelog create` to generate missing changelog")
+
+### If Content Quality Issues Found
+
+Report by severity:
+
+**Critical Issues (Must Fix):**
+
+- Major version missing breaking changes documentation
+- Empty changelog sections
+
+**Warnings (Should Fix):**
+
+- Vague descriptions ("updated code" instead of specific changes)
+- Missing code examples for API changes
+- Missing migration guide for major versions
+- Undocumented breaking changes detected in code
+
+**Suggestions (Consider):**
+
+- Adding more context to feature descriptions
+- Including use cases or benefits
+- Improving before/after examples
+
+For each issue, provide:
+
+1. File path
+2. What's wrong
+3. How to improve it
+
+### If All Checks Pass
+
+Simply state: "Changelog check passed - all changelog entries are valid and high quality."
diff --git a/.cursor/agents/reviewer-dependencies.md b/.cursor/agents/reviewer-dependencies.md
new file mode 100644
index 0000000..5318c37
--- /dev/null
+++ b/.cursor/agents/reviewer-dependencies.md
@@ -0,0 +1,142 @@
+---
+name: reviewer-dependencies
+description: Validates dependency changes during code reviews. Use proactively during code reviews to verify dependency consistency.
+inputs:
+  - id: branch
+    type: currentBranch
+    description: The branch to review
+---
+
+You are a dependency validator for code reviews.
+
+## When Invoked
+
+**IMPORTANT:** Run each command exactly ONCE. Do NOT re-run commands for verification.
+
+### Step 1: Detect Dependency Changes
+
+Run:
+
+```bash
+git diff master...HEAD --name-only | grep -E "package\.json$"
+```
+
+If no `package.json` files changed → Report: "No dependency changes detected." and stop.
+
+### Step 2: Analyze Changed Dependencies
+
+For each changed `package.json`, run:
+
+```bash
+git diff master...HEAD -- <path-to-package.json>
+```
+
+Parse the diff to identify:
+
+- **Added dependencies**: New entries in `dependencies`, `devDependencies`, or `peerDependencies`
+- **Removed dependencies**: Deleted entries
+- **Updated dependencies**: Changed version numbers
+- **Moved dependencies**: Dependencies moved between types (e.g., from `devDependencies` to `peerDependencies`)
+
+### Step 3: Validate Consistency
+
+#### 3.1 Load All Package.json Files
+
+Use **Glob** tool to find `package.json` and `frontend/package.json`, then **Read** tool to load them.
+
+#### 3.2 Check Version Consistency
+
+For each non-workspace dependency that appears in multiple package.json files, verify the version is consistent:
+
+**Check across all dependency types:**
+
+- `dependencies`
+- `devDependencies`
+- `peerDependencies`
+
+**Flag inconsistencies:**
+
+| Scenario                                                                       | Severity     | Example                                                                |
+| ------------------------------------------------------------------------------ | ------------ | ---------------------------------------------------------------------- |
+| Same dependency, different versions in different package.json files            | **Critical** | `react: ^18.0.0` in root, `react: ^19.0.0` in frontend                 |
+| Same dependency, different versions in different dep types within same package | **Critical** | `devDependencies: react ^19.2.4` but `peerDependencies: react ^18.0.0` |
+
+### Step 4: Check Changelog Documentation
+
+**IMPORTANT:** Do NOT create or modify changelog files - that is the changelog reviewer's responsibility.
+
+If dependency changes were detected in Step 2:
+
+1. Use **Glob** to check if `.yarn/changelogs/*.md` files exist
+2. If changelogs exist, **Read** them and check for `📦 Dependencies` section
+3. If dependency changes are not documented → **Critical Issue**
+
+## Output Format
+
+### Summary Section
+
+Start with a brief summary:
+
+```
+## Dependency Review Summary
+
+- **Packages with dependency changes:** [list]
+- **Total dependencies added:** X
+- **Total dependencies updated:** X
+- **Total dependencies removed:** X
+```
+
+### Critical Issues (Must Fix)
+
+**All dependency issues are Critical.** Dependencies affect the entire project and downstream consumers - inconsistencies can cause runtime failures, version conflicts, and broken builds.
+
+Report as **Critical Issue**:
+
+- Version mismatch for same dependency across packages
+- Dev dependency version doesn't satisfy peer dependency range
+- Dependency changes not documented in changelog (if changelog exists)
+
+### If No Issues Found
+
+Simply state: "Dependency check passed - all dependencies are consistent."
+
+## Examples
+
+### Critical Issue Example
+
+```
+## Critical Issues
+
+### Version Mismatch: @monaco-editor/react
+
+The dependency `@monaco-editor/react` has inconsistent versions:
+
+| Package  | Type            | Version |
+|----------|-----------------|---------|
+| root     | devDependencies | ^4.6.0  |
+| frontend | dependencies    | ^4.5.0  |
+
+**Fix:** Update all packages to use the same version (recommend: `^4.6.0`)
+```
+
+### Critical Issue Example: Missing Changelog Documentation
+
+```
+## Critical Issues
+
+### Dependency Changes Not Documented
+
+Dependency changes detected but no `📦 Dependencies` section found in changelog.
+
+Changed dependencies:
+- Updated: `typescript` ^5.8.0 → ^5.9.3
+- Added: `@types/node` ^22.0.0
+
+**Fix:** Add a `📦 Dependencies` section to the changelog documenting these changes.
+```
+
+## Notes
+
+- This reviewer focuses on **consistency validation**, not changelog creation
+- All issues are **Critical** - dependency inconsistencies affect the entire project
+- This reviewer runs in parallel with `reviewer-changelog` - both only read existing changelogs, neither creates them
diff --git a/.cursor/agents/reviewer-eslint.md b/.cursor/agents/reviewer-eslint.md
new file mode 100644
index 0000000..3cc928a
--- /dev/null
+++ b/.cursor/agents/reviewer-eslint.md
@@ -0,0 +1,29 @@
+---
+name: reviewer-eslint
+description: Runs ESLint checks during code reviews. Use proactively during code reviews to verify code quality and linting rules.
+---
+
+You are an ESLint checker for code reviews.
+
+## When Invoked
+
+**IMPORTANT:** Run `yarn lint` exactly ONCE. Do NOT re-run the command for any reason (verification, double-checking, etc.). Base your entire report on the single execution.
+
+1. Run `yarn lint` once and capture the output
+2. Analyze the exit code and output from that single run
+3. Report findings immediately - do not re-run
+
+## Output Format
+
+### If Errors Found (non-zero exit code)
+
+Report each error as a **Critical Issue** with:
+
+- File path and line number
+- The rule that was violated
+- The error message
+- Brief suggestion on how to fix it (if obvious)
+
+### If No Errors (exit code 0)
+
+Simply state: "ESLint check passed - no linting errors found."
diff --git a/.cursor/agents/reviewer-prettier.md b/.cursor/agents/reviewer-prettier.md
new file mode 100644
index 0000000..cb2bade
--- /dev/null
+++ b/.cursor/agents/reviewer-prettier.md
@@ -0,0 +1,27 @@
+---
+name: reviewer-prettier
+description: Runs Prettier formatting checks during code reviews. Use proactively during code reviews to verify code formatting.
+---
+
+You are a Prettier formatting checker for code reviews.
+
+## When Invoked
+
+**IMPORTANT:** Run `yarn prettier:check` exactly ONCE. Do NOT re-run the command for any reason (verification, double-checking, etc.). Base your entire report on the single execution.
+
+1. Run `yarn prettier:check` once to check for formatting issues
+2. Analyze the exit code and output from that single run
+3. Report findings immediately - do not re-run
+
+## Output Format
+
+### If Errors Found
+
+Report each unformatted file as a **Critical Issue** with:
+
+- File path
+- Instruction to run `yarn prettier` to fix formatting
+
+### If No Errors
+
+Simply state: "Prettier check passed - all files are properly formatted."
diff --git a/.cursor/agents/reviewer-tests.md b/.cursor/agents/reviewer-tests.md
new file mode 100644
index 0000000..3278bca
--- /dev/null
+++ b/.cursor/agents/reviewer-tests.md
@@ -0,0 +1,112 @@
+---
+name: reviewer-tests
+description: Runs unit tests and assesses test coverage during code reviews. Use proactively during code reviews to verify all tests pass and new code has adequate coverage.
+---
+
+You are a unit test and coverage reviewer for code reviews.
+
+## When Invoked
+
+**IMPORTANT:** Run `yarn test:unit` exactly ONCE. Do NOT re-run the command for any reason (verification, double-checking, etc.). Base your entire report on the single execution.
+
+### Step 1: Run Unit Tests
+
+1. Run `yarn test:unit` once to execute all unit tests
+2. Analyze the exit code and output from that single run
+3. If any tests fail, report them as **Critical Issues**
+
+### Step 2: Assess Test Coverage for Changed Code
+
+If tests pass, analyze whether new/changed code has adequate test coverage:
+
+#### 2.1 Identify Changed Source Files
+
+```bash
+git diff master...HEAD --name-only -- "*.ts" "*.tsx" | grep -v "\.spec\."
+```
+
+#### 2.2 Check for Corresponding Test Files
+
+For each changed source file, verify a test file exists:
+
+- `frontend/src/foo.ts` → `frontend/src/foo.spec.ts`
+- `frontend/src/components/bar.tsx` → `frontend/src/components/bar.spec.tsx`
+
+#### 2.3 Analyze Test Quality
+
+Use **Read** tool on test files to assess:
+
+- **Coverage of new functions/exports** - Are new public functions tested?
+- **Meaningful assertions** - Tests should verify behavior, not just run without errors
+- **Edge cases** - Error handling, boundary conditions, empty states
+- **Mocking appropriateness** - External dependencies properly mocked
+
+#### 2.4 Check for False Positive Tests
+
+Identify tests that could pass without actually verifying correct behavior:
+
+- **Missing `expect.assertions()`** - Tests with assertions only inside `catch` blocks or conditional branches MUST use `expect.assertions(n)` to ensure assertions run. Without it, if the code unexpectedly resolves/doesn't throw, the test passes silently with zero assertions.
+
+  ```typescript
+  // ❌ False positive risk - passes if function doesn't throw
+  it('should throw on error', async () => {
+    try {
+      await functionThatShouldThrow()
+    } catch (error) {
+      expect(error).toBeInstanceOf(Error)
+    }
+  })
+
+  // ✅ Correct - fails if assertions don't run
+  it('should throw on error', async () => {
+    expect.assertions(1)
+    try {
+      await functionThatShouldThrow()
+    } catch (error) {
+      expect(error).toBeInstanceOf(Error)
+    }
+  })
+  ```
+
+- **Empty catch blocks** - Tests that catch errors but don't assert on them may hide failures
+- **Assertions in callbacks** - Assertions inside `.forEach()`, `.map()`, or event handlers that may not execute
+- **Async assertions without await** - Promises that resolve after the test completes
+- **Mocks that always return success** - Tests where mocks don't reflect realistic failure scenarios
+
+## Output Format
+
+### If Tests Fail
+
+Report each failing test as a **Critical Issue** with:
+
+- Test file path
+- Test name/description that failed
+- The error message or assertion that failed
+- Brief suggestion on what might be wrong (if obvious from the error)
+
+### If Coverage Issues Found
+
+Report by severity:
+
+**Critical (Must Fix):**
+
+- False positive tests - tests that would pass even if the code is broken (e.g., assertions in catch blocks without `expect.assertions()`)
+- New exported functions/components without any tests
+- Changed logic without updated tests
+- Assertions inside loops/callbacks without `expect.assertions()`
+
+**High Priority (Should Fix):**
+
+- Missing edge case coverage
+- Tests that only check happy path
+- Shallow assertions (e.g., only checking component renders)
+
+For each issue, provide:
+
+1. Source file and function/component name
+2. What's missing
+3. Suggested test case to add
+
+### If All Checks Pass
+
+Simply state: "Unit tests passed - all tests are green and coverage is adequate."
diff --git a/.cursor/agents/reviewer-typescript.md b/.cursor/agents/reviewer-typescript.md
new file mode 100644
index 0000000..84b63d9
--- /dev/null
+++ b/.cursor/agents/reviewer-typescript.md
@@ -0,0 +1,28 @@
+---
+name: reviewer-typescript
+description: Runs TypeScript type checking during code reviews. Use proactively during code reviews to verify type safety.
+---
+
+You are a TypeScript type checker for code reviews.
+
+## When Invoked
+
+**IMPORTANT:** Run `yarn build` exactly ONCE. Do NOT re-run the command for any reason (verification, double-checking, etc.). Base your entire report on the single execution.
+
+1. Run `yarn build` once to check for TypeScript errors
+2. Analyze the exit code and output from that single run
+3. Report findings immediately - do not re-run
+
+## Output Format
+
+### If Errors Found
+
+Report each error as a **Critical Issue** with:
+
+- File path and line number
+- The error message
+- Brief suggestion on how to fix it (if obvious)
+
+### If No Errors
+
+Simply state: "TypeScript check passed - no type errors found."
diff --git a/.cursor/agents/reviewer-versioning.md b/.cursor/agents/reviewer-versioning.md
new file mode 100644
index 0000000..c309b63
--- /dev/null
+++ b/.cursor/agents/reviewer-versioning.md
@@ -0,0 +1,104 @@
+---
+name: reviewer-versioning
+description: Validates version bumps during code reviews. Use proactively during code reviews to verify version bumps are present and appropriate for the changes.
+inputs:
+  - id: branch
+    type: currentBranch
+    description: The branch to review
+---
+
+You are a versioning validator for code reviews using Yarn's deferred versioning.
+
+## When Invoked
+
+**IMPORTANT:** Run each command exactly ONCE. Do NOT re-run commands for verification.
+
+### Step 1: Run Version Check Command
+
+1. Run `yarn version check` once
+2. If command fails → **Critical Issue** (missing version bump for changed packages)
+
+### Step 2: Validate Version Bump Type vs Changes
+
+If the command passes, analyze whether the declared version bump types match the actual changes:
+
+#### 2.1 Read Version Manifests
+
+Use **Glob** tool to find `.yarn/versions/*.yml` files, then **Read** tool to load them.
+
+Each manifest contains:
+
+```yaml
+releases:
+  'package-name': patch | minor | major
+```
+
+Identify:
+
+- Which packages have version bumps staged
+- What type of bump (patch/minor/major) is declared for each
+
+#### 2.2 Analyze Branch Changes
+
+Run:
+
+```bash
+git diff master...HEAD --name-only
+```
+
+Then use **Read** tool on changed files to understand the nature of changes:
+
+- **Breaking changes indicators:**
+  - Removed or renamed exports
+  - Changed function signatures (parameters added/removed/reordered)
+  - Changed return types
+  - Removed public API methods
+  - Changed required props in components
+
+- **New feature indicators:**
+  - New exported functions, classes, or components
+  - New optional parameters or props
+  - New configuration options
+
+- **Bug fix indicators:**
+  - Internal logic changes without API changes
+  - Error handling improvements
+  - Performance optimizations without API changes
+
+#### 2.3 Validate Version Type Matches Changes
+
+For each package with a version bump:
+
+| Declared Bump | Required Changes                | Issue if Mismatch                                                                  |
+| ------------- | ------------------------------- | ---------------------------------------------------------------------------------- |
+| **major**     | Breaking changes must exist     | Warning: "Package has `major` bump but no breaking changes detected"               |
+| **minor**     | New features/exports must exist | Warning: "Package has `minor` bump but no new exports detected - consider `patch`" |
+| **patch**     | Only fixes, no new public API   | Warning: "Package has `patch` bump but adds new export `foo` - consider `minor`"   |
+
+#### 2.4 Check for Missing Bumps
+
+Compare packages with changes against packages with version bumps:
+
+- If a package has source file changes but no version bump → Warning: "Package was modified but has no version bump staged"
+- Exclude non-source changes (tests, docs, config) from this check
+
+## Output Format
+
+### If Version Check Fails
+
+Report as **Critical Issue**:
+
+- List packages that need version bumps
+- Provide command to fix: `yarn bumpVersions` (interactive) or `yarn version patch/minor/major` for specific package
+
+### If Version Type Mismatches Found
+
+Report as **Warnings**:
+
+- Package name and declared version type
+- What was expected based on changes
+- Specific files/exports that indicate the mismatch
+
+### If All Checks Pass
+
+Simply state: "Version check passed - all package versions are properly staged."
diff --git a/.cursor/rules/CODE_STYLE.mdc b/.cursor/rules/CODE_STYLE.mdc
new file mode 100644
index 0000000..68ca5ce
--- /dev/null
+++ b/.cursor/rules/CODE_STYLE.mdc
@@ -0,0 +1,315 @@
+---
+name: Code Style Guidelines
+description: Code formatting, naming conventions, and file organization
+globs:
+  - '**/*.ts'
+  - '**/*.tsx'
+alwaysApply: true
+---
+
+# Code Style Guidelines
+
+## Formatting Standards
+
+### Prettier Configuration
+
+This project uses Prettier for code formatting. **Always use the project's Prettier configuration**.
+
+**Configuration file:** `prettier.config.js`
+
+```bash
+# Format code
+yarn prettier
+
+# Check formatting
+yarn prettier:check
+```
+
+### ESLint Configuration
+
+This project uses ESLint for code quality. **Always use the project's ESLint configuration**.
+
+**Configuration file:** `eslint.config.js`
+
+```bash
+# Lint code
+yarn lint
+```
+
+### Automated Formatting
+
+Code is automatically formatted on commit via Husky and lint-staged:
+
+```json
+{
+  "lint-staged": {
+    "*.{ts,tsx}": ["eslint --ext .tsx,.ts --cache --fix", "prettier --write", "git add"]
+  }
+}
+```
+
+## Naming Conventions
+
+### Files and Directories
+
+#### Source Files
+
+- **kebab-case** for all files
+- `.ts` for TypeScript, `.tsx` for JSX components
+- One main export per file
+
+```
+✅ Good:
+frontend/src/components/theme-switch/index.tsx
+frontend/src/services/session.ts
+frontend/src/pages/home.tsx
+
+❌ Avoid:
+frontend/src/components/ThemeSwitch.tsx
+frontend/src/services/Session.ts
+frontend/src/pages/Home.tsx
+```
+
+#### Test Files
+
+- **Same name as source** with `.spec.ts` suffix
+- Co-located with source file when possible
+
+```
+✅ Good:
+frontend/src/environment-options.ts
+frontend/src/environment-options.spec.ts
+
+❌ Avoid:
+test/environment-options.spec.ts (not co-located)
+frontend/src/environment-options.test.ts (use .spec.ts)
+```
+
+### Components and Classes
+
+- **PascalCase** for components, classes, and types
+- Descriptive and clear purpose
+
+```typescript
+// ✅ Good
+export const ThemeSwitch = Shade(...)
+export const MonacoEditor = Shade(...)
+export type EditorOptions = {}
+
+// ❌ Avoid
+export const themeSwitch = Shade(...) // Wrong case
+export const editor = Shade(...) // Too generic
+```
+
+### Functions and Variables
+
+- **camelCase** for functions and variables
+- **UPPER_SNAKE_CASE** for constants
+
+```typescript
+// ✅ Good
+export function getEnvironmentOptions() {}
+export const isValidJson = true;
+export const DEFAULT_THEME = 'dark';
+
+// ❌ Avoid
+export function GetEnvironmentOptions() {}
+export const IsValidJson = true;
+```
+
+## Project Structure
+
+### Directory Organization
+
+```
+json-tools/
+├── frontend/                # Frontend application
+│   └── src/
+│       ├── index.tsx        # App entry point
+│       ├── components/      # Reusable components
+│       │   ├── header.tsx
+│       │   ├── body.tsx
+│       │   ├── layout.tsx
+│       │   ├── theme-switch/
+│       │   │   └── index.tsx
+│       │   ├── github-logo/
+│       │   │   ├── index.tsx
+│       │   │   ├── gh-dark.png
+│       │   │   └── gh-light.png
+│       │   └── monaco/
+│       │       ├── monaco-editor.tsx
+│       │       └── monaco-diff-editor.tsx
+│       ├── pages/           # Page components
+│       │   ├── home.tsx
+│       │   ├── compare.tsx
+│       │   └── validate.tsx
+│       ├── services/        # Frontend services
+│       └── themes/          # Theme definitions
+└── e2e/                     # End-to-end tests
+    └── page.spec.ts
+```
+
+### Component File Structure
+
+Components should be organized in directories when they have assets:
+
+```
+components/
+├── theme-switch/
+│   └── index.tsx           # Component with no assets
+├── github-logo/
+│   ├── index.tsx           # Component
+│   ├── gh-dark.png         # Dark theme asset
+│   └── gh-light.png        # Light theme asset
+└── header.tsx              # Simple component (no directory needed)
+```
+
+## Import Ordering
+
+### Import Order
+
+1. **Node built-ins**
+2. **External dependencies** (npm packages)
+3. **FuryStack packages** (`@furystack/*`)
+4. **Relative imports**
+5. **Type imports** (if separated)
+
+```typescript
+// ✅ Good - organized imports
+import { EventEmitter } from 'events';
+
+import { Shade } from '@furystack/shades';
+import { Injector } from '@furystack/inject';
+
+import { MonacoEditor } from '../components/monaco/monaco-editor.js';
+import type { EditorOptions } from './types.js';
+
+// ❌ Avoid - random ordering
+import { MonacoEditor } from '../components/monaco/monaco-editor.js';
+import { EventEmitter } from 'events';
+import { Injector } from '@furystack/inject';
+```
+
+### Import Grouping
+
+Separate import groups with blank lines:
+
+```typescript
+// ✅ Good - separated groups
+import { Injector } from '@furystack/inject';
+import { Shade } from '@furystack/shades';
+
+import { MonacoEditor } from './components/monaco/monaco-editor.js';
+```
+
+## Code Organization
+
+### Component File Structure
+
+```typescript
+// 1. Imports
+import { Shade } from '@furystack/shades';
+
+// 2. Types
+type MyComponentProps = {
+  title: string;
+};
+
+// 3. Component
+export const MyComponent = Shade<MyComponentProps>({
+  shadowDomName: 'my-component',
+  render: ({ props }) => {
+    return <div>{props.title}</div>;
+  },
+});
+```
+
+### Service File Structure
+
+```typescript
+// 1. Imports
+import { Injectable, Injected } from '@furystack/inject';
+import { ObservableValue } from '@furystack/utils';
+
+// 2. Types
+type ServiceState = {
+  data: string;
+};
+
+// 3. Service class
+@Injectable({ lifetime: 'singleton' })
+export class MyService {
+  // Injected dependencies
+  @Injected(OtherService)
+  private declare otherService: OtherService;
+
+  // Observable state
+  public state = new ObservableValue<ServiceState | null>(null);
+
+  // Public methods
+  public getData(): string {
+    return this.state.getValue()?.data ?? '';
+  }
+}
+```
+
+## JSX/TSX Code Style
+
+### JSX Formatting
+
+```tsx
+// ✅ Good - multi-line for readability
+<button
+  type="button"
+  onclick={handleClick}
+  style={{ padding: '8px 16px' }}
+>
+  Save Changes
+</button>
+
+// ✅ Good - single line for simple cases
+<button onclick={handleClick}>Save</button>
+
+// ❌ Avoid - hard to read
+<button type="button" onclick={handleClick} style={{ padding: '8px 16px' }}>Save Changes</button>
+```
+
+### Conditional Rendering
+
+```tsx
+// ✅ Good - logical AND for simple cases
+{isLoading && <div>Loading...</div>}
+
+// ✅ Good - ternary for if-else
+{isLoading ? <div>Loading...</div> : <div>Content</div>}
+
+// ✅ Good - early return for complex cases
+if (isLoading) return <div>Loading...</div>;
+if (error) return <div>Error: {error}</div>;
+return <div>Content</div>;
+
+// ❌ Avoid - nested ternaries
+{isLoading ? <div>Loading...</div> : error ? <div>Error</div> : <div>Content</div>}
+```
+
+## Summary
+
+**Key Principles:**
+
+1. **Follow project's Prettier and ESLint configs**
+2. **Use consistent naming:**
+   - PascalCase: Components, classes, types
+   - camelCase: Functions, variables
+   - kebab-case: File names
+   - UPPER_SNAKE_CASE: Constants
+3. **Organize imports** by category with blank lines
+4. **Co-locate tests** with source files
+5. **Structure components** in directories when they have assets
+
+**Tools:**
+
+- Prettier: `yarn prettier`
+- ESLint: `yarn lint`
+- Type Check: `yarn build`
+- Unit Tests: `yarn test:unit`
+- E2E Tests: `yarn test:e2e`
diff --git a/.cursor/rules/TESTING_GUIDELINES.mdc b/.cursor/rules/TESTING_GUIDELINES.mdc
new file mode 100644
index 0000000..1aaafa3
--- /dev/null
+++ b/.cursor/rules/TESTING_GUIDELINES.mdc
@@ -0,0 +1,234 @@
+---
+name: Testing Guidelines
+description: Unit testing with Vitest and E2E testing with Playwright
+globs:
+  - '**/*.spec.ts'
+  - '**/*.spec.tsx'
+  - 'e2e/**/*.ts'
+alwaysApply: false
+---
+
+# Testing Guidelines
+
+## Unit Testing with Vitest
+
+### Test Structure
+
+```typescript
+// ✅ Good - clear test structure
+describe('EnvironmentOptions', () => {
+  describe('getEnvironmentOptions', () => {
+    it('should return default options when no URL params', () => {
+      // Arrange
+      const url = new URL('http://localhost');
+
+      // Act
+      const result = getEnvironmentOptions(url);
+
+      // Assert
+      expect(result.theme).toBe('dark');
+    });
+  });
+});
+```
+
+### Test All Exported Functions
+
+Every exported function should have tests:
+
+```typescript
+// ✅ Good - testing public API
+describe('orderFields', () => {
+  it('should order object fields alphabetically', () => {
+    const input = { z: 1, a: 2, m: 3 };
+    const result = orderFields(input);
+    expect(Object.keys(result)).toEqual(['a', 'm', 'z']);
+  });
+
+  it('should handle nested objects', () => {
+    const input = { outer: { z: 1, a: 2 } };
+    const result = orderFields(input);
+    expect(Object.keys(result.outer)).toEqual(['a', 'z']);
+  });
+
+  it('should handle empty objects', () => {
+    const result = orderFields({});
+    expect(result).toEqual({});
+  });
+});
+```
+
+### Test Edge Cases
+
+Test boundary conditions and error scenarios:
+
+```typescript
+// ✅ Good - testing edge cases
+describe('parseJson', () => {
+  it('should handle valid JSON', () => {
+    const result = parseJson('{"key": "value"}');
+    expect(result).toEqual({ key: 'value' });
+  });
+
+  it('should handle invalid JSON', () => {
+    const result = parseJson('invalid');
+    expect(result).toBeNull();
+  });
+
+  it('should handle empty string', () => {
+    const result = parseJson('');
+    expect(result).toBeNull();
+  });
+
+  it('should handle null input', () => {
+    const result = parseJson(null as unknown as string);
+    expect(result).toBeNull();
+  });
+});
+```
+
+### Avoid False Positive Tests
+
+Ensure assertions always run:
+
+```typescript
+// ❌ False positive risk - passes if function doesn't throw
+it('should throw on error', async () => {
+  try {
+    await functionThatShouldThrow();
+  } catch (error) {
+    expect(error).toBeInstanceOf(Error);
+  }
+});
+
+// ✅ Correct - fails if assertions don't run
+it('should throw on error', async () => {
+  expect.assertions(1);
+  try {
+    await functionThatShouldThrow();
+  } catch (error) {
+    expect(error).toBeInstanceOf(Error);
+  }
+});
+
+// ✅ Better - use expect().rejects
+it('should throw on error', async () => {
+  await expect(functionThatShouldThrow()).rejects.toThrow();
+});
+```
+
+## E2E Testing with Playwright
+
+### Page Object Pattern
+
+```typescript
+// e2e/page.spec.ts
+import { test, expect } from '@playwright/test';
+
+test.describe('Home Page', () => {
+  test.beforeEach(async ({ page }) => {
+    await page.goto('/');
+  });
+
+  test('should display editor', async ({ page }) => {
+    await expect(page.locator('.monaco-editor')).toBeVisible();
+  });
+
+  test('should format JSON on button click', async ({ page }) => {
+    const editor = page.locator('.monaco-editor');
+    await editor.fill('{"z":1,"a":2}');
+    
+    await page.click('button:has-text("Format")');
+    
+    // Verify formatted output
+    await expect(editor).toContainText('"a": 2');
+  });
+});
+```
+
+### Visual Regression Testing
+
+```typescript
+// ✅ Good - visual snapshot testing
+test('should match visual snapshot', async ({ page }) => {
+  await page.goto('/');
+  await expect(page).toHaveScreenshot('home-content.png');
+});
+
+test('should match title snapshot', async ({ page }) => {
+  await page.goto('/');
+  const title = page.locator('h1');
+  await expect(title).toHaveScreenshot('title.png');
+});
+```
+
+### Waiting for Elements
+
+```typescript
+// ✅ Good - wait for element to be ready
+test('should load editor', async ({ page }) => {
+  await page.goto('/');
+  
+  // Wait for Monaco editor to initialize
+  await page.waitForSelector('.monaco-editor', { state: 'visible' });
+  
+  // Now interact with the editor
+  await page.click('.monaco-editor');
+});
+```
+
+## Test Coverage
+
+### Coverage Requirements
+
+- **Exported functions**: 100% coverage required
+- **Components**: Key render paths covered
+- **E2E**: Critical user flows covered
+
+```bash
+# Run unit tests with coverage
+yarn test:unit --coverage
+
+# Run E2E tests
+yarn test:e2e
+```
+
+## Running Tests
+
+### Available Commands
+
+```bash
+# Unit tests
+yarn test:unit
+
+# E2E tests
+yarn test:e2e
+
+# All tests
+yarn test:unit && yarn test:e2e
+```
+
+## Summary
+
+**Key Principles:**
+
+1. **Test all exported APIs** - 100% coverage for exports
+2. **Test edge cases** - Null, undefined, errors, empty states
+3. **Avoid false positives** - Use `expect.assertions()` when needed
+4. **E2E for critical flows** - Test main user journeys
+5. **Visual regression** - Snapshot testing for UI
+6. **Clear test structure** - describe > describe > it
+
+**Testing Checklist:**
+
+- [ ] All exported functions have tests
+- [ ] Edge cases tested (null, undefined, errors)
+- [ ] Error paths tested
+- [ ] E2E tests cover critical user flows
+- [ ] Visual snapshots updated when UI changes
+
+**Tools:**
+
+- Unit Tests: `vitest`
+- E2E Tests: `playwright`
+- Commands: `yarn test:unit`, `yarn test:e2e`
diff --git a/.cursor/rules/TYPESCRIPT_GUIDELINES.mdc b/.cursor/rules/TYPESCRIPT_GUIDELINES.mdc
new file mode 100644
index 0000000..be981a6
--- /dev/null
+++ b/.cursor/rules/TYPESCRIPT_GUIDELINES.mdc
@@ -0,0 +1,266 @@
+---
+name: TypeScript Guidelines
+description: TypeScript type safety and strict typing guidelines
+globs:
+  - '**/*.ts'
+  - '**/*.tsx'
+alwaysApply: true
+---
+
+# TypeScript Guidelines
+
+## Type Safety
+
+### NEVER use `any`
+
+There are no acceptable uses of `any` in this codebase:
+
+```typescript
+// ✅ Good - use unknown for truly unknown types
+export function processData(data: unknown): string {
+  if (typeof data === 'string') {
+    return data;
+  }
+  return JSON.stringify(data);
+}
+
+// ✅ Good - use generics for flexible types
+export function identity<T>(value: T): T {
+  return value;
+}
+
+// ❌ FORBIDDEN - using any
+export function processData(data: any): string {
+  return data.toString();
+}
+```
+
+### Explicit Types for Public APIs
+
+All exported functions and public methods should have explicit types:
+
+```typescript
+// ✅ Good - explicit types
+export function getEnvironmentOptions(): EnvironmentOptions {
+  // Implementation
+}
+
+export class EditorService {
+  public formatJson(input: string): string {
+    // Implementation
+  }
+}
+
+// ❌ Avoid - implicit return types for public APIs
+export function getEnvironmentOptions() {
+  // Return type is inferred - not ideal for public APIs
+}
+```
+
+## Type Definitions
+
+### Prefer `type` over `interface`
+
+```typescript
+// ✅ Good
+type EditorOptions = {
+  theme: 'light' | 'dark';
+  fontSize: number;
+};
+
+type JsonResult<T> = {
+  data: T;
+  valid: boolean;
+};
+
+// ❌ Avoid
+interface EditorOptions {
+  theme: string;
+  fontSize: number;
+}
+```
+
+### Component Props Types
+
+Define explicit prop types for all components:
+
+```typescript
+// ✅ Good - explicit props type
+type MonacoEditorProps = {
+  value: string;
+  onChange?: (value: string) => void;
+  language?: string;
+  readOnly?: boolean;
+};
+
+export const MonacoEditor = Shade<MonacoEditorProps>({
+  shadowDomName: 'monaco-editor',
+  render: ({ props }) => {
+    return (
+      <div data-testid="editor">
+        {/* Editor implementation */}
+      </div>
+    );
+  },
+});
+```
+
+## Type Guards
+
+### Provide Type Guards for Runtime Checks
+
+```typescript
+// ✅ Good - type guard
+export function isValidJson(value: unknown): value is object {
+  if (typeof value !== 'string') return false;
+  try {
+    JSON.parse(value);
+    return true;
+  } catch {
+    return false;
+  }
+}
+
+// Usage
+if (isValidJson(data)) {
+  console.log('Valid JSON');
+}
+```
+
+## Observable Types
+
+### Type Observable Values
+
+Always provide explicit types for ObservableValue:
+
+```typescript
+// ✅ Good - explicit observable type
+public currentTheme = new ObservableValue<'light' | 'dark'>('dark');
+public isLoading = new ObservableValue<boolean>(false);
+public editorContent = new ObservableValue<string>('');
+
+// ❌ Avoid - relying on inference for complex types
+public currentTheme = new ObservableValue(null); // Type is ObservableValue<null>
+```
+
+## Generic Patterns
+
+### Use Descriptive Generic Names
+
+```typescript
+// ✅ Good - descriptive generic names
+type JsonParseResult<TData> = {
+  data: TData;
+  valid: boolean;
+  error?: string;
+};
+
+// ❌ Avoid - unclear generic names
+type JsonParseResult<T> = {
+  data: T;
+  valid: boolean;
+};
+```
+
+### Constrain Generics When Appropriate
+
+```typescript
+// ✅ Good - constrained generic
+export function formatValue<T extends string | number | boolean>(value: T): string {
+  return String(value);
+}
+```
+
+## Strict Null Checks
+
+### Handle Null and Undefined Explicitly
+
+```typescript
+// ✅ Good - explicit null handling
+export function parseJson(input: string): object | null {
+  try {
+    return JSON.parse(input);
+  } catch {
+    return null;
+  }
+}
+
+// ✅ Good - use optional chaining
+const theme = options?.theme ?? 'dark';
+
+// ❌ Avoid - ignoring potential null
+const theme = options.theme; // Error if options is null
+```
+
+## Utility Types
+
+### Use TypeScript Utility Types
+
+```typescript
+// ✅ Good - using utility types
+type EditorOptions = {
+  theme: 'light' | 'dark';
+  fontSize: number;
+  language: string;
+};
+
+// Partial for optional fields
+type PartialEditorOptions = Partial<EditorOptions>;
+
+// Pick for specific fields
+type ThemeOption = Pick<EditorOptions, 'theme'>;
+
+// Omit for excluding fields
+type EditorWithoutTheme = Omit<EditorOptions, 'theme'>;
+```
+
+## Type Inference
+
+### Let TypeScript Infer When Possible
+
+```typescript
+// ✅ Good - let TypeScript infer internal types
+const users = ['Alice', 'Bob', 'Charlie']; // Inferred as string[]
+const count = users.length; // Inferred as number
+
+// ✅ Good - explicit for complex conditional logic
+export const getStatusDisplay = (status: string): JSX.Element | null => {
+  switch (status) {
+    case 'valid':
+      return <div>Valid</div>;
+    case 'invalid':
+      return <div>Invalid</div>;
+    default:
+      return null;
+  }
+};
+
+// ❌ Avoid - unnecessary annotations
+const count: number = 5;
+const name: string = 'John';
+```
+
+## Summary
+
+**Key Principles:**
+
+1. **NEVER use `any`** - Use `unknown`, generics, or proper types
+2. **Explicit types for exports** - Document the contract
+3. **Prefer `type` over `interface`**
+4. **Type component props** - Every Shade component should have typed props
+5. **Type observables** - Always provide explicit types for ObservableValue
+6. **Handle nulls** - Use strict null checks and optional chaining
+7. **Use type guards** - For runtime type checking
+
+**Type Safety Checklist:**
+
+- [ ] No `any` types anywhere
+- [ ] All exported functions have explicit return types
+- [ ] Component props are typed
+- [ ] Observable values have explicit types
+- [ ] Null/undefined handled explicitly
+
+**Tools:**
+
+- Type checking: `yarn build`
+- Strict mode: Enabled in `tsconfig.json`
diff --git a/.cursor/rules/rules-index.mdc b/.cursor/rules/rules-index.mdc
new file mode 100644
index 0000000..9d49b62
--- /dev/null
+++ b/.cursor/rules/rules-index.mdc
@@ -0,0 +1,11 @@
+---
+name: Rules Index
+description: Index of available rules and guidelines
+alwaysApply: true
+---
+
+This file contains a list of helpful information and context that the agent can reference when working in this codebase. Each entry provides specific guidance or rules for different aspects of the project. You can read these files using the readFile tool if the users prompt seems related.
+
+- [Code formatting, naming conventions, and file organization](./CODE_STYLE.mdc)
+- [TypeScript type safety and strict typing guidelines](./TYPESCRIPT_GUIDELINES.mdc)
+- [Unit testing with Vitest and E2E testing with Playwright](./TESTING_GUIDELINES.mdc)
diff --git a/.cursor/skills/fill-changelog/SKILL.md b/.cursor/skills/fill-changelog/SKILL.md
new file mode 100644
index 0000000..261a63c
--- /dev/null
+++ b/.cursor/skills/fill-changelog/SKILL.md
@@ -0,0 +1,146 @@
+---
+name: fill-changelog
+description: Fill changelog entries for the current branch. Use when the user asks to fill changelog, write changelog entries, update changelog, or prepare changelog for a PR.
+---
+
+# fill-changelog
+
+Automate filling changelog entries based on the changes in the current branch.
+
+## Prerequisites
+
+Version bumps MUST be configured before running this skill. If `yarn version check` fails, version files need to be adjusted first using `yarn version patch/minor/major` or `yarn bumpVersions` (interactive).
+
+## Workflow
+
+### Step 1: Validate Version Configuration
+
+Run `yarn version check` to validate version manifests exist:
+
+```bash
+yarn version check
+```
+
+**If fails:** Stop and report error. The user must run `yarn version patch`, `yarn version minor`, `yarn version major`, or `yarn bumpVersions` first to configure version bumps.
+
+### Step 2: Create/Recreate Changelog Drafts
+
+Run with force flag to ensure all drafts are created or recreated:
+
+```bash
+yarn changelog create -f
+```
+
+This creates files in `.yarn/changelogs/` with the pattern `{package-name}.{manifest-id}.md`.
+
+### Step 3: Analyze Branch Changes
+
+Gather information about changes:
+
+```bash
+git diff master...HEAD --stat
+git log master...HEAD --oneline
+```
+
+Read the changed files to understand what was actually modified.
+
+### Step 4: Read Changelog Drafts
+
+Use Glob to find `.yarn/changelogs/*.md` files, then Read to load their content.
+
+### Step 5: Fill Changelog Entries
+
+Map changes to the appropriate sections and fill the changelog drafts.
+
+## Section Mapping
+
+| Section             | When to Use                                    |
+| ------------------- | ---------------------------------------------- |
+| ✨ Features         | New functionality, new files, new capabilities |
+| 🐛 Bug Fixes        | Corrections to existing behavior               |
+| 📚 Documentation    | README, comments, documentation files          |
+| ⚡ Performance      | Optimizations                                  |
+| ♻️ Refactoring      | Code restructuring without behavior change     |
+| 🧪 Tests            | Test additions/modifications                   |
+| 📦 Build            | Build system, dependencies configuration       |
+| 👷 CI               | CI/CD configuration changes                    |
+| ⬆️ Dependencies     | Dependency updates                             |
+| 🔧 Chores           | Other maintenance tasks                        |
+| 💥 Breaking Changes | Major version only (REQUIRED)                  |
+| 🗑️ Deprecated       | Minor/Major versions only                      |
+
+## Quality Guidelines
+
+### Writing Style: Documentation, NOT Git Log
+
+Write for package consumers, not as git history.
+
+**Avoid vague terms:**
+
+- "improved", "updated", "refactored", "fixed bugs", "changed internal implementation"
+
+**Use specific, actionable language:**
+
+- "Added dark theme support with automatic system preference detection"
+- "Fixed JSON validation not detecting trailing commas"
+
+### Version-Specific Requirements
+
+**Major Versions:**
+
+- Document ALL breaking changes with descriptive titles
+- Explain WHAT changed and WHY
+- Include before/after code examples using ❌/✅ markers
+- Provide migration guide with step-by-step instructions
+- Explain impact (who is affected)
+
+**Minor Versions:**
+
+- Document new features with descriptive titles
+- Provide usage examples
+- Explain benefits/use cases
+
+**Patch Versions:**
+
+- Be specific about bug fixes (not vague "fixed bugs")
+- Describe what was broken
+
+## Entry Format Examples
+
+### Simple List (straightforward changes)
+
+```markdown
+## ✨ Features
+
+- Added JSON schema validation support
+- Implemented diff view for comparing JSON files
+```
+
+### Detailed Entry (complex changes)
+
+```markdown
+## ✨ Features
+
+### New JSON Schema Validation
+
+Validate JSON documents against JSON Schema drafts.
+
+**Usage:**
+
+Select a schema from the dropdown and paste your JSON to validate.
+```
+
+## Validation
+
+After filling entries, run:
+
+```bash
+yarn changelog check
+```
+
+This validates:
+
+- Every release has a changelog file
+- Major releases have filled "💥 Breaking Changes" section
+- At least one section has content
+- Version type matches the manifest
diff --git a/.cursor/skills/review-changes/SKILL.md b/.cursor/skills/review-changes/SKILL.md
new file mode 100644
index 0000000..84281f7
--- /dev/null
+++ b/.cursor/skills/review-changes/SKILL.md
@@ -0,0 +1,206 @@
+---
+name: review-changes
+description: Review all changes on the current branch. Use when the user asks for a code review or PR review.
+disable-model-invocation: false
+inputs:
+  - id: branch
+    type: currentBranch
+    description: The branch to review
+---
+
+# review-changes
+
+Review all changes on the current branch compared to the upstream branch.
+
+## Context
+
+{{branch}}
+
+## Determining the Base Branch
+
+**IMPORTANT:** This repository uses `master` as the integration branch.
+
+1. **Use `master` as the default base branch** for all comparisons:
+
+   ```bash
+   git diff origin/master...HEAD
+   ```
+
+2. **Verify by checking GitHub workflows** if unsure - look at `.github/workflows/*.yml` for `pull_request.branches` targets
+
+3. **Use the correct git diff syntax:**
+   - `origin/master...HEAD` - shows changes in current branch since it diverged from master
+   - Run `git log --oneline origin/master..HEAD` to see commits being reviewed
+
+## Pre-flight: Detect Change Types
+
+Before launching subagents, analyze what files changed:
+
+```bash
+git diff origin/master...HEAD --name-only
+```
+
+**Conservative skip rules (only skip when 100% safe):**
+
+| Reviewer                | Run         | Notes                                               |
+| ----------------------- | ----------- | --------------------------------------------------- |
+| `reviewer-prettier`     | ✅ Always   | Formats `.md`, `.json`, `.ts`, `.tsx`, etc.         |
+| `reviewer-versioning`   | ✅ Always   | Fast validation, can fail early                     |
+| `reviewer-changelog`    | ✅ Always   | Fast validation, can fail early                     |
+| `reviewer-dependencies` | Conditional | Run if ANY `package.json` changed                   |
+| `reviewer-typescript`   | Conditional | Skip ONLY if NO `.ts`/`.tsx` in `frontend/` changed |
+| `reviewer-eslint`       | Conditional | Skip ONLY if NO `.ts`/`.tsx` in `frontend/` changed |
+| `reviewer-tests`        | Conditional | Skip ONLY if NO `.ts`/`.tsx` in `frontend/` changed |
+
+**When in doubt, run the check.** Fast failures are better than missed issues.
+
+## Execution Strategy
+
+**IMPORTANT:** Launch ALL applicable subagents in a SINGLE parallel batch.
+Do NOT wait for one group to finish before starting another.
+
+In one tool call batch, launch all applicable reviewers:
+
+- `reviewer-prettier` (always)
+- `reviewer-versioning` (always)
+- `reviewer-changelog` (always)
+- `reviewer-dependencies` (if any `package.json` changed)
+- `reviewer-typescript` (if `.ts`/`.tsx` in `frontend/` changed)
+- `reviewer-eslint` (if `.ts`/`.tsx` in `frontend/` changed)
+- `reviewer-tests` (if `.ts`/`.tsx` in `frontend/` changed)
+
+**Note:** `reviewer-dependencies` checks changelog documentation but does NOT create/modify changelogs. If both changelog and dependency changes exist, both reviewers run in parallel - the dependency reviewer only reads existing changelogs.
+
+## Analysis Required
+
+Check for:
+
+**Code Quality & Bugs:**
+
+- Potential bugs, edge cases, or runtime errors
+- Code smells, anti-patterns, or violations of repository rules (check `.cursor/rules/*`)
+- Newly added TODO/FIXME comments that should be addressed
+- Suspicious or unclear code changes
+- Business logic changes that need scrutiny
+
+**Standards & Compliance:**
+
+- Delegate to `reviewer-typescript` subagent to check for TypeScript errors
+- Delegate to `reviewer-eslint` subagent to check for linting violations
+- Delegate to `reviewer-prettier` subagent to check for formatting issues
+- Breaking changes to public API surface
+
+**Shades Component Patterns:**
+
+- Flag `useState()` used only for CSS-representable states (hover, focus, active)
+- Recommend using `css` property with pseudo-selectors instead:
+
+  ```typescript
+  // ❌ Anti-pattern to flag
+  const [isHovered, setIsHovered] = useState('hover', false)
+  <div onMouseEnter={() => setIsHovered(true)} style={{ opacity: isHovered ? 1 : 0.7 }} />
+
+  // ✅ Recommend instead
+  css: { opacity: '0.7', '&:hover': { opacity: '1' } }
+  ```
+
+- Static `style` props in Shade definitions should use `css` instead
+
+**Testing & Coverage:**
+
+- Delegate to `reviewer-tests` subagent to run unit tests and assess coverage
+- Missing test coverage for new/changed functions
+- Test quality and edge case coverage
+
+**Performance & Security:**
+
+- Performance concerns (memory leaks, missing disposal)
+- Security vulnerabilities or data exposure
+
+**Versioning & Changelog:**
+
+- Delegate to `reviewer-versioning` subagent to validate version bumps
+- Delegate to `reviewer-changelog` subagent to validate changelog entries
+
+**Dependencies:**
+
+- Delegate to `reviewer-dependencies` subagent to validate dependency consistency
+
+**Documentation:**
+
+- Missing or outdated documentation
+- README updates for new features
+
+## Subagent Output Rules
+
+**IMPORTANT:** Only include subagent results in the final output if they found errors or issues.
+
+- If `reviewer-typescript` passes → Do NOT mention it in the output
+- If `reviewer-eslint` passes → Do NOT mention it in the output
+- If `reviewer-prettier` passes → Do NOT mention it in the output
+- If `reviewer-tests` passes → Do NOT mention it in the output
+- If `reviewer-versioning` passes → Do NOT mention it in the output
+- If `reviewer-changelog` passes → Do NOT mention it in the output
+- If `reviewer-dependencies` passes → Do NOT mention it in the output
+
+Only report subagent findings when they detect actual problems.
+
+## Output Format
+
+**1. Summary:** Brief overview of changes (2-3 sentences max)
+
+**2. Issues by Priority:**
+
+- 💀 **Critical:** Must fix before merge
+- 🔥 **High:** Should fix before merge
+- 🤔 **Medium:** Consider addressing
+- 💚 **Low:** Nice to have
+
+For each issue, be specific: file, line, problem, suggested fix.
+
+**3. Test Coverage:** Assess coverage quality. Warn if functions lack tests.
+
+**4. Breaking Changes:** List any breaking changes and suggest migration guide if needed.
+
+**5. Changelog:** Generate a short, consistent changelog as a copyable markdown code block.
+
+Format:
+
+- Use present tense, imperative mood (e.g., "Add", "Fix", "Update", "Remove")
+- One line per logical change (max 5-7 lines)
+- Group by type if multiple changes: Features, Fixes, Refactors
+- No verbose descriptions - keep each line under 80 characters
+
+Example:
+
+```
+- Add JSON schema validation support
+- Fix theme toggle not persisting preference
+- Update Monaco editor to latest version
+```
+
+**6. Pull Request Description:** Generate as a copyable markdown code block with:
+
+- Relevant emoji per header
+- Brief description of what the PR does
+- **Remaining Tasks** checklist generated from found issues (if any), grouped by priority:
+
+```markdown
+## 📋 Remaining Tasks
+
+### 💀 Critical
+
+- [ ] Fix TypeScript error in `frontend/src/components/editor.tsx:42`
+
+### 🔥 High
+
+- [ ] Add missing test for `formatJson` function
+
+### 🤔 Medium
+
+- [ ] Address memory leak in observable subscription
+```
+
+Omit empty priority sections. If no issues found, omit the entire Remaining Tasks section.
+
+**Style:** Be critical, specific, and concise. If unsure, ask for clarification.
diff --git a/.yarn/versions/d87e5b12.yml b/.yarn/versions/d87e5b12.yml
new file mode 100644
index 0000000..e27b4cb
--- /dev/null
+++ b/.yarn/versions/d87e5b12.yml
@@ -0,0 +1,2 @@
+releases:
+  furystack-boilerplate-app: patch