design

House rules and format for Architecture Decision Records. Load before writing, reviewing, superseding, or indexing an ADR in any repo, and when asked to record a decision, write something up as an ADR, add to or reindex a directory of ADRs, or change an ADR's Status. Also load when a decision already recorded in an ADR has changed, since ADRs are superseded rather than edited. NOT for architecture pages on the wiki, RFCs, or design docs that record no decision.

Drives a thorough design interview that takes a software engineer from a rough pitch to a complete, gap-free design before code is written. Use this skill whenever the user wants to design new functionality, plan a change to existing code, extend a codebase, or work out the shape of a feature before implementing it. Trigger on phrases like "design X", "help me design", "plan a change to", "before I write code", "let's think through", "I'm planning to add", "I want to build", "how should I structure", and on substantive change descriptions even without an explicit design ask, since pre-implementation is when this skill is most valuable. Produces a complete design tree — every branch closed in a terminal state with its rationale — laid out in context when the interview ends, and on request captures it as functional spec, contracts, edge cases, acceptance criteria, and ADRs.

Load before any design or implementation work: before writing or changing code that adds, extends or restructures behaviour; before designing or planning a change; and at the start of a design interview, before any branch is seeded. Carries the structural principles that govern how software here is built — complexity as the thing to minimize, deep modules behind small interfaces, information hiding, no pass-through layers, pushing complexity down, considering alternatives before committing, long-term simplicity over short-term speed. Trigger on implement, add, build, extend, refactor, restructure, design, plan. NOT for mechanical edits whose decisions are already made (a typo, a rename, formatting), and NOT for code-level style: formatting, naming conventions, comment mechanics.

House rules for a project's lexicon — the domain's ubiquitous language — and the procedure for pruning, consolidating and correcting one that has sprawled. Load before admitting, amending or retiring a lexicon or glossary entry in any repo; when asked to review, audit, prune, consolidate, clean up or correct a lexicon or glossary; and when a lexicon has grown past about thirty entries or its entries describe code rather than meaning. design-interview loads it for the admission tests. NOT for API reference documentation, code doc comments, or user manuals.