Resource
API Request Variable Builder
Turns a reusable API request prompt into a clean variable set covering endpoint, method, auth, payload, response format, and error handling.
User Story Variable Builder
Documents and exports variables from user story and acceptance criteria prompt templates — persona, goal, outcome, constraints, and definition of done.
Overview
User story templates accumulate variables unevenly. Persona and goal are almost always named consistently; acceptance criteria and definition of done vary across copies. When the same template is reused across sprint planning tools and backlog automations, {{acceptanceCriteria}} and {{criteria}}, or {{definitionOfDone}} and {{dod}}, appear as separate names for the same field in different team versions. The Prompt Variable Builder flags these similar names so you can consolidate to one consistent set before the template is shared across the team.
How to use this resource
-
Open in Prompt Variable Builder
Load this template into the tool. The textarea will show the user story template with its persona, goal, and acceptance criteria variables.
-
Check for similar variable names
If your team's templates use {{acceptanceCriteria}} and {{criteria}}, or {{definitionOfDone}} and {{dod}}, the similarity check will flag them. Rename to one consistent form before the template enters a backlog automation.
-
Set types and add descriptions
Most fields are text. The priority variable might be list (High/Medium/Low). Add a description to acceptanceCriteria to clarify whether it expects plain text, Given/When/Then format, or numbered criteria.
-
Export for your team
Use the Markdown export as a variable reference for the team. Use JSON or CSV to integrate the schema into a backlog or ticket generation tool.
Why This Works
- {{acceptanceCriteria}} and {{criteria}}, or {{definitionOfDone}} and {{dod}}, are the naming pairs most likely to appear across different team copies of the same story template — consolidating them before the template is shared prevents substitution mismatches in backlog tools
- Acceptance criteria is the variable most often left unformatted — a description field that specifies the expected format (plain text vs. Given/When/Then) prevents inconsistent outputs
- A shared variable schema means a product manager and a developer filling in the same template will produce compatible inputs
Best for
- Product teams with a shared story template library that multiple team members use
- Story templates fed into automated backlog or project management tools
- Teams where acceptance criteria format needs to be consistent across all stories in a sprint
Not for
- One-off stories written directly in a ticket tool without a reusable template
- Teams where story format is intentionally flexible and varies by feature type
Use cases
- Standardising the variable names in user story templates shared across a product team — catching {{acceptanceCriteria}} and {{criteria}}, or {{definitionOfDone}} and {{dod}}, before they diverge
- Documenting what each placeholder expects before integrating story templates into a backlog automation tool
- Generating a TypeScript interface for a story prompt used in a typed ticket generation script
- Exporting a variable CSV to align product and engineering teams on story format before a sprint
FAQ
Why does the builder flag {{acceptanceCriteria}} and {{criteria}} as a duplicate in my user story template?
It flags them because the similarity check compares your variable names and finds {{acceptanceCriteria}} and {{criteria}} too close to be separate fields. It marks the pair; it does not merge them for you. Rename one form in the tool so a backlog automation substitutes into a single field instead of splitting the same value across two named placeholders.
How should I set the type for the {{priority}} variable in this story template?
Set {{priority}} to a list type and enter the allowed values High, Medium, and Low, so anyone filling this story template picks from a fixed set instead of typing free text. The type lands in the JSON or CSV export as schema; the tool records it but does not force the value when you later run the filled prompt in ChatGPT, Claude, or Gemini.
Can I generate a TypeScript interface from this story template for a ticket generation script?
Set every variable's type in the builder, then use the JSON or TypeScript export, which turns the nine placeholders like {{persona}}, {{acceptanceCriteria}}, and {{priority}} into a typed interface for your ticket generation script. The tool emits the interface from the schema; wiring it into the script and running it stays on your side.
More resources from Prompt Variable Builder
Resource
Landing Page Variable Builder
Cleans up variables in landing page prompt templates — headline, audience, pain point, offer, social proof, CTA, and objections.
Resource
Candidate Evaluation Variable Builder
Documents variables in candidate evaluation prompt templates — candidate name, role, interview notes, strengths, concerns, and recommendation.
Resources that pair well
Resource
Agent Task Template
A reusable AI agent task template with variables for objective, context, available tools, constraints, success criteria, failure handling, and output format.
Resource
Agent Instruction Prompt Formatter
Formats fuzzy agent instructions into a structured prompt with objective, available tools, constraints, success criteria, and failure handling.
Related tools
Tool
Prompt Variable Builder
Turn any plain prompt into a reusable, variable-based template — auto-detect values and export.
Workflows that use this resource
Workflow
AI Product Requirements Workflow
Turn a fuzzy business need into requirements a team can build from — interrogate the need into concrete requirements, shape them as user stories, and write the PRD.
Guides for this resource
Guide
How to Turn a Feature Into User Stories With AI
A feature arrives as one line — "let users change the pickup location" — and AI splits it the two wrong ways: it restates the spec, or it hands back a task list. Here is how to turn a feature into user stories with AI: sliced by the user's path, each one shippable and checkable on its own.