just-vibeBackend · apply by default
/backend-service
Implement a service with clear boundaries and validation
Use for a domain service implementation; api-design defines transport-facing contracts.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select backend-service from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv backend-service, /just-vibe backend-service and /jv:backend-service in Claude. See shortcut setup and context examples.
/just-vibe:backend-service Implement a narrow invitation service using existing validation and persistence patterns./just-vibe:backend-service Implement order creation when notification fails after persistence./just-vibe:backend-service Inspect service requirements with an unavailable dependency; use a contract fixture only.What the agent does
- Identify transaction ownership and domain invariants, reusing the project's domain conventions.
- Implement the service with input validation and persistence, keeping transport parsing outside business decisions and making dependency failures observable to callers.
- Test observable success and failure behavior.
Inputs
- service responsibility, request/event contracts, persistence, and error requirements.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- One service boundary and necessary integration; no unrelated service decomposition.
- Writes
- Apply: only the requested local changes and relevant isolated verification. Inspect/plan requests remain inspection/planning. External actions require their exact action and target in session authorization.
- Mode
- Apply; service responsibility, request/event contracts, persistence, and error requirements.
- Prerequisites
- Service source, data/interface contracts, framework/runtime versions, and test environment. Default apply operations target local code and isolated tests; live infrastructure/data mutations require their own requested scope.
Expected output
- Service implementation with its contract, effect/transaction boundaries, configuration guidance and success/failure checks.
How the work is checked
- A valid operation persists the intended effect; validation/dependency failure leaves a consistent state.
When to stop or clarify
- Do not invent business rules or create production infrastructure. Missing external credentials block live verification, not local contract work.
Handling missing context
- Infer
- Trace service callers, request contracts, authorization, transactions, retries and existing test infrastructure.
- Assume
- Use the existing persistence and framework; isolate local tests from live services.
- Ask
- Resolve ambiguous durability, duplication or consistency requirements before encoding them; absent production access does not prevent local implementation.
Technical guidance
- Evidence
- Trace transport parsing, validation, domain invariants, transaction ownership and downstream effects.
- Method
- Keep business validation at the owning boundary; represent expected failures separately from infrastructure uncertainty.
- Pitfall
- Broad catch-and-success fallbacks can report an order created when its durable write failed.
- Check
- Exercise valid input, invalid input, authorization failure and a dependency failure after partial progress; verify persisted state as well as response.
Situational decisions
When one operation spans local persistence and an external effect: Define outbox/reconciliation or compensating behavior before claiming atomicity.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.