Infrastructure-as-Code Tool Comparison Prompt Template

This prompt is designed for technical decision-makers who need a rigorous, evidence-backed comparison of Infrastructure-as-Code (IaC) tools—specifically Terraform, Pulumi, AWS CDK, and OpenTofu. The primary job-to-be-done is generating a structured trade-off matrix that can be directly ingested into an Architecture Decision Record (ADR), an internal wiki, or a downstream comparison UI. It assumes the user already possesses a working knowledge of IaC concepts such as state management, provider plugins, and drift detection, and needs a side-by-side analysis, not an introductory tutorial.

Use this prompt when you are actively choosing between these tools and need to evaluate them across consistent, critical dimensions like multi-cloud accuracy, testing support, and state file handling. The prompt enforces a strict JSON output schema, making it ideal for automated pipelines where the output must be parsed by another system without manual cleanup. It is particularly valuable when the decision involves multiple stakeholders who require a traceable, evidence-backed justification for the final tool selection, as the matrix format highlights trade-offs rather than prescribing a single winner without context.

Do not use this prompt for general cloud service comparisons (e.g., AWS vs. Azure vs. GCP) or for deep-dive tutorials on a single tool. It is not designed to generate implementation code, troubleshoot specific configuration errors, or compare tools outside the defined set. If your goal is to understand the basic syntax of Pulumi or debug a Terraform state lock, a different, more targeted prompt is required. For high-risk production migrations, always pair the generated matrix with a human review step to validate the accuracy of provider coverage claims and version-specific features before finalizing any architectural decision.

This prompt is designed to be pasted directly into your AI harness. It instructs the model to produce a strict JSON output that compares [TOOL_LIST] across the dimensions you define in [COMPARISON_DIMENSIONS]. The prompt enforces a schema-first approach, requiring the model to output a valid JSON object with a matrix array and a summary object. Replace every square-bracket placeholder with your specific inputs before sending the request. The prompt assumes your system can enforce JSON mode or structured output; if it cannot, add an explicit instruction to wrap the output in a markdown code fence.

textCopy
System: You are a technical analyst specializing in Infrastructure-as-Code (IaC) tooling. Your task is to produce a structured, evidence-based comparison of the tools listed in [TOOL_LIST]. You must output only a valid JSON object conforming to the schema described in [OUTPUT_SCHEMA]. Do not include any text outside the JSON object.

User: Compare the following IaC tools: [TOOL_LIST].

Evaluate each tool across these dimensions: [COMPARISON_DIMENSIONS].

For each dimension, provide a rating from the controlled vocabulary in [RATING_SCALE] and a concise, factual justification grounded in the tool's documented capabilities as of [KNOWLEDGE_CUTOFF]. If information for a dimension is not publicly documented, set the rating to "UNKNOWN" and note this in the justification.

Additional constraints:
- [CONSTRAINTS]

Output must strictly follow this JSON schema:
[OUTPUT_SCHEMA]

Here are examples of the expected output format:
[EXAMPLES]

Adaptation Notes: The [TOOL_LIST] placeholder should be a comma-separated list of tools (e.g., "Terraform, Pulumi, OpenTofu, AWS CDK"). The [COMPARISON_DIMENSIONS] should be an array of strings representing the facets to compare (e.g., ["State Management", "Provider Coverage", "Testing Support", "Multi-Cloud Maturity"]). The [RATING_SCALE] should define your controlled vocabulary, such as ["BEST-IN-CLASS", "ADEQUATE", "LIMITED", "UNSUPPORTED", "UNKNOWN"]. The [OUTPUT_SCHEMA] placeholder must be replaced with a valid JSON Schema object defining the structure of the matrix array and summary object. The [CONSTRAINTS] field is where you add rules like "Do not compare pricing" or "Focus only on GA features." The [EXAMPLES] placeholder should contain one or two few-shot examples of the desired output format to anchor the model's behavior. For high-stakes decisions, always route the output through a human review stage before using it to inform architecture choices.

This prompt is designed to be called programmatically within a CI/CD or internal tooling workflow, not just as a one-off chat interaction. The primary integration point is an API call to a model endpoint (OpenAI, Anthropic, or a self-hosted model) where the prompt template is populated with the [TOOLS_LIST], [COMPARISON_DIMENSIONS], and [OUTPUT_SCHEMA] variables. The output must be treated as a structured artifact that feeds into a downstream decision record or architecture review document. Because the comparison involves infrastructure choices with cost, security, and operational implications, the implementation harness must include automated validation, a retry strategy for malformed outputs, and a mandatory human review step before the comparison is accepted as a decision input.

The recommended architecture is a three-stage pipeline: Generation → Validation → Review. In the generation stage, use a model with strong JSON mode or structured output support (e.g., gpt-4o with response_format: { type: 'json_schema', json_schema: {...} } or Claude with tool-use for the target schema). Set temperature to 0.1–0.2 to maximize factual consistency and schema adherence. In the validation stage, parse the output against the expected JSON Schema and run domain-specific checks: verify that each tool in [TOOLS_LIST] appears in the matrix, that all [COMPARISON_DIMENSIONS] are covered, that scores are within the defined range (e.g., 1–5), and that evidence_summary fields are non-empty strings. If validation fails, retry up to two times with the error messages appended to the prompt as [PREVIOUS_ERRORS]. After two failures, escalate to a human operator with the partial output and error log. Log every generation attempt, validation result, and retry to an observability platform (e.g., LangSmith, Braintrust, or custom logging) for traceability.

For teams using RAG to ground comparisons in live documentation, implement a retrieval step before prompt assembly. Fetch the latest docs for each tool in [TOOLS_LIST] from official sources or an internal knowledge base, then inject the retrieved chunks into the [CONTEXT] variable. This reduces hallucinated features and stale claims. However, retrieval introduces latency and potential source conflicts—add a source_confidence field to the output schema so reviewers can spot low-confidence claims. When the comparison covers regulated infrastructure (e.g., FedRAMP, HIPAA), the human review gate is non-negotiable. Build the review step as a simple UI or Slack notification that presents the validated JSON alongside a diff against the previous comparison run, letting the reviewer approve, reject, or annotate individual cells. Do not treat this prompt as a fire-and-forget generator; it is a structured evidence compiler that requires operational guardrails before it influences infrastructure decisions.