# Design by Contract A methodology where software components define precise, verifiable interface specifications. Each component declares its preconditions (what it requires), postconditions (what it guarantees), and invariants (what stays true). Introduced by Bertrand Meyer with the Eiffel language. ## The three parts - **Preconditions**: what the caller must provide. If violated, the fault is the caller's - **Postconditions**: what the component guarantees on return. If violated, the fault is the component's - **Invariants**: properties that remain true before and after every operation ## Why it matters Contracts make interfaces explicit. Debugging becomes straightforward: check preconditions, then postconditions. Blame is unambiguous. Components can be swapped if they satisfy the same contract ([[SOLID Principles]], Liskov Substitution). ## In AI skills AI skills lack formal type systems, but contract thinking still applies: - **Preconditions**: "This skill requires a note path as argument and the osk-obsidian-cli context loader" - **Postconditions**: "This skill outputs a markdown document with H1 title matching the filename" - **Invariants**: "This skill never modifies files outside the target folder" Making these explicit (in a dedicated Input/Output section of SKILL.md) enables substitution, composition, and trust between skills that chain into each other. Today, most skill "contracts" are implicit. Formalizing them is the next step for skill ecosystems. ## References - Bertrand Meyer, "Object-Oriented Software Construction" (1988) ## Related - [[SOLID Principles]] - [[Loose Coupling]] - [[AI Skill Best Practices]] - [[AI Skill Testing]] - [[Software Design Patterns for AI Skills and Agents]]