Skip to main content

contract

Turn capsule invariants and boundary crossings into executable contracts. Use after creating a concept capsule, or when invariants need to be enforced in code. Covers preconditions, postconditions, constructor validation, domain types, and contract tests.

설치로 이동

소스 정보

저장소
hashintel/labs
최근 소스 활동
2026년 3월 23일 12:12
감지된 SKILL.md 언어
영어
스타
36
포크
14

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
contract
description
Turn capsule invariants and boundary crossings into executable contracts. Use after creating a concept capsule, or when invariants need to be enforced in code. Covers preconditions, postconditions, constructor validation, domain types, and contract tests.
argument-hint
[invariants to enforce, or 'audit' to check current coverage]
# Contract Extraction Turn capsule invariants into **executable contracts**: domain types that prevent invalid states, validation at boundaries, and tests that prove enforcement. Operationalizes "design by contract" (Meyer) and "parse, don't validate." ## Input Invariants to enforce (or `audit` to check current coverage): $ARGUMENTS **Preconditions**: - A concept capsule must exist (it defines the invariants). If none → `/pragma:capsule` first. - At least one slice of working code to attach contracts to. If at skeleton stage → `/pragma:card` + `/pragma:slice` first. Also read: the capsule (glossary + invariants), recent cards (boundary crossings), and existing source code. ## Procedure ### 1. Build the contract map For each capsule invariant, determine current enforcement status: | Invariant | Enforcement | Location | Evidence | |-----------|-------------|----------|----------| | [from capsule] | Type system / Constructor / Test / None | [file:line or "missing"] | [test name or "none"] | Enforcement levels (best → worst): **Type system** (invalid states unrepresentable) → **Constructor/validator** (checked at entry points) → **Test** (at least a check somewhere) → **None** (fix this). ### 2. Identify boundary contracts For each public entry point in scope: ``` Module: [name] Function: [name] Preconditions: [what must be true on entry] Postconditions: [what must be true on exit] Errors: [what can go wrong and how it's signaled] ``` Use glossary terms. No clear pre/postconditions → design smell, module may need splitting. ### 3. Enforce incrementally One invariant at a time. Prioritize "None" first, then upgrade "Test" → "Constructor" → "Type system": 1. **Types first**: narrower types to make invalid states impossible (branded IDs, discriminated unions, non-empty collections) 2. **Then constructors/validators**: validation where data enters the domain (factory functions, constructor guards) 3. **Then tests**: contract tests asserting invariants hold (table tests, property tests, regression tests) Keep tests green throughout. Do not change behavior — only tighten enforcement. ### 4. Update the contract map Write or update `docs/contracts.md` with: - The invariant-to-enforcement table (updated) - Boundary contracts for each module - A **contract budget**: what's enforced now vs. what remains "English-only" and why ### 5. Verify and commit Run full verification harness. All checks must pass. Contract extraction must not change behavior. Commit: `Contract: enforce [invariant] at [boundary]` ## Constraints - **No behavior changes.** Contracts tighten enforcement only. Missing behavior → `/pragma:card`. - **Incremental.** One invariant or boundary per pass. Do not "contract the whole system" at once. - **Types over runtime checks.** Compile-time enforcement preferred. Runtime is fallback. - **The capsule is the authority.** Capsule wrong → update it first. - **No heavy frameworks.** Native type system + standard assertion patterns only. ## Output 1. **Contracts enforced**: which invariants, at what level 2. **Contract budget**: what remains unenforced and why 3. **Boundary contracts**: pre/postconditions added or clarified 4. **Code changes**: types, validators, tests added 5. **Recommended next step**: more `/pragma:contract` passes, or back to `/pragma:card` + `/pragma:slice` 6. **Lifecycle**: `State: governance`, `Next: /pragma:consult` (or the explicitly recommended next step), `Loop: /pragma:consult` (default unless user explicitly continues directly)
GitHub에서 보기