Prompt Template Design – Creating a Reusable Modular System

Introduction: If You're Writing the Same Prompt 20 Times, You're Doing It Wrong

Suppose you're using AI to write 10 blog post drafts. Only the topics differ; the request method is identical. Same tone, same output format, same character limit. Each time, you either type a new prompt or copy the previous one and modify only the topic.

Two problems emerge in this process.

The first is inefficiency. The structure is identical, yet you write it from scratch each time. The second is inconsistency. Ten prompts modified slightly differently produce subtly different results. If the 9th post comes out in a different tone from the 1st, you can't trace why.

In software development, copying the same code 10 times is bad code. The same standard applies to prompt engineering.

The solution is simple: separate unchanging structure (templates) from changing values (variables). That's the entirety of this series.

---

1. The Nature of Variables: Separate Constants from Variables

1.1. Viewing Prompts as Functions

In programming, when the same logic repeats, you extract it into a function. A function takes parameters and returns results. Prompts can be designed in exactly the same way.

# Prompt from a function perspective
generate_blog_post(topic, tone, word_count, audience) → draft

Even if topic changes, you don't need to redesign tone, word_count, and audience each time. Structure is fixed; only inputs are swapped.

1.2. Before / After: Without Variables vs. With Variables

Before — Writing the prompt from scratch each time:

You're an IT tech blog specialist writer. Write a blog post draft on "Mastering Next.js App Router"
optimized for SEO. Your readers are web development beginners.
Use a friendly and practical tone. Keep it under 800 characters.

To change this to the next topic, "TypeScript Generics"? You rewrite the entire sentence.

After — Prompt template with variables:

You're an IT tech blog specialist writer. Write a blog post draft on "{{topic}}"
optimized for SEO. Your readers are {{audience}}.
Use a {{tone}} tone. Keep it under {{word_count}} characters.

When creating the next post, you only replace the values:

• {{topic}} = "Mastering TypeScript Generics"
• {{audience}} = "intermediate developers"
• {{tone}} = "technical and concise"
• {{word_count}} = 1200

Design the structure once. After that, fill in only the variables.

---

2. Variable Types: Distinguish and Use Five Types

Not all variables are the same. Classify them into five types by role and handle each differently.

2.1. Required Variables

Variables that must be filled with values. Do not execute if empty.

Notation: {{variable_name}}

Example:
Target for analysis: {{target_text}}

2.2. Optional Variables

Variables that may or may not have values. If absent, ignore that condition.

Notation: {{variable_name?}}

Example:
Additional constraints: {{constraints?}}
(If absent, follow default settings.)

2.3. Default Variables

Specify a value to use in place when none is provided.

Notation: {{variable_name:default_value}}

Example:
Output language: {{lang:English}}
Character limit: {{word_count:800}}

If no value is specified, "English" and "800 characters" are applied automatically.

2.4. Conditional Variables

Include or exclude entire blocks of the prompt based on specific conditions.

Notation: {{#if condition}} ... {{/if}}

Example:
{{#if include_summary}}
Add a 3-line summary at the end.
{{/if}}

The summary instruction is included in the prompt only when include_summary = true.

2.5. Loop Variables

Iterate over list-type inputs and repeat identical processing.

Notation: {{#each items}} ... {{/each}}

Example:
Summarize each of the following items in one sentence:
{{#each paragraphs}}
- {{this}}
{{/each}}

---

3. Template Anatomy: Four-Section Structure

A well-designed prompt template consists of four sections. Understanding the order and role of each enables you to create a structure applicable to any task.

3.1. Roles of the Four Sections

[CONTEXT]    — Who and under what situation (Persona + Situation)
[INSTRUCTION] — What and how to do it (Action + Method)
[INPUT]       — Actual data to process (Variables)
[OUTPUT]      — Output format and constraints (Format + Constraints)

3.2. Four-Section Template Example: Technical Document Translator

[CONTEXT]
You are a specialist technical document translator. You are fluent in both {{source_lang}} and {{target_lang}},
maintain technical terms precisely while using natural expression.
Target audience: {{audience}}

[INSTRUCTION]
Translate the text below into {{target_lang}}.
Translation principles:
1. Keep technical terms (API, library names, etc.) as-is from the source
2. Convert formal language → {{target_tone}} tone
3. For ambiguous meanings, add notes in [Note: Source: xxx] format
{{#if preserve_formatting}}
4. Maintain the original markdown format (headers, code blocks, lists) as-is
{{/if}}

[INPUT]
Text to translate:
---
{{source_text}}
---

[OUTPUT]
- Output translation only (no explanations)
- Maintain markdown format
- If {{word_limit?}} character limit exists, cut at a natural point and mark "[Continued]"

With this single template, you can handle various translation tasks: English↔Korean, technical documents, marketing copy, and more. Only the variables change.

---

4. Modular System: Assemble Prompts Like LEGO

A single template handles one task. But real workflows are pipelines with multiple connected steps. By creating these steps as independent modules and combining them, you can automate entire complex workflows.

4.1. Atomic Modules: Minimal Unit of Reuse

An atomic module is the smallest prompt unit performing only one role.

# Atomic module examples

[tone_module]
Tone: {{tone}} (formal / friendly / technical / persuasive)

[format_module]
Output format:
- Title: H2 header
- Body: Paragraph-separated
- Key keywords: **bold**

[audience_module]
Reader level: {{audience_level}} (beginner / intermediate / expert)
Technical terms: {{terminology_policy}} (explain / use as-is)

These modules can be used independently or inserted into other templates.

4.2. Composite Modules: Combining Atoms

A composite module combines multiple atomic modules to perform one complete function.

# Composite module: Blog Post Generator

[CONTEXT]
You are an IT tech blog specialist writer.
{{audience_module}}  ← Insert atomic module

[INSTRUCTION]
Write a blog post draft on "{{topic}}".
SEO keywords: {{seo_keywords}}

[OUTPUT]
{{format_module}}   ← Insert atomic module
{{tone_module}}     ← Insert atomic module
Character limit: {{word_count:1000}} characters

4.3. Pipeline: Connect Modules in Sequence

Construct a 3-step pipeline using the entire content creation workflow as an example.

[Step 1: Research Module]
Input: {{topic}}, {{depth_level}}
Output: 5 key points + related data list

      ↓ Pass output as {{research_result}} to next step

[Step 2: Draft Generation Module]
Input: {{research_result}}, {{tone}}, {{word_count}}
Output: Structured blog draft

      ↓ Pass output as {{draft}} to next step

[Step 3: Review & Improvement Module]
Input: {{draft}}, {{review_criteria}}
Output: Revised final version + summary of changes

Each step's output becomes the next step's input. In this structure, replacing or upgrading one module doesn't impact the entire pipeline.

---

5. Practical Template Library: Three Ready-to-Use Templates

Completed templates applying theory. Fill in variable values and use immediately.

5.1. Code Review Template

[CONTEXT]
You are a senior developer specializing in {{tech_stack}}.
Provide balanced reviews from three perspectives: code quality, performance, and security.

[INSTRUCTION]
Review the code below.
Review criteria:
- Bug potential (classify as Critical / Warning / Info)
- Performance improvement points
- Security vulnerabilities
{{#if include_refactor}}
- Refactoring suggestions (include improved code snippets)
{{/if}}

[INPUT]
Code to review:
\`\`\`{{language}}
{{code}}
\`\`\`

[OUTPUT]
## Review Summary
- Critical: (count)
- Warning: (count)
- Info: (count)

## Detailed Feedback
(Explanation per item)

5.2. Meeting Notes → Action Items Extraction Template

[CONTEXT]
You are a project manager assistant.
The goal is to extract only actionable decisions from meeting content.
Do not process vague mentions as action items.

[INSTRUCTION]
Extract action items from the meeting notes below.
Extraction criteria:
- Include only items with clearly designated owners
- Include deadline if mentioned
- Distinguish between decision items and execution items

[INPUT]
Meeting notes:
---
{{meeting_notes}}
---
Participants: {{participants?}}

[OUTPUT]
## Decision Items
| Decision | Decision-maker |
|----------|--------|

## Action Items
| Item | Owner | Deadline | Priority |
|------|--------|------|----------|

## Open Items (Requires further discussion)
- (Mark "None" if no items)

5.3. Data Analysis Report Template

[CONTEXT]
You are a data analysis specialist. You are familiar with the {{domain}} domain,
and prioritize delivering insights in language understandable to non-technical decision-makers.

[INSTRUCTION]
Analyze the data below and write a report.
Analysis perspective: {{analysis_focus}} (trend / anomaly / comparison / forecast)
Business question to emphasize: {{business_question}}

[INPUT]
Data:
{{data}}

Period: {{period?}}
Comparison baseline: {{baseline?}}

[OUTPUT]
## Key Findings (Executive Summary, 3 lines max)

## Detailed Analysis
(Analysis content)

## Business Implications
(Recommendations for decision-makers)

## Limitations and Caveats
(Data reliability, analysis scope, etc.)

---

Conclusion: Prompts Are Managed Like Code

The moment you introduce variables and templates, prompts transform from one-time instructions into reusable assets.

Writing a single prompt well is the realm of 'users'. Designing prompts as a system is the realm of 'engineers'. The three steps—abstracting with variables, structuring with templates, assembling with modules—mark that boundary.

Practical Application Method

Try these three things right now.

1. Find prompts you repeat. If there's a prompt with similar structure you use 3+ times per week, it's your first template candidate.
2. Mark changing parts as {{variables}}. The rest becomes structure.
3. Fix output format. Simply specifying an [OUTPUT] section dramatically improves consistency.

Toward Part 8: Self-Consistency

Once you've secured consistent structure with templates, the next question is: "Can you ask the same question multiple times to get more accurate answers?"

In the upcoming [Part 8: Self-Consistency – Raising Accuracy Through Multiple Reasoning Paths], we'll cover techniques to execute identical prompts multiple times and integrate results for far higher accuracy than single execution. Especially for problems with one correct answer (math calculations, logical reasoning, classification), the effect of this technique is dramatic.