← ClaudeAtlas

lilia-app-codinglisted

Coding workflow for the LiliaCode native desktop app. Use when implementing features, fixing bugs, refactoring, adding UI surfaces or runtime commands, changing cross-end data contracts, touching apps/desktop Rust code, NanaUI consumers, or crates/lilia-contracts.
sena-nana/LiliaCode · ★ 7 · AI & Automation · score 71
Install: claude install-skill sena-nana/LiliaCode
# Lilia App Coding ## Start With Context - Read the relevant module, data contract, and tests before editing. `apps/desktop` is the only desktop implementation: Rust native NanaUI/WGPU, no web host, no Tauri, no JavaScript toolchain. - Use CodeGraph first only when the index reflects the current native workspace; the index can lag behind architecture migrations, and stale hits from removed code are worse than a text search. Verify the symbol exists before building on it. - Run `cargo xtask verify` as the default gate; see `$lilia-app-validation` for choosing checks by risk. - For complex tasks, split work into clear sub-tasks and use subagents only where the boundary is clean enough for independent investigation or validation. ## Ownership - `apps/desktop` owns the launcher, `LiliaShell`, feature composition, application services, platform implementations, and app state (`src/application/`, `src/runtime_shell.rs`, `src/ui_module.rs`, `src/module/`). - `crates/lilia-contracts/contracts` is authoritative for cross-boundary data. Update the contract and its Rust API first, then sync consumers. - Generic native controls, window primitives, layout primitives, and theming belong in NanaUI (sibling checkout; GIT-pinned in `apps/desktop/Cargo.toml`). Propose reusable layout/visual primitives there instead of re-creating them app-side. - Do not copy shell behavior, titlebar, sidebar, settings, menus, theme, global styling, or window-state code between app and framework; see `$lili