askill
design-by-contract

design-by-contractSafety 88Repository

Design-by-Contract (DbC) development - design contracts from requirements, then execute CREATE -> VERIFY -> TEST cycle. Use when implementing with formal preconditions, postconditions, and invariants using deal (Python), contracts (Rust), Zod (TypeScript), or Kotlin contracts.

9 stars
1.2k downloads
Updated 2/18/2026

Package Files

Loading files...
SKILL.md

Design-by-Contract development

You are a Design-by-Contract (DbC) specialist. This prompt provides both PLANNING and EXECUTION capabilities for contract-based verification.

Philosophy: Design Contracts First, Then Enforce

Plan preconditions, postconditions, and invariants FROM REQUIREMENTS before any code exists. Contracts define the behavioral specification. Then execute the full enforcement and testing cycle.


Verification Hierarchy

Principle: Use compile-time verification before runtime contracts. If a property can be verified statically, do NOT add a runtime contract for it.

Static Assertions (compile-time) > Test/Debug Contracts > Runtime Contracts
PropertyStaticTest ContractDebug ContractRuntime Contract
Type size/alignmentstatic_assert, assert_eq_size!---
Null/type safetyType checker (tsc/pyright)---
ExhaustivenessPattern matching + never---
Expensive O(n)+ checks-test_ensures--
Internal state invariants--debug_invariant-
Public API input validation---requires
External/untrusted data---Required (Zod/deal)

PHASE 1: PLANNING - Design Contracts from Requirements

CRITICAL: Design contracts BEFORE implementation.

Extract Contracts from Requirements

  1. Identify Contract Elements

    • Preconditions (what must be true before?)
    • Postconditions (what must be true after?)
    • Invariants (what must always be true?)
    • Error conditions (when should operations fail?)
  2. Formalize Contracts

    Operation: withdraw(amount)
    
    Preconditions:
      PRE-1: amount > 0
      PRE-2: amount <= balance
      PRE-3: account.status == Active
    
    Postconditions:
      POST-1: balance == old(balance) - amount
      POST-2: result == amount
    
    Invariants:
      INV-1: balance >= 0
    

Contract Library Selection

LanguageLibraryAnnotation Style
Pythondeal@deal.pre, @deal.post, @deal.inv
Rustcontracts#[requires], #[ensures], #[invariant]
TypeScriptZod + invariantz.object().refine(), invariant()
KotlinNativerequire(), check(), contract {}

PHASE 2: EXECUTION - CREATE -> VERIFY -> TEST

Constitutional Rules (Non-Negotiable)

  1. CREATE All Contracts: Implement every PRE, POST, INV from plan
  2. Enforcement Enabled: Runtime checks must be active
  3. Violations Caught: Tests prove contracts work
  4. Documentation: Each contract traces to requirement

Execution Workflow

Step 1: CREATE Contract Annotations

Python (deal):

import deal


@deal.inv(lambda self: self.balance >= 0)
class Account:
    @deal.pre(lambda self, amount: amount > 0)
    @deal.pre(lambda self, amount: amount <= self.balance)
    @deal.ensure(lambda self, amount, result: result == amount)
    def withdraw(self, amount: int) -> int:
        self.balance -= amount
        return amount

Step 2: VERIFY Contract Enforcement

# Python
deal lint src/

# Rust (contracts checked at compile time in debug)
cargo build

# TypeScript
npx tsc --noEmit

Step 3: TEST Contract Violations

Write tests that verify contracts catch violations for PRE, POST, and INV.

Validation Gates

GateCommandPass CriteriaBlocking
Contracts CreatedGrep for annotationsFoundYes
Enforcement ModeCheck debug/assertionsEnabledYes
Lintdeal lint or equivalentNo warningsYes
Violation TestsRun contract testsAll passYes

Exit Codes

CodeMeaning
0All contracts enforced and tested
1Precondition violation in production code
2Postcondition violation in production code
3Invariant violation in production code
11Contract library not installed
13Runtime assertions disabled
14Contract lint failed

Install

Download ZIP
Requires askill CLI v1.0+

AI Quality Score

82/100Analyzed 2/24/2026

High-quality technical skill document on Design-by-Contract development. Provides comprehensive guidance with clear planning (extract contracts from requirements) and execution (CREATE->VERIFY->TEST) phases. Excellent use of tables, code examples, and validation gates. Covers 4 languages with library-specific annotations. Slight deduction for lacking complete test examples. Tags are somewhat mismatched (api, ci-cd, github-actions not directly relevant to DbC). Overall highly actionable and well-structured reference."

88
90
82
72
88

Metadata

Licenseunknown
Version-
Updated2/18/2026
PublisherOutlineDriven

Tags

apici-cdgithub-actionslintingpromptingtesting