the-exodus
- 4 skills
- 0 followers
- 8 hours ago last updated
- ▌ Adr · the-exodus bundleHouse 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.
- ▌ Lexicon · the-exodusHouse 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.
- ▌ Design Interview · the-exodus bundleDrives 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.
- ▌ Design Philosophy · the-exodusLoad first, before the first Edit or Write, whenever a request will have you write or change code that adds or changes behaviour — a feature, a bug fix, error handling, a new option, a refactor — however small it looks. Where the new logic lives and what its callers see are structural decisions, and these principles govern them here. Also load 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.