Ambiguous Goal Refinement Prompt Template

This prompt is designed for the critical translation layer between a raw, often vague user request and a downstream agent planner or orchestrator. Its primary job is to take an input like 'optimize our database performance' or 'help us reduce churn' and force the model to make implicit assumptions explicit, define a concrete scope, and produce verifiable success criteria. It is a machine-to-machine refinement step, not a conversational clarification tool for end users. The ideal deployment point is within an agent frontend or a planning pre-processor module that receives unstructured goals and must produce a structured GoalSpecification object that a planner, task decomposition module, or orchestrator can consume without further human interpretation.

Use this prompt when the initial user request contains high-level objectives, ambiguous verbs (e.g., 'improve,' 'analyze,' 'fix'), or lacks measurable boundaries. It is particularly valuable when the cost of misaligned execution is high—such as in autonomous coding agents, multi-step data pipelines, or customer-facing automation where a wrong assumption can cascade into expensive tool calls or incorrect outputs. The prompt template includes placeholders for [USER_GOAL], [AVAILABLE_TOOLS], and [CONSTRAINT_HINTS], allowing you to inject known operational boundaries before refinement begins. The output should be validated against a schema that requires explicit in_scope, out_of_scope, assumptions_made, and success_criteria fields, ensuring the refinement is auditable before execution starts.

Do not use this prompt when the user has already provided a detailed specification with measurable acceptance criteria, or when the task is trivial enough that the refinement overhead exceeds the execution cost. For example, a direct instruction like 'list all users created in the last 24 hours' does not require goal refinement; it requires a direct tool call. Similarly, avoid this prompt in latency-sensitive, single-turn interactions where the user expects an immediate answer rather than a planning artifact. In high-risk domains, always route the refined goal specification through a human review step before execution begins, and log the refinement output alongside the original user input for auditability and debugging.

This template is designed to be placed in the system prompt of an agent pre-processor or planning module. It receives a vague user request and outputs a structured clarification. The prompt forces the model to identify missing dimensions—scope, constraints, success criteria, and authority boundaries—rather than silently guessing. Use this when the user's initial input is a single sentence or a broad desire, and the downstream planning system requires a concrete, machine-readable goal specification to avoid loops, over-execution, or misaligned plans. Do not use this template for simple, well-constrained commands where clarification would add unnecessary latency.

textCopy
You are a goal refinement engine. Your job is to convert an ambiguous user request into a clarified, actionable goal specification. You must identify what is underspecified and make reasonable, safe assumptions explicit. Do not execute the goal. Do not plan the steps. Only produce the refined specification.

## INPUT
User Request: [USER_REQUEST]
Available Context: [CONTEXT]

## OUTPUT SCHEMA
Return a JSON object with the following fields:
- clarified_goal: A single, concise statement of what should be accomplished. Resolve vague pronouns and implicit references.
- scope: An object with `in_scope` (array of strings) and `out_of_scope` (array of strings). Explicitly list what is included and excluded.
- constraints: An object with sub-fields for `security`, `data_handling`, `operational`, `output_format`, and `other`. Each sub-field is an array of constraint strings. If a category has no known constraints, use an empty array.
- success_criteria: An array of objects, each with `criterion` (string) and `verification_method` (string describing how to check if it was met).
- assumptions: An array of strings listing assumptions you made to resolve ambiguities. Flag high-risk assumptions with `[NEEDS VERIFICATION]`.
- authority_boundary: A string describing what actions the agent is permitted to take without human approval, and what requires escalation.
- unresolved_ambiguities: An array of strings listing questions that must be answered before safe execution. If none, use an empty array.

## CONSTRAINTS
- Prefer safety: if an action could be destructive or irreversible, flag it in `authority_boundary` as requiring human approval.
- Be specific: replace vague terms like "analyze" with concrete outputs like "produce a CSV report with columns X, Y, Z."
- If the user request contains conflicting desires, note them in `unresolved_ambiguities` rather than silently choosing one.
- Do not invent user preferences. If a choice is arbitrary, state your assumption in the `assumptions` field.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace the square-bracket placeholders with your specific inputs. [USER_REQUEST] should contain the raw, unedited user input. [CONTEXT] can include conversation history, user profile data, or environmental state. [EXAMPLES] should contain 2-3 few-shot demonstrations of vague inputs mapped to refined outputs, covering edge cases like conflicting constraints or high-risk actions. [RISK_LEVEL] should be set to low, medium, or high to adjust the model's conservatism in the authority_boundary and assumptions fields. For high-risk domains, add an additional instruction requiring that all assumptions be explicitly tagged for human review before any downstream execution. After generating the refined goal, validate the output against the JSON schema and check that unresolved_ambiguities is non-empty when the input is genuinely underspecified—an empty array for a vague request is a failure signal.

The Ambiguous Goal Refinement prompt is designed to sit at the entry point of an agent pipeline, acting as a pre-processor before any planning or tool-use modules are invoked. It should be called synchronously after user input is received but before the main agent loop begins. The prompt expects a raw, potentially vague user request as [USER_GOAL] and any available [CONTEXT] such as user role, session history, or known tool capabilities. The output is a structured clarification containing a refined goal statement, explicit scope boundaries, enumerated constraints, and measurable success criteria. This output becomes the input contract for downstream planning, task decomposition, and execution modules.

To integrate this into an application, wrap the prompt in a function that enforces a strict JSON output schema. Use a model with strong instruction-following and JSON mode enabled (e.g., gpt-4o, claude-3.5-sonnet with structured outputs). The application layer must validate the returned JSON against a schema that requires at minimum: refined_goal (string), scope_inclusions (array of strings), scope_exclusions (array of strings), constraints (array of objects with type and description), and success_criteria (array of strings). If validation fails, implement a single retry by feeding the validation error back into the prompt as [PREVIOUS_ERROR]. If the retry also fails, route the interaction to a human-in-the-loop queue rather than proceeding with an under-specified goal. Log the raw user input, the refined output, and the validation result for observability and prompt debugging.

For high-stakes domains such as healthcare, finance, or legal workflows, add a mandatory human review step after refinement. Present the clarified goal, scope, and constraints to the user for explicit confirmation before the agent proceeds. Do not treat the model's refinement as authoritative without user sign-off. Additionally, implement a specificity improvement eval: compare the number of ambiguous terms in the raw input versus the refined output using a simple heuristic (e.g., count of words like 'it', 'that', 'stuff', 'things', or undefined pronouns). If the refinement did not reduce ambiguity, flag the interaction for prompt template review. Avoid wiring this prompt directly to autonomous execution without these guardrails, as under-specified goals are the most common root cause of agent loops, over-execution, and misaligned plans.