contracts

Clouder0's avatarfrom Clouder0

Contract lifecycle management - creation, consumption, modification, and resolution.

⭐0stars🔀0forks📁View on GitHub🕐Updated Dec 2, 2025

When & Why to Use This Skill

The Contracts Skill is a comprehensive framework for managing the lifecycle of technical interfaces between parallel software development tasks. It enables AI agents and developers to define, materialize, and verify API, data, and event contracts, ensuring seamless integration and type safety across complex, concurrent workflows. By making dependencies explicit and version-controlled, it eliminates integration friction and 'integration hell' in multi-task projects.

Use Cases

  • Architectural Planning: Defining minimal yet complete interfaces (APIs, Data Structures, Events) during the design phase to guide parallel implementation.
  • Dependency Management: Explicitly mapping providers and consumers for every cross-task dependency to prevent implementation mismatches.
  • Automated Verification: Validating that implemented code strictly adheres to pre-defined contract specifications and reporting discrepancies.
  • Change Management: Handling breaking changes through a structured resolution process, including version incrementing and impact assessment across all consumers.
  • Parallel Development Orchestration: Enabling multiple agents or developers to work on interdependent modules simultaneously by providing a 'source of truth' for their interactions.
namecontracts
descriptionContract lifecycle management - creation, consumption, modification, and resolution.
allowed-toolsRead, Write, Glob

Contracts Skill

Contracts define interfaces between parallel tasks. They enable safe concurrent implementation by making dependencies explicit.

When to Load This Skill

  • Architect: When defining contracts in design
  • Executor: When materializing contracts before implementation
  • Implementer: When implementing or consuming contracts
  • Contract-Resolver: When modifying contracts

Contract Lifecycle

DESIGN → MATERIALIZE → IMPLEMENT → VERIFY → (RESOLVE if blocked)
   ↓          ↓            ↓          ↓            ↓
Architect  Executor   Implementer  Verifier  Contract-Resolver

Phase 1: Design (Architect)

Architect defines contracts in design output (compact JSON):

{"contracts":[{"name":"user-repository","description":"Interface for user data access","definition":"interface UserRepository { getById(id: string): Promise<User | null>; save(user: User): Promise<void>; }","used_by":["task-001","task-002","task-003"]}]}

Rules for Architects:

  • Define contracts for ANY cross-task dependency
  • Make contracts minimal but complete
  • Specify who provides vs consumes
  • Include in execution_plan.contracts_first

Phase 2: Materialize (Executor)

Before spawning implementers, executor writes contracts to files:

FOR each contract in final_design.contracts:
  Write to memory/contracts/{name}.json (compact JSON)

Location: memory/contracts/{contract-name}.json

Contract file structure:

{"name":"user-repository","version":1,"status":"active","created_at":"ISO-8601","source_design":"memory/reports/final_design.json","definition":{"type":"interface","language":"typescript","spec":"interface UserRepository { ... }"},"description":"Interface for user data access","consumers":[{"task_id":"task-001","role":"provider"},{"task_id":"task-002","role":"consumer"}],"history":[{"version":1,"date":"ISO-8601","change":"Initial contract from design"}]}

Phase 3: Implement (Implementer)

Implementer receives contract paths and must:

  1. Read contracts before coding
  2. Implement exactly what contract specifies
  3. Report implementation in output:
{"contracts_implemented":[{"name":"user-repository","location":"src/repositories/user.ts","role":"provider"}]}

If contract is insufficient:

  • Status: blocked
  • Reason: contract_change
  • Include suggested contract modification

Phase 4: Verify (Verifier)

Verifier checks:

  • Provider implements all contract methods
  • Consumer only uses contract-defined interfaces
  • Types match contract specification

Phase 5: Resolve (Contract-Resolver)

When implementer is blocked on contract:

  1. Read the block - What change is needed?

  2. Assess impact - Who else uses this contract?

  3. Decide action:

    • modify: Update contract, mark breaking if needed
    • extend: Add to contract without breaking
    • reject: Suggest alternative approach
  4. Update contract file - Increment version, add to history

  5. Instruct executor on affected tasks

Contract Types

Interface Contract

{"definition":{"type":"interface","language":"typescript","spec":"interface PaymentGateway { charge(amount: number, token: string): Promise<ChargeResult>; refund(chargeId: string): Promise<RefundResult>; }"}}

Data Structure Contract

{"definition":{"type":"data_structure","language":"typescript","spec":"type User = { id: string; email: string; createdAt: Date; }"}}

API Contract

{"definition":{"type":"api","spec":"POST /api/users | Request: { email: string, password: string } | Response: { id: string, token: string } | Errors: 400 (validation), 409 (exists)"}}

Event Contract

{"definition":{"type":"event","spec":"Event: user.created | Payload: { userId: string, email: string, timestamp: ISO8601 } | Emitted by: UserService | Consumed by: EmailService, AnalyticsService"}}

Contract Discovery

To find contracts for a task:

1. Read task description
2. Glob("memory/contracts/*.json")
3. Filter where task_id in consumers
4. Separate by role (provider vs consumer)

Breaking Changes

A change is breaking if:

  • Method signature changed
  • Required field added to input
  • Field removed from output
  • Type changed incompatibly

Breaking changes require:

  • Re-verification of all consumers
  • Potentially re-implementation

Principles

  1. Contracts before code - Materialize all contracts before spawning implementers
  2. Single provider - Each contract has exactly one provider task
  3. Explicit consumers - All consumers must be listed
  4. Version everything - Never modify without incrementing version
  5. History is immutable - Never edit past history entries