Pr1m4lc0d3

kiss-blast-radius

Use before editing, refactoring, moving, or deleting existing code — to keep the change contained to its bounded unit and prevent collateral damage to surrounding services and functions. Use whenever a change touches a file other code depends on, or whenever a refactor could ripple beyond the thing you were asked to change.

kiss-coherence

Use when auditing or changing a system where the same concept is derived in more than one place - enforces one canonical accessor per concept ("one question, one answer"), catching cross-cutting duplication that file-size and modularity audits structurally cannot see.

kiss-debt-guard

Use when a repo needs an enforceable size/debt control rather than advice — installs a light, dependency-free size-budget audit script plus a config, and points to heavier guards (dead-code, duplicate-surface, test-debt, dependency-risk, doc-drift) when a repo warrants them. Use during KISS kickoff, or when files keep drifting over budget despite good intentions.

kiss-map

Use before editing or creating code, to find where something is, whether it exists at all, or whether a twin/duplicate already exists — cheaply and without guessing. Use instead of grepping or reading the whole codebase, and whenever you are tempted to assume a function's existence or location.

kiss-plan

Use before writing code for any multi-step task, feature, or new project — orient inside the existing structure first, then turn the request into a short design doc with explicit modules, interfaces, and a verify-stepped build sequence. Use when a task is ambiguous, spans more than one file, or has more than one reasonable interpretation.

kiss-readable

Use when writing or laying out code so a human and an AI can read it, navigate it, and lift pieces out of it cleanly. Covers bounded labeled sections, intent-summaries on non-trivial functions, why-comments on complex logic, and intention-revealing naming. Use whenever code is non-obvious or a file holds more than one section of related logic.

kiss

Use at the base of a project — when starting a new project, a sizable feature, or a fresh module, before much code exists — to set it up to stay clean, and as the entry point to the KISS discipline (plan, map, readable sections, modularity, blast-radius, debt). Use whenever you want clean-code structure established from the start rather than bolted on later.

kiss-changelog

Use after a change lands — a feature, a fix, or any behavior change — to record what changed and why, so humans and future-you can follow the project's evolution without reading the diff. Use before declaring a unit of work done, not in a batch at the end.