Prompt Constructor in CAD Design

• Prompt Constructor is a proactive system that converts under-specified natural language prompts into executable CAD programs using a two-stage pipeline.
• It separates clarification from code generation by using a clarifier agent and a CAD coder, ensuring specification fidelity and reducing interaction overhead.
• The system employs formal MDP frameworks and template-driven auditing to improve geometric accuracy, significantly reducing Chamfer Distance and code invalidity.

A Prompt Constructor is a proactive agentic system developed to transform ambiguous or under-specified natural-language design prompts into executable programmatic representations, typically for computer-aided design (CAD) tasks. The Prompt Constructor architecture is exemplified by frameworks such as ProCAD, which separates prompt clarification from code generation through a two-stage pipeline, yielding robust, self-consistent output that aligns with user intent while minimizing unnecessary interaction overhead (Yuan et al., 3 Feb 2026).

1. Formalization of Prompt Construction and Clarification

The Prompt Constructor problem starts with a raw natural-language prompt $p \in \mathcal{P}$, which describes a target CAD artifact and may lack critical parameters or contain internal inconsistencies. The objective is to generate a valid program $y \in \mathcal{Y}$ (e.g., a CadQuery Python script) whose execution yields a mesh $M(y)$ that accurately reflects the user's intended shape, as measured by geometric metrics such as Chamfer Distance (CD).

To formalize this process, a clarifying agent is cast as a finite-horizon Markov Decision Process (MDP) $(\mathcal{S},\mathcal{A},R)$, with:

• States $s = (p,h)$, where $h = (q_1,v_1,...,q_k,v_k)$ logs the dialogue history of clarification questions $q_i$ and answers $v_i$,
• Actions $$\mathcal{A} = \{\text{ACCEPT}\} \cup \{\text{ASK}(u):\, u\in\mathcal{U}\}$$, enabling either accepting the specification or requesting targeted clarifications,
• Reward $R = -\mathrm{CD}(y) - \lambda \cdot C(h)$, with $y \in \mathcal{Y}$0 modulating the trade-off between specification fidelity and user interaction burden,
• Transitions update $y \in \mathcal{Y}$1 after each clarification cycle until a specification is accepted and passed to the code generator.

A prompt is classified as under-specified if required geometric or parametric details are missing in $y \in \mathcal{Y}$2 and $y \in \mathcal{Y}$3, and as conflicting if duplicated information presents mutually inconsistent values.

2. Pipeline Architecture and Agent Design

A two-agent system underpins this architecture:

• Proactive Clarifier ($y \in \mathcal{Y}$4): An LLM-based policy that parses the current state $y \in \mathcal{Y}$5, issuing clarification questions or accepting the current specification. Its outputs are strictly structured via a JSON schema:
  • If $y \in \mathcal{Y}$6 is unambiguous: {"is_misleading": false, "standardized_prompt": "<p>"}.
  • If ambiguities exist: {"is_misleading": true, "questions": [u_1, ..., u_k]}.
• CAD Coder ($y \in \mathcal{Y}$7): Another LLM-based agent that receives the standardized prompt $y \in \mathcal{Y}$8 (output of the clarifier) and emits an executable CadQuery program $y \in \mathcal{Y}$9.

Clarification proceeds iteratively, with the clarifier batching required questions and terminating once all ambiguities are resolved. This separation of concerns enforces modularity and interpretability in the generation process.

3. Prompt Clarification Templates and Specification Auditing

The clarifying agent utilizes a library of slot-filling natural language templates to interrogate the user about missing or conflicting information. Examples include:

Issue Type	Template Example
Missing Dimension	"Could you please specify the <feature> <parameter>?"
Conflicting Values	"There is a conflict for the <feature>: you wrote <val1> in one place and <val2> elsewhere. Which should we use?"
Missing Coordinate	"The vertex at X=<x> is missing its Y coordinate. What should Y be?"

The feature and parameter slots are populated from a domain-specific ontology (e.g., hole radius, plate thickness, leg length). These templates standardize clarification, ensuring coverage and minimizing redundant interaction.

4. Data, Training, and System Prompts

Training relies on a curated corpus of CAD specifications and corresponding programs. The ProCAD system originates from ∼17K CadQuery scripts reverse-engineered from DeepCAD point clouds. After deduplication and strict geometric checks (e.g., shapes with $M(y)$0), the final training set is further filtered to guarantee executable, unambiguous code.

• CAD Coder ($M(y)$1) Training: Supervised fine-tuning (SFT) on text-to-CadQuery pairs, using loss $M(y)$2 with $M(y)$3 enforcing code style constraints.
• Clarifier ($M(y)$4) Training: SFT on synthetic ambiguity pairs, generated by perturbing gold-standard prompts to induce under-specification and conflicts, then simulating user corrections by replaying ground-truth parameter values. The objective:

$M(y)$5

where $M(y)$6 denotes system prompts specifying schema and style for the clarifier outputs.

System prompts act as formal interface contracts, dictating expected input/output structures and ensuring compatibility between agents.

5. Evaluation Metrics and Empirical Results

The performance of a Prompt Constructor is quantified through task-relevant metrics:

• Chamfer Distance (CD):

$M(y)$7

Evaluates geometric fidelity between mesh $M(y)$8 and reference $M(y)$9.

• Invalidity Ratio (IR):

$(\mathcal{S},\mathcal{A},R)$0

Captures the robustness of code generation.

Using these metrics, ProCAD reduces mean CD by approximately 79.9% and IR from 4.8% to 0.9% relative to the strongest closed-source baselines. Clarifier efficiency (F₁ question coverage) approaches 0.97, and resolution (specification accuracy) is estimated at 0.93 (Yuan et al., 3 Feb 2026).

6. Best Practices and Systemic Trade-Offs

Effective Prompt Constructor design adheres to several best practices:

1. Two-Stage Pipeline: Decouple clarification from code generation for transparency and control.
2. Formal Ambiguity Criteria: Maintain precise thresholds and procedures for identifying and classifying missing/conflicting parameters, directly encoded into the reward structure.
3. Minimalist Clarification: Batch clarification queries to minimize dialogue rounds, reducing $(\mathcal{S},\mathcal{A},R)$1 in the agent's reward.
4. Template-Driven Auditing: Rely on domain-structured templates for consistent, comprehensive questioning.
5. Synthetic Ambiguity for Training: Systematically perturb gold-standard data to supervise clarifier behavior under various failure modes.
6. Trade-Off Handling: Adjust $(\mathcal{S},\mathcal{A},R)$2 in the agent's reward to flexibly bias the system toward user comfort or ultimate geometric fidelity.
7. Scalability and Maintenance: Harmonize backbones for clarifier and coder agents to streamline fine-tuning and inference.

An LLM judge may be employed as an automated evaluation tool to assess question quality, clarifier efficiency, and overall resolution. Adhering to strict input/output specifications via system prompts enables robust interfacing and reproducibility.

7. Limitations and Open Challenges

Despite its empirical effectiveness, several limitations persist:

• The quality of clarification is bounded by the coverage and specificity of templates and the underlying data. Ambiguities not representable within the preset library may cause incomplete resolution.
• Assumptions regarding the existence of a fully self-consistent, executable specification after minimal rounds are not universally valid for all design spaces.
• The current pipeline presumes a deterministic mapping from clarified prompts to code; higher diversity or multiple plausible specifications are not explicitly addressed.
• Extension to broader CAD domains, multimodal inputs, or integration with graphical design tools requires further advances in ontology design, template generation, and evaluation protocol development.

A plausible implication is that as prompt-constructor agents increase in sophistication and data coverage, they may generalize to more complex task settings, including non-CAD program synthesis, provided analogous clarification and auditing processes can be operationalized (Yuan et al., 3 Feb 2026).