mixjam-electron

Structured design critique across usability, hierarchy, consistency, and accessibility. Use when the user shares a Figma link, screenshot, mockup, or asks for design feedback ("review this design", "critique this screen", "what do you think of this UI?"). Use after design-router when a theme has been selected and applied.

Runs a disciplined ablation workflow for MixJam Electron (MJE) bugs to prove which changed files or layers are actually required for a fix. Use when an MJE import, playback, or UI bug has a known pass/fail check but several edits may be involved, or when the user asks which change actually fixed it, what can be removed, or for the smallest proven fix.

Creates or updates repository specs, acceptance criteria, durable decisions, and documentation for new work. Use when adding a feature or defining an ambiguous slice, when making architectural decisions or changing contracts (API, persistence, import, playback), or when recording durable context (glossary, conventions, trade-offs) for future engineers and agents.

Audits the MixJam Electron (MJE) codebase for dead TypeScript code, orphan files, and unused symbols across main and renderer processes, triages findings into live dead code or false positives, and optionally removes provably dead code with focused validation. Use for a dead-code audit, or for cleanup explicitly requested from analyzer findings.

Routes a requested UI visual direction to one bundled design theme. Use when building or restyling an interface that needs an explicit aesthetic.

Remove AI slop from every file in the repository while preserving behavior and genuine information.

Diagnoses hard bugs and performance regressions with a controlled feedback loop, and implements the fix only when requested. Use when the failure is flaky, not yet reproducible, still lacks a root cause, or needs measurement.

Reviews a change set against an unusually strict maintainability bar, emphasizing code-judo simplification, abstraction quality, the 1k-line rule, and spaghetti growth.

Stress-tests a plan or design through a decision-tree interview. Use when the user asks to be grilled before building.

Runs the repository quality gate in verification or repair mode. Use to assess release readiness, clear diagnostics, fix lint or test failures, or enforce the unit-coverage policy.

Teach a skill or concept over multiple sessions using the workspace as a durable learning record.

Verifies nontrivial MixJam renderer changes against the built Chromium surface using pixels, computed styles, and canvas sampling.

Surface architectural friction across the entire project and propose deepening opportunities — refactors that turn shallow modules into deep ones.

Surgical, behavior-preserving cleanup for the MixJam Electron (MJE) repository. Use when the user asks to refactor — reduce complexity or make code easier to change without adding features.

Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.