engram-contract
Maintain Engram contract and domain-model integrity. Use when editing docs/domain-data-model.md, contracts/schemas/*.json, ADRs/RFCs that affect public data shapes, Rust/TypeScript type generation, co
SKILL.md.claude/skills/engram-contract/SKILL.md
GitHubEngram Contract
Use this skill whenever work could change the portable domain contract. The goal is to keep Engram contract-first: storage, APIs, Rust types, TypeScript bindings, and generated schemas must derive from the accepted domain model instead of drifting into separate interpretations.
Required Context
Read these files before changing contract-affecting behavior:
docs/domain-data-model.mdcontracts/v1/**/*.mdcontracts/v1/**/*.jsondocs/specs/*.mddocs/architecture.mddocs/adr/*.mdwhen the change touches architecture policydocs/rfcs/*.mdwhen the change touches scope or extension pointsreferences/contract-checklist.md
Workflow
- Identify whether the change is pre-acceptance, compatible post-acceptance, or breaking.
- Keep domain language storage-neutral. Do not add SQL, vector-store, Node.js, or Rust-specific concepts to the portable contract.
- Preserve opaque identifiers. Do not encode tenant, storage location, timestamps, or authorization semantics in IDs.
- Check that every durable record has scope, provenance, timestamps, and policy implications where applicable.
- Update JSON schemas only when they intentionally track the domain model.
- Keep accepted v1 examples valid against accepted v1 schemas.
- Document deferred compatibility questions in
docs/domain-data-model.mdrather than hiding them in code comments. - Run
.codex/hooks/check-contracts.shbefore handoff.
Output
When reporting contract work, include:
- The contract surface changed.
- Whether the change is compatible or breaking.
- Any schema or generated-type follow-up required.
- Validation commands run and their result.