A prompt-template parameter is a named placeholder replaced with a concrete value before a prompt is sent to a language model. It keeps changing inputs separate from stable instructions, so one template can serve many runs. Here, “parameter” refers to a prompt input, not a model-internal setting. section 2.5 section 2.0
Use parameters as part of a repeatable workflow:
- Keep the task instructions and required output format stable. Add named placeholders only for values that change across runs; static inputs can remain ordinary context. section 2.9 section 2.8
- Choose a placeholder style consistently: Python f-strings use {placeholder}, while Jinja2 uses {{placeholder}}. Fill every placeholder manually or programmatically before sending the prompt. section 2.5
- Delimit dense or external input where it could be confused with instructions. Test the resolved template with varied input combinations before relying on its results. section 5.3.1 section 5.0
Release-note template
A release-note prompt fixes the instruction to produce sections for features, bug fixes, and breaking changes. It varies {version}, {product_name}, {features}, {bug_fixes}, and {breaking_changes}. Filling those fields for payment-gateway-sdk v2.8.0 produces a release-specific prompt without rewriting the task. section 2.5.2
For multistep work, one run can supply a later run’s input. A refactor workflow first asks about hidden dependencies and rollback needs, then injects the assessment answers into a planning template. Evaluate whether outputs remain useful and consistent across different inputs; a reusable template is not reliable merely because its placeholders resolve. section 5.3.3 section 5.0
