contracts
Contract lifecycle management - creation, consumption, modification, and resolution.
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.
| name | contracts |
|---|---|
| description | Contract lifecycle management - creation, consumption, modification, and resolution. |
| allowed-tools | Read, 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:
- Read contracts before coding
- Implement exactly what contract specifies
- 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:
Read the block - What change is needed?
Assess impact - Who else uses this contract?
Decide action:
modify: Update contract, mark breaking if neededextend: Add to contract without breakingreject: Suggest alternative approach
Update contract file - Increment version, add to history
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
- Contracts before code - Materialize all contracts before spawning implementers
- Single provider - Each contract has exactly one provider task
- Explicit consumers - All consumers must be listed
- Version everything - Never modify without incrementing version
- History is immutable - Never edit past history entries