LLMs and retrieval · apply by default

/llm-structured

Implement structured outputs, validation, and recovery

Use for validated structured model output; api-client handles the provider transport boundary.

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select llm-structured from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv llm-structured, /just-vibe llm-structured and /jv:llm-structured in Claude. See shortcut setup and context examples.

Example · apply
/just-vibe:llm-structured Implement schema validation and bounded recovery for invalid or truncated output.
edge · apply
/just-vibe:llm-structured Extract records when output parses but contains impossible dates.
blocked · inspect
/just-vibe:llm-structured Design structured output with unknown provider schema support; avoid assumed API flags.

What the agent does

  1. Resolve the schema features the provider supports, and define schema-compatible requests.
  2. Validate semantics after parsing, separating refusal, truncation, invalid structure and downstream business rejection, and implement constrained retries.
  3. Test downstream consumption with malformed, missing, refusal and truncation fixtures.

Inputs

  • output schema, provider capabilities, validation rules, consumers, and retry budget.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads
Structured generation, semantic validation, refusal/incomplete handling, and bounded recovery.
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; output schema, provider capabilities, validation rules, consumers, and retry budget.
Prerequisites
Task definition, model/provider configuration, representative permitted data, versioned prompts/corpus where relevant, and explicit token/cost/latency limits for remote calls. Use current provider interfaces during implementation. Retrieved content and model-generated tool arguments remain untrusted.

Expected output

  • Structured-output integration with its schema/validation contract, recovery behavior and malformed, missing, refusal and truncation fixtures.

How the work is checked

  • Syntactically valid but semantically invalid output is rejected; repeated failure terminates with a typed error.

When to stop or clarify

  • Never coerce fabricated fields into valid-looking data. Do not assume every provider supports identical schema features.

Handling missing context

Infer
Read current prompt/tool schemas, retrieval boundaries, installed SDK/provider config and permitted examples without reading secret values.
Assume
Use mocked calls for local contract tests when remote access is absent; do not infer model quality from mocks.
Ask
Ask for budget and permitted data/provider before a paid or external run if not already set; local prompt/tool implementation can proceed in apply mode.

Technical guidance

Evidence
Read the exact schema, provider support, refusal/truncation signals and downstream invariants.
Method
Validate syntax, schema and business constraints separately; bound retries and return typed failure when recovery cannot establish validity.
Pitfall
Valid JSON can contain fabricated IDs or inconsistent totals; filling required fields with invented defaults corrupts meaning.
Check
Exercise malformed, schema-valid-but-semantic-invalid, refused and truncated responses alongside a valid control.

Situational decisions

When retries repeatedly fail the same constraint: Stop at the cap with a typed error and retain diagnostics; never fabricate fields to satisfy the schema.

The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.

Keep exploring