doeixd

Guidance for writing, reviewing, and refactoring SolidJS 1.x code using idiomatic APIs and reactivity patterns. Use this whenever the user is working in SolidJS 1.x and asks for help with components, signals, props, memos, effects, stores, control flow, or why a Solid component is not updating correctly. Also use it for code reviews or refactors of Solid 1.x code, especially when React habits may be causing non-idiomatic Solid patterns.

Guidance for migrating an existing SolidJS 1.x codebase to SolidJS 2.x beta or next, including identifying old APIs, rewriting code to the new semantics, sequencing changes safely, and validating the migration with warnings and tests. Use this whenever the user asks to upgrade, port, convert, or migrate SolidJS code from 1.x to 2.x, especially when they mention renamed imports, removed APIs like Index or createResource, new effect behavior, Loading or Errored, store API changes, failing tests after upgrade, or ecosystem breakage during the move to Solid 2.x beta or next.

Guidance for writing, reviewing, and explaining SolidJS 2.x beta or next-era code, including new APIs, changed semantics, and idiomatic patterns. Use this whenever the user is targeting Solid 2.x beta or next, asks how a 2.x API works, wants new code written in the 2.x style, or needs help understanding warnings about top-level reactive reads, writes in owned scope, batching, Loading, Errored, new store APIs, or changed DOM and control-flow behavior. Use this even if the user does not explicitly say beta or next when the code clearly targets Solid 2.x APIs.

Guidance for building, reviewing, and refactoring high-quality SolidStart v2 applications using idiomatic route, data, mutation, server, and deployment patterns. Use this whenever the user is working in a SolidStart app or mentions `@solidjs/start`, `@solidjs/router`, route `preload`, `query`, `action`, `createAsync`, forms, sessions, middleware, API routes, metadata, or app setup in Start v2. Use it even when the user does not explicitly say "SolidStart" if they are clearly building a Solid full-stack app with route-based server data and mutations.

Set up Ralph RLM in an existing OpenCode project by installing the package, running the opencode-ralph-rlm setup command, checking generated .opencode config, and verifying the provider/worker loop wiring. Use when a user asks to install, configure, initialize, troubleshoot setup for, or add opencode-ralph-rlm / Ralph RLM to a repository.

Before starting a Ralph RLM loop, interview the user to sharpen the goal, stress-test the design, and write an authored PLAN.md (goal, definition of done, milestones, open questions, invariants) that the loop can follow. Use when a user wants to plan, scope, or stress-test work before delegating it to the supervisor / start_loop, or whenever PLAN.md is still the placeholder bootstrap.

Draft, rewrite, and edit blog posts, essays, commentary, and persuasive prose so they read like sharp human writing rather than generic AI copy. Use when Codex needs to develop a clear point of view, explain systems and incentives, improve rhythm and flow, remove AI tells, sharpen headlines, or run a ruthless editing pass for specificity, tone, and structure.