doeixd
- 8 skills
- 0 followers
- 9 hours ago last updated
- ▌ Flue Eve · doeixd bundleMigrate an Eve project to flue-eve — scan existing code, scaffold the Flue runtime, wire the Eve compat server, connect the frontend. Triggers on any mention of "migrate from Eve", "switch to flue-eve", "run Eve on Flue", "flue-eve migration", "project conversion", or when users ask how to port an existing Eve agent, client, or frontend to flue-eve. Also triggers when users ask about setting up flue-eve in a new project from scratch.
- ▌ Blog Writing · doeixd bundleDraft, 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.
- ▌ Setup Opencode Ralph Rlm · doeixd bundleSet 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.
- ▌ Interview And Create Plan · doeixdBefore 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.
- ▌ Solid Start V2 · doeixd bundleGuidance 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.
- ▌ Solid JS 2x Migration · doeixd bundleGuidance 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.
- ▌ Solid JS 1x Best Practices And API · doeixd bundleGuidance 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.
- ▌ Solid JS 2x API Changes And Best Practices · doeixd bundleGuidance 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.