developing-reeflisted

REQUIRED before any non-test code change in Reef. Load this skill before modifying Reef runtime architecture, `App` state, tabs/panels, rendering code, input dispatch (`src/input.rs`, any picker overlay, the commit textarea, any new text-input field), background work, git/file-tree/diff/graph loading, performance-sensitive paths, or when the user asks about "how Reef is structured", "render blocking", "heavy tasks", "new tab", "new feature architecture", "input handling", "text input", "picker", "PickerCore", "input_edit", or "project conventions". Do NOT start editing Reef source without loading this skill first — the architecture has non-obvious invariants (render-pure, async generation tokens, three-layer text-input stack) whose violation has been re-introduced and re-fixed across multiple PRs. Pair with `testing-reef` whenever adding or changing tests.
Blushyes/reef · ★ 67 · Code & Development · score 72

Install: claude install-skill Blushyes/reef

# Developing Reef Use this skill as the project onboarding guide for non-test Reef changes. Reef is a minimal single-process Rust TUI: UI must stay responsive, and expensive host work must not run from render. ## Core Architecture Rules - Keep `ui::*::render` on cached state only. Do not call git, filesystem walks, diff generation, syntax highlighting, or long formatting from render. - Treat input handlers as intent dispatchers. They may update cheap UI state (selection, scroll, hover, active tab) and request work, but must not do blocking host work. - Route expensive work through the background task coordinator in `src/tasks.rs`; merge results only from `App::tick`. - Prefer stale cached UI over blocking. Show old data plus loading/stale/error status instead of waiting during tab switches or hover/mouse movement. - Use generation tokens for async results. Late results from older requests must not overwrite newer selections or newer snapshots. - Keep each tab/panel independently refreshable. Adding a feature should not require another tab to render before data can update. ## Runtime Data Flow 1. User input mutates cheap UI state or calls an `App` request method such as `refresh_status`, `load_diff`, or `load_preview`. 2. The request method marks an `AsyncState`, increments its generation, and sends a worker request through `TaskCoordinator`. 3. Workers do git/filesystem/diff/highlight work off the render path and send `WorkerResult`. 4. `App::tick` drains results, accept