just-vibeArchitecture · plan by default
/arch-contracts
Define interfaces and contracts between components or services
Use for contracts across services or modules; api-openapi maintains a concrete HTTP schema, api-breaking assesses a concrete change's consumer impact, and data-contract owns dataset/field semantics and freshness.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select arch-contracts from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv arch-contracts, /just-vibe arch-contracts and /jv:arch-contracts in Claude. See shortcut setup and context examples.
/just-vibe:arch-contracts Define a versioned order-created contract that existing consumers can still read./just-vibe:arch-contracts Evolve an event field while an offline consumer remains on an old version./just-vibe:arch-contracts Review a contract without a complete consumer inventory; avoid universal compatibility claims.What the agent does
- Inventory actual writers and readers, including independently deployed consumers, and compare their current payloads and assumptions.
- Define required, optional and nullable fields, version negotiation and error behavior.
- Design compatibility tests and deprecation steps for each consumer.
Inputs
- producer/consumer boundaries, versions, and compatibility requirements.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Interface schemas, invariants, errors, ownership, and evolution; no endpoint implementation by default.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.
- Mode
- Plan; producer/consumer boundaries, versions, and compatibility requirements.
- Prerequisites
- Readable source, infrastructure/configuration definitions, and any supplied system documentation. Runtime telemetry is optional evidence, never assumed available. Architecture proposals remain plans until implementation is requested.
Expected output
- Versioned contract proposal with examples, a consumer compatibility matrix, consumer obligations and deprecation gates.
How the work is checked
- Old consumers handle an additive field; a removed required field is identified as breaking.
When to stop or clarify
- Do not infer all consumers from one repository. Unknown consumers require a compatibility-preserving assumption or explicit decision.
Handling missing context
- Infer
- Trace current entry points, data owners, deployment units and documented constraints before proposing boundaries.
- Assume
- Prefer extending an existing owner while scale or organizational evidence is absent; mark capacity estimates as assumptions.
- Ask
- Ask for an unresolved consistency, compatibility or ownership requirement only if it changes the design; missing telemetry limits capacity claims, not source mapping.
Technical guidance
- Evidence
- Read producer serializers, consumer decoders, timeout settings and ownership of fields and errors.
- Method
- Specify absence versus null, units, enum evolution, version negotiation and retry semantics using concrete exchanges.
- Pitfall
- Adding an enum or tightening validation may break existing consumers despite being schema-additive.
- Check
- Exercise an old consumer against a proposed new producer and the reverse where rolling deployment requires it.
Situational decisions
When old consumers reject unknown fields: Treat even additive changes as potentially breaking and design a compatibility bridge.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.