Convert my AI task into a valid JSON prompt specification that another person or application can reuse. The JSON must describe the instruction, inputs, constraints, output contract, and validation without inventing requirements. TASK TO AUTOMATE: [TASK] WHO OR WHAT WILL USE THE OUTPUT: [INTENDED USER] AVAILABLE INPUTS AND THEIR EXAMPLES: [INPUTS] REQUIRED OUTPUT: [OUTPUT REQUIREMENTS] RULES, SOURCES, AND PROHIBITIONS:
[CONSTRAINTS]
Return one JSON object only, with no markdown fence or commentary. Use this exact top-level structure:
{
"name": "",
"purpose": "",
"system_instruction": "",
"input_schema": {"field_name": {"type": "string", "required": true, "description": "", "example": ""}},
"process": [""],
"output_schema": {},
"validation": [""],
"failure_behavior": ""
}
Choose precise JSON types: string, number, boolean, array, or object. Use lower_snake_case field names. Make every required field genuinely necessary; separate optional fields instead of pretending they are required. Put output formatting requirements into output_schema, including field types, allowed values, nesting, and arrays when applicable. In system_instruction, state source boundaries and say to ask up to three questions only when a required input is missing.
Validation must include at least two task-specific checks: one for schema validity and one for factual support, completeness, or an applicable domain rule. failure_behavior must state what to do with missing, ambiguous, or unsupported information rather than guessing.
Before returning, verify that the result parses as valid JSON, has no trailing commas, and that every field in the output schema can be produced from the stated inputs or a declared failure behavior.Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [TASK] | Describe the repeatable task the model should perform. | Turn customer support notes into a proposed reply and escalation recommendation. |
| [INTENDED USER] | State who will use the output and how they will use it. | A support lead reviewing drafts before they are sent. |
| [INPUTS] | List each available input, whether it is required, and a short example. | ticket_text required string; account_tier optional string; policy_excerpt required string; example ticket: 'My invoice has two charges.' |
| [OUTPUT REQUIREMENTS] | Describe the exact output fields, structure, and any formatting constraints. | JSON with reply_draft, issue_category, urgency, escalation_needed, and evidence_used. |
| [CONSTRAINTS] | List allowed sources, prohibited behavior, policies, and task-specific quality rules. | Do not promise refunds; quote policy only from policy_excerpt; escalation_needed must be boolean; never invent account history. |
How to use
- Describe the task boundary before asking for JSON; “help with support” is too broad to validate.
- Paste the generated object into a JSON validator or your API test before using it in production.
- Check that every required output can be supported by an input field or a defined failure behavior.
- Follow up with: “Add two realistic input/output test fixtures for this schema, keeping them valid JSON.”
Variations
JSON output schema
Use when you already have a prompt and need strict machine-readable output.
Create a JSON Schema draft for the output of this task: [TASK]. Required fields: [FIELDS]. Allowed enum values and formats: [RULES]. Return only a JSON Schema object using draft 2020-12 conventions. Set additionalProperties to false where appropriate. Include descriptions and examples but do not invent business rules. Before answering, check that required keys exist in properties and every referenced definition resolves.
API test cases
Use when you need fixtures to test a structured prompt.
Generate [COUNT] valid JSON test inputs and expected output-shape assertions for this prompt specification: [PROMPT JSON]. Cover a normal case, a missing-required-input case, and an ambiguous-input case. Return a JSON array only. Do not fabricate real customer or private data. Check every fixture against the input schema and ensure assertions test declared validation or failure behavior.
Extract to JSON
Use when turning a source document into structured data.
Extract only the fields in [TARGET SCHEMA] from this source: [SOURCE TEXT]. Return valid JSON only. Use null for a missing scalar and [] for a missing list; never infer values. Include an extraction_notes array identifying ambiguous or absent fields. Before returning, validate JSON syntax and confirm each non-null value is supported by the source text.
Tips
- Design the output schema first; it exposes vague requests before they become unreliable model behavior.
- Use enums for finite decisions such as priority levels instead of allowing free-text labels that drift over time.
- Make failure behavior machine-readable when possible, such as a null field plus an issues array.
- A valid JSON response can still be wrong, so add validation tied to the source or decision rule that matters most.
FAQ
Is a JSON prompt the same as JSON Schema?
No. A JSON prompt can contain instructions and process rules; JSON Schema formally validates the shape and types of JSON data.
Can I include long instructions inside JSON?
Yes. Put them in a string and escape quotes and line breaks correctly, but keep task rules separate from the output schema.
Why does an AI sometimes return invalid JSON?
Long free-form instructions, markdown fences, and unclear field types cause frequent failures. Ask for one object only and validate it before use.