kiss-practiceslisted

# KISS Practices ## General Rules (always apply) - Don't add features nobody asked for - Don't add error handling for scenarios that can't happen — trust internal code and framework guarantees - Don't create abstractions for one-time operations — three similar lines is better than a premature helper - Don't design for hypothetical future requirements — solve today's problem - Don't add backwards-compatibility shims — just change the code - Don't wrap framework calls in service layers unless there's real business logic to encapsulate - Simple, readable code beats clever, compact code - Validate at system boundaries (user input, external APIs), not at every internal function ## How to Use **During Phase 0 (Discovery):** 1. Detect which languages/frameworks are present in the project (by file extensions, config files, or dependencies) 2. Read only the relevant language files (e.g., `${CLAUDE_SKILL_DIR}/elixir.md`, `${CLAUDE_SKILL_DIR}/javascript.md`) 3. Include the language-specific KISS rules in the discovery context passed to the Planner **Language detection heuristics:** | Files present | Load | |---|---| | `*.ex`, `*.exs`, `mix.exs` | `${CLAUDE_SKILL_DIR}/elixir.md` | | `*.js`, `*.ts`, `*.jsx`, `*.tsx`, `*.css`, `*.html` | `${CLAUDE_SKILL_DIR}/javascript.md` | | `*.svelte`, `svelte.config.*` | `${CLAUDE_SKILL_DIR}/svelte.md` | | `*.py`, `pyproject.toml`, `requirements.txt` | `${CLAUDE_SKILL_DIR}/python.md` | | `*.sh`, `*.bash`, `Makefile` | `${CLAUDE_SKILL_DIR}/bash.md