shiki: Instructions file for Claude Code

CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

Project

shiki (私記) is a TUI note-taking app written in Rust, inspired by Yazi's three-pane layout and modal navigation. Notes are plain Markdown files with YAML frontmatter, organized into "notebooks" (directories, each its own git repo). Full design spec, motivation, keybindings, config format, and included themes are documented in IDEA.md — read it before making architectural changes, since it's the source of truth for intended behavior (layout, CLI commands, config schema, etc).

Commands

cargo build --workspace              # build everything
cargo check --workspace              # fast type-check (use this while iterating)
cargo clippy --workspace --all-targets -- -D warnings   # lint; CI enforces -D warnings, so match it locally
cargo fmt --all                      # format (run after editing, before checking clippy)
cargo run -p shiki-cli -- <args>     # run the binary, e.g. `-- new "titulo"`, `-- daily`, no args launches the TUI
cargo test -p shiki-tui panel_drawer::tests   # single module, e.g. while iterating on one file
cargo test -p shiki-tui clicking_the_button_row   # single test by (substring of) name
cargo audit                          # CI runs this too; ignore list is .cargo/audit.toml

There are 504 #[test]s: 242 in shiki-core, 27 in shiki-config, 196 in shiki-tui, 33 in shiki-cli, plus 1 in shiki-native-host and 5 in shiki-desktop (shiki-mcp has none yet — its tool bodies are thin wrappers over already-tested shiki-core logic, verified instead by a manual stdio protocol smoke test) — cargo test --workspace is green. They're all inline #[cfg(test)] modules inside the source files (no tests/ dirs, no #[ignore], no fixture setup), so the pattern set by panel_drawer::tests (shiki-tui/src/panel_drawer.rs) — covering drawer_hit_at's mouse coordinate math as a plain function of numbers, not &App — is the norm. When adding tests, put them as #[cfg(test)] modules in the relevant file; shiki-core/shiki-config have no TUI/terminal dependency, so they're the easiest to unit test. For shiki-tui, prefer designing the function to not need &App in the first place (as drawer_hit_at does) over constructing a full App in a test.