Parameters

In this step, you’ll turn a one-off prompt into a reusable template by adding parameters—named placeholders (like {{OUTPUT_FORMAT}}, {{WORD_LIMIT}}, {{AUDIENCE}}) that control inputs, structure, tone, and guardrails without rewriting the prompt.

You’ll leave knowing which knobs to expose, how to declare them up front, and how to wire them into the body so the same prompt reliably adapts across repos, teams, and tools.

Problem

Your prompt works, but only for one situation. If you change the audience, format, or goal, you have to rewrite chunks of it by hand. It’s brittle and hard to reuse.

Your task is to refactor your prompt to use parameters (like {{TONE}} or {{OUTPUT_FORMAT}}) so you can easily swap values without editing the whole thing. This will make your prompt flexible, maintainable, and ready to scale across different contexts.

What you need to know

Parameters are named placeholders that control a prompt’s behavior without changing its wording. They act like function arguments: some supply inputs/context (what to read), others define the shape of the output (Markdown vs JSON and its schema), and others tune style and constraints (tone, word limit, strictness). Good parameters are minimal, explicit, and orthogonal—each one should change exactly one thing.

Example

{{FUNCTION_NAME}} = makeNetworkRequest

{{TEST_FRAMEWORK}} = Jest

---

Write a unit test for {{FUNCTION_NAME}} called {{FUNCTION_NAME}}Test using the {{TEST_FRAMEWORK}} framework.

If the test framework is Jest, use mocks; If it’s Cypress, take screenshots of the final result.

In practice, declare a compact parameter block at the very top of the prompt, then reuse those placeholders throughout the instructions. This keeps the body of the prompt stable while you vary behavior by changing only the parameter values.

For example: set {{OUTPUT_FORMAT}} = json and the prompt’s output will change automatically; switch {{AUDIENCE}} = beginner and your tone/definitions adapt without touching the rest of the prompt.

Parameters should be easily distinguishable from the normal text in the prompt. Throughout this document, we’re using the {{PARAM_NAME}} syntax, but you can use whatever makes sense for you.

Do’s and Don’ts

• Keep parameters few and focused

  • Do: Make each parameter control exactly one thing.

  • Don’t: Create overlapping knobs that fight each other.

• Use clear, stable names

  • Do: Prefer {{OUTPUT_FORMAT}}, {{WORD_LIMIT}}, {{AUDIENCE}}.

  • Don’t: Use vague labels like {{MODE}} or {{LEVEL}}.

• Test combinations, not just the happy path

  • Do: Run a tiny matrix (e.g., markdown/json × concise/professional) to verify interactions.

  • Don’t: Assume one successful run means all settings behave.

• Use explicit conditional branches in the prompt

  • Do: Write clear “if/then” clauses tied to parameters (e.g., If {{OUTPUT_FORMAT}}=json, return exactly {...} keys; otherwise use the Markdown skeleton).

  • Don’t: Bury conditions in prose or mix branches, make each branch unambiguous and mutually exclusive.

• Document allowed parameter values

  • Do: Declare allowed values and sensible defaults (e.g., {{OUTPUT_FORMAT}} = markdown|json (default: markdown)).

  • Don’t: Leave values open-ended or undocumented.

Types of Parameters

A curated list of different types of parameters to give you an idea of how they work in different scenarios:

Technical Requirements

✏️ Complete the following steps to add parameters to your prompt.

1. Identify potential parameters

   1. Scan your prompt and mark anything that can be parameterized (its value could be swapped without changing the structure of the prompt)

      1. Ex. format, tone/audience, word limits, paths/URLs, frameworks, languages, strictness, etc.

2. Create a compact parameter block (top of prompt)

   1. Add a small header with names, allowed values, and sensible defaults. Keep names clear and stable:

      1. Note: when you run the prompt, you’ll need to choose from the allowed values, but it’s good to document these things if you’re going to be sharing the prompt.

         {{OUTPUT_FORMAT}} = markdown | json (default: markdown) {{AUDIENCE}} = beginner | expert (default: expert) {{WORD_LIMIT}} = 600 (±10%) {{CODEBASE_PATH}} = /path/to/repo {{STRICT_MODE}} = on | off (default: on)

3. Refactor the body to use placeholders

   1. Identify the places throughout your prompt that can be replaced by parameters.

   2. Replace any hard coded values in the body of the prompt with the corrisponding {{PARAMETER}} tag that you defined at the top of the prompt. Ensure each parameter controls exactly one thing.

      1. ... parameter definition block ... Write a document for {{AUDIENCE}} in {{OUTPUT_FORMAT}} Limit it to {{WORD_COUNT}} words

4. (Optional) Add explicit conditionals for branching behavior

   1. Use if/else logic to add decision making and intelligence to the prompt

      If {{OUTPUT_FORMAT}}=json, return a single JSON object with keys Else if {{OUTPUT_FORMAT}}=markdown, return a markdown file with structured headers Else, return plain text

5. Test a tiny matrix of combinations

   1. Run 3–4 quick checks of the prompt with different combinations of parameters to make sure everything plays nice.

      1. markdown × json

      2. beginner × expert

      3. strict on × off

   2. Fix any ambiguous instructions revealed by these tests.

Solution

We take everything we’ve built so far for the instructions.md prompt, and parameterize it:

Parameters:

• {{CODEBASE_PATH}}: /path/to/the/repository

• {{OUTPUT_FORMAT}}: markdown

• {{TONE}}: professional

• {{WORD_LIMIT}}: maximum 500 words

You are a senior full-stack engineer documenting a codebase for a new AI teammate.
Generate an instructions.md file that explains the purpose, architecture, dependencies, and coding conventions of the project.

Use the example outlines below to help shape your output. The final document should be detail-rich and include a variety of sections:

Good Example Outline:

• Overview: Brief but informative project description

• Architecture: Explanation of major components (frontend/backend, APIs, database)

• Dependencies: Key frameworks, libraries, versions

• Conventions: Folder structure, naming patterns, style guides

• Setup Instructions (if relevant): Install, run, test steps

• Common Pitfalls: Gotchas or non-obvious behaviors

Bad Example Outline:

• Overview: "It’s a web app"

• No architecture section

• Lists dependencies with no context

• Doesn’t explain folder structure or coding practices

• No instructions or assumptions listed

---

Think step-by-step before writing the file:

1. Identify key folders and their purpose.

2. Determine main dependencies and frameworks.

3. Describe how the components fit together.

4. Write the final instructions.md file in Markdown format.

First, propose two possible outline structures for the instructions.md file — one organized by architecture, another by developer workflows.
Evaluate which outline will be clearer and more useful, then write the file using that structure.

 

Output the result as {{OUTPUT_FORMAT}}, in a {{TONE}} tone, and within the {{WORD_LIMIT}} limit.
Begin by analyzing the codebase at {{CODEBASE_PATH}}.

Output Description:
The AI now respects constraints (word count, tone), and outputs in the specified format (e.g. Markdown).
If you switch {{OUTPUT_FORMAT}} to JSON, it automatically adapts the structure.

What Changed

Our prompt is now modular, reusable, and enforceable.
It’s effectively a configurable “prompt function” that can run anywhere.

Next Steps

Your prompt is now more modular and re-usable thanks to parameters!

Continue to: ChecklistsPreview

In the next step, you’ll help the AI keep track of what it’s doing using a checklist.

Sources