Imported from itzrnvr/Rcode-v3 (
AGENTS.md). Install upstream withnpx skills add itzrnvr/Rcode-v3. Copyright stays with the author.
- Performance, UI and UX, Reliability are the most important pillars of this project.
- Commit messages must be detailed and also include relevant context, reasoning behind changes reasons, decisions etc
- https://github.com/zai-org/ZCode frontend components and ui ux and design system are going to be mostly based on this, copy code for ui elements from zcode. Also refer to it for implementation patterns etc and anlayse and take inspiration from impementation of different features. Their session loading speeds sucks ass though and performance is bad, so be careful there. Our's is light on hardware and lightening fast.
- UI UX must also be fully responsive and supported on mobile and tablets with all functionality available. Full ui ux compatibility and tuned for those platforms as well along with desktop. Zcode also has this, they support mobile via web.
- Read DESIGN.md before writing or changing UI. It is the authority for colour semantics, typography, radius, spacing, sizing and motion, and violating it is a defect rather than a style preference. Where the code and DESIGN.md disagree, the code is the part that is wrong.
- DESIGN.md is Rcode's own design system, adapted from zai-org/ZCode (Apache-2.0) and rewritten to describe what Rcode actually ships: the One UI language plus the monochrome family. It states the RULES. The token VALUES live in src/index.css, which is the single source of truth - the stylesheet owns the palette and applyTheme owns the knobs, and every derived token is a formula over a primitive. Never duplicate a token value in a second place.
- Size components by their container, not by the window. The same component renders in a 1000px chat column and a 320px side panel, so its compact rules are container queries, not media queries.
- Develop and verify UI in the browser.
npm run dev:webruns Vite plus a headless backend, with no Electron window, and serves http://127.0.0.1:5173. Reserve the Electron window for window-chrome work: titlebar, traffic lights, tray. - Put every component in the gallery at http://127.0.0.1:5173/gallery.html (gallery.html), which renders components in isolation against mock data with no backend and no Electron bridge. Build, review and customise UI there without running the app, and extend it whenever a component or its states change.
- Components must render without the Electron bridge: anything reached through window.electron is optional at render time, so a component has to mount in a plain browser with mock props. A component that needs the app shell to render is a defect, not a reason to move the gallery toward the app.
- Maintain a flatter simpler dir and file structure, avoid too much deep nesting, keep it clean and easy to understand and navigate.
- Rely on external packages, sdks wherever applicable, avoid developing designing everything from scratch. If there is an open source library etc available then use it. No need to reinvent the wheel unless its actually beneficial.
