Validated structured output
Use this skill when the task needs a mechanically checkable response shape. Validation proves only the declared shape and bounded checks; it does not prove facts, extraction correctness, or behavior.
When to use
Should trigger
- “Return exactly one approved status from this list.”
- “Produce JSON with these fields and no extra properties.”
- “Give me a CSV with these columns and no more than 20 rows.”
Should not trigger
- “Research whether this claim is true.”
- “Fix this repository bug.”
- “Write a normal explanation with no machine-checkable shape.”
Inputs
Identify the desired format, fields or columns, required values, size limits, whether human semantic review remains required, and the candidate output. Keep the contract declarative JSON. Do not include commands, remote schema references, regexes, templates, or executable expressions. A literal URL value does not authorize network access.
Portable workflow
- State the smallest output shape that can be checked mechanically.
- Express it as a bounded declarative contract: JSON schema subset, CSV columns, enum values, string limits, or checklist items.
- Inspect the full contract or its hash-bound artifact before activation.
- Validate the candidate for syntax and declared structure.
- Mark factual, extraction, interpretation, and behavioral claims for independent evidence or human review.
- Stop after the original candidate plus at most two repairs; escalate rather than looping.
Safety boundary
Do not treat a schema pass as factual correctness. Do not execute contract content, fetch referenced resources, compile generated code, follow URLs, or silently repair unlimited candidates. Reject malformed or oversized contracts and candidates.
Verification
Report the contract identifier or hash, candidate attempt count, syntax result, structural result, semantic-review requirement, and any unresolved human review. A pass may mean only that the output matches the declared form.
Pi adapter
If an ordinary or queued correction leaves input unconfirmed, use /reliability input confirm first. That confirmation creates a new instruction; contract activation still needs its own native decision and cannot reuse expanded prompt text as authority. A retained-session plan report is untrusted Markdown, not a validator receipt.
When the reliability extension is enabled, use /reliability output-contract <path> and confirm the displayed contract before using reliability_gate action validate-output. The extension binds the confirmation and validator receipt to the current session branch. A native UI is required; RPC paths with ctx.hasUI can present the dialog, while headless or otherwise no-UI paths cannot activate a contract and must report the read-only limitation.
