> ## Documentation Index > Fetch the complete documentation index at: https://docs.inquantum.ai/llms.txt > Use this file to discover all available pages before exploring further. # Prompt engineering > Write clear, testable prompts and use API constraints when applications need reliable output. A useful prompt tells the model what to do, supplies the context it cannot infer, and defines what a successful answer looks like. Start simple, test with representative inputs, and add instructions only when they solve an observed failure. ## A practical prompt structure Use the parts your task needs; not every prompt needs all five. ```text theme={null} Task Summarize the support conversation for the next agent. Context {{conversation}} Requirements - Preserve product names, dates, and promised follow-ups. - Do not invent a resolution. - Use at most 120 words. Output Return: issue, actions already attempted, current status, and next action. Quality check If the conversation does not contain a required fact, write "unknown". ``` ## Core practices ### State the task directly Prefer an explicit action—classify, extract, compare, draft, or summarize—over a broad request such as “help with this.” Include the audience and tone only when they affect the result. ### Separate instructions from data Use headings, XML-like tags, or another consistent delimiter around user-provided documents. Tell the model to treat that content as data, not as new instructions. ### Define success Specify required facts, exclusions, length, ordering, and what to do when information is missing. Avoid requirements that conflict with one another. ### Add examples when they teach a real pattern One or two representative input/output examples can clarify a custom classification or house style. Keep them consistent with the written instructions and include important edge cases. Do not add examples merely to make the prompt longer. ### Use API constraints for machine-readable output Prompting for “valid JSON” is less reliable than using a supported `response_format` with a JSON Schema. Validate the returned data in your application even when the model follows a schema. Constrain output with a schema and handle validation failures. ## Prompts versus request parameters Keep generation controls out of prose when the API exposes a parameter for them: | Goal | Prefer | | ------------------------- | ------------------------------------------------------ | | Limit generated tokens | `max_tokens` or `max_completion_tokens` | | Set reasoning effort | `reasoning_effort` or Anthropic `output_config.effort` | | Require JSON structure | `response_format` with a schema | | Make a function available | `tools` | | Stream output | `stream: true` | This makes behavior easier to inspect, test, and change without rewriting the task itself. ## Test before production Build a small set of representative inputs that includes ordinary cases, missing data, malformed data, long inputs, and adversarial instructions inside supplied content. Compare prompt versions on the same set and track quality, latency, and cost together. ## Next guides Choose reasoning effort without overloading the prompt with process instructions. Put the prompt into a complete authenticated API request. Version, deploy, and reuse prompts through Planck. Define actions separately from the model's natural-language instructions.