r3bl-open-core: Skill for Claude Code

Design Philosophy Skill

Apply these principles when writing or reviewing code.

When to Use

• Proactively when designing new APIs, modules, or data structures
• When refactoring existing code
• When reviewing code for maintainability

Core Principles

1. Minimize Cognitive Load

Code should be easy to understand without loading too much into working memory.

Guidelines:

• Good Separation of Concerns (SoC) means fewer "things" to keep in mind
• Each module/function should have a single, clear responsibility
• Limit the number of concepts a reader must hold simultaneously
• Clean Imports: Use use statements at the top of files rather than inline absolute paths (e.g. crate::Type) to reduce visual noise and cognitive clutter in function bodies.
• No Magic Numbers/Strings: Extract domain-specific numbers and strings (like ANSI mode integers or escape sequences) into named constants (e.g., in tui/src/core/ansi/constants/). Do not use magic numbers directly in business logic or pattern matches, as this requires readers to memorize their meaning.
• Single Source of Truth for Constants: Never duplicate raw literals across byte, string, and length constants. Follow the Constant Derivation Hierarchy:
  • Atomic Primitives (Single byte/char): u8 is the SSOT (u8 to char via ascii_byte_to_char to &str via ascii_byte_to_str).
  • Composed Sequences (Multi-byte strings): &str is the SSOT (&str via compile-time concatenation/macro to &[u8] via .as_bytes() to usize via .len()). See Constant Design Patterns in patterns.md.
• Technical Precision: Use standard, precise terminology (e.g., Parameter vs. Argument) to ensure the reader's mental model matches the implementation exactly. See the Terminology Precision guide.

2. Progressive Disclosure

Reveal complexity only when needed.

Guidelines: