Templates System
This document explains how templates work in Xema Workflows, including prompt templates, deliverable specs, and customization.
Table of Contents
- Overview
- Template Types
- Prompt Templates
- Deliverable Specs
- Template Rendering
- Handlebars Syntax
- Customization
- Registry & Discovery
Overview
What Are Templates?
Templates are reusable specifications that standardize how workflows generate deliverables:
- Consistency — Same structure across projects
- Customization — Adapt content to context
- Reusability — Share templates across teams
- Maintainability — Update once, everywhere updates
Template Layers
1User Input / Trigger
2 ↓
3Template Selection
4 ↓
5Context Binding
6 ↓
7Template Rendering (Handlebars)
8 ↓
9Final Output (Spec, Report, etc.)Template Types
1. Prompt Templates
System prompts that guide LLM agents:
Purpose: Provide role-specific instructions for agents
Format: Markdown with embedded logic
Rendering: Handlebars templating
Used by: Agent invocation jobs
Key Templates:
agents-md.builder— Create specificationsagents-md.gate-reviewer— Review phase outputsagents-md.clarification-coordinator— Handle clarificationsagents-md.interactive— Interactive session guide
Example:
1# Role: Requirements Analyst
2
3You are {{role}} for the {{organization}} project.
4
5## Your Task
6Analyze the following {{domain}} and create a detailed specification:
7
8{{requirements}}
9
10## Standards to Follow
11{{#each standards}}
12- {{this.name}}: {{this.description}}
13{{/each}}
14
15## Context
16- Project Name: {{projectName}}
17- Budget: ${{budget}}
18- Timeline: {{timeline}}2. Deliverable Specs Templates
Structured templates for deliverables (specifications, reports, plans):
Purpose: Standard document structure
Format: Markdown with sections and placeholders
Rendering: Handlebars + embedded logic
Used by: Phase workflows
Examples:
- Requirements specification
- Architecture design document
- Delivery plan
- Governance report
- Implementation report
Structure:
1specs/
2├── enterprise/
3│ ├── requirements-enterprise/
4│ │ ├── content.md # Main template
5│ │ └── pages/
6│ │ ├── overview.md
7│ │ ├── requirements.md
8│ │ └── acceptance.md
9│ ├── architecture-enterprise/
10│ └── ...
11├── complex/
12│ ├── requirements-complex/
13│ └── ...
14└── simple/
15 └── ...Example Spec:
1# {{projectName}} Requirements Specification
2
3## Overview
4{{overview}}
5
6## Functional Requirements
7{{#each functionalRequirements}}
8### {{this.id}} - {{this.title}}
9**Priority**: {{this.priority}}
10**Description**: {{this.description}}
11**Acceptance Criteria**:
12{{#each this.acceptanceCriteria}}
13- {{this}}
14{{/each}}
15{{/each}}
16
17## Non-Functional Requirements
18{{nfr_reliability}}
19{{nfr_performance}}
20{{nfr_security}}
21
22## Dependencies
23{{#each dependencies}}
24- {{this}}
25{{/each}}
26
27## Success Criteria
28{{successCriteria}}
29
30---
31**Prepared by**: {{preparedBy}}
32**Date**: {{date}}
33**Version**: {{version}}3. Session Templates
Reusable session configurations:
Purpose: Standard session setup
Format: JSON configuration
Used by: Interactive session jobs
Example:
1{
2 "name": "requirements-gathering",
3 "type": "interactive",
4 "tools": [
5 "code-editor",
6 "browser",
7 "diagrams",
8 "notes"
9 ],
10 "participants": ["user"],
11 "context": {
12 "role": "requirements-engineer",
13 "phase": "requirements"
14 }
15}Prompt Templates
Template Keys (Enum)
Available system prompt templates:
| Key | Purpose | Used When |
|---|---|---|
agents-md.builder | Create deliverables | Agent builds specs/plans |
agents-md.gate-reviewer | Review phase outputs | Gate review (automated) |
agents-md.clarification-coordinator | Handle clarifications | Clarification phase |
agents-md.scope-validator | Validate scope | Scope validation |
agents-md.interactive | Interactive session | Chat/collaboration |
Template Context
When rendering a template, provide context:
1interface PromptContext {
2 role: string // Agent role (e.g. unit-worker, coordinator, gate-reviewer)
3 phase: string // Current phase (requirements, architecture, etc.)
4 spec: {
5 title: string
6 standards: string[] // e.g., ["ISO/IEC 25010", "TOGAF"]
7 guidelines: string
8 }
9 projectName: string
10 organization: string
11 hasRetryContext: boolean // Has this been retried?
12 retryFeedback?: string // Feedback from previous attempt
13 domain: string // Domain (backend, frontend, data, etc.)
14}Rendering Example
1jobs:
2 build-spec:
3 uses: xema/agent
4 with:
5 task: Build comprehensive requirements specification
6 systemPrompt: ${{ templates.render('agents-md.builder', context) }}
7 context:
8 role: requirements-analyst
9 phase: requirements
10 spec:
11 title: Enterprise Requirements
12 standards: [ISO/IEC 25010, MoSCoW]
13 projectName: Acme Portal
14 organization: Acme CorpDeliverable Specs
Spec Categories
Specs vary by complexity and type:
Complexity Levels
- simple — Minimal structure, quick generation
- complex — Full sections, comprehensive coverage
- enterprise — Complete with governance, security, compliance
Types
requirements-*— Requirement specificationsarchitecture-*— Architecture designdelivery-plan-*— Implementation roadmapgovernance-*— Quality & complianceimplementation-*— Development report
Selecting a Template
In workflow:
1jobs:
2 create-requirements:
3 uses: xema/agent
4 with:
5 template: requirements-enterprise # Select template
6 task: Create detailed requirements
7 context: ${{ inputs.scope }}Template Sections
Deliverable specs include standard sections:
Requirements Spec Sections
- Overview — High-level summary
- Functional Requirements — What the system does
- Non-Functional Requirements — Performance, security, etc.
- Dependencies — External systems
- Success Criteria — How to measure success
- Assumptions — Underlying assumptions
- Constraints — Limitations and boundaries
Architecture Spec Sections
- System Overview — Big picture
- Architecture Layers — Component organization
- Technology Stack — Tools and frameworks
- Data Model — Entity relationships
- Integration Points — External systems
- Security Architecture — Security design
- Scalability Plan — Growth considerations
Template Rendering
Handlebars Syntax
Templates use Handlebars for dynamic content:
1 → Substitute variable
2
3 → Conditional block
4 Content
5
6
7 → Negation
8 Content
9
10
11 → Loop over array
12 Item:
13
14
15 → Change context
16
17
18
19 → Access parent context
20
21 → Helper functionsCommon Helpers
Built-in Helpers
if— Conditional renderingeach— Loop iterationwith— Context changeunless— Negation
Custom Helpers
Available custom helpers:
1 → Logical AND
2 → Ternary operator
3 → Array membership
4 → Equality checkTemplate Examples
Example 1: Conditional Sections
1# Requirements Specification
2
3
4## Executive Summary
5
6
7
8
9### :
10Priority:
11
12*This is an optional requirement*
13
14Example 2: Nested Loops
1# Architecture Design
2
3
4##
5
6
7###
8- Technology:
9- Responsibility:
10
11
12**Dependencies:**
13
14-
15
16
17
18
19
20Example 3: Context Switching
1# Project Details
2
3
4**Name**:
5**Owner**:
6
7## Team Members
8
9
10- ()
11
12
13Customization
Creating Custom Templates
Define custom templates for your organization:
1# Custom Template: Acme Requirements Spec
2
3## Project Information
4- Name: {{projectName}}
5- Organization: {{organization}}
6- Budget: ${{budget}}
7
8## Requirements by Category
9
10{{#each requirementsByCategory}}
11### {{@key | capitalize}}
12
13{{#each this}}
141. **{{id}}** - {{title}}
15 - Priority: {{priority}}
16 - Effort: {{estimatedDays}} days
17 - Owner: {{owner}}
18{{/each}}
19
20{{/each}}
21
22## Quality Standards
23- All requirements must be SMART (Specific, Measurable, Achievable, Relevant, Time-bound)
24- All must have acceptance criteria
25- All must be traceable to business goals
26
27---
28**Prepared by**: {{preparedBy}}
29**Date**: {{date}}
30**Status**: {{status}}Template Versioning
Templates are versioned:
1metadata:
2 name: requirements-spec
3 version: 2.1.0
4 lastUpdated: 2026-04-27
5 author: platform-teamChanges are tracked; old versions remain available.
Template Localization
Support multiple languages:
1specs/
2├── en/
3│ ├── requirements-enterprise/
4│ └── ...
5├── es/
6│ ├── requirements-enterprise/
7│ └── ...
8└── fr/
9 └── ...Select language at render time:
1with:
2 template: requirements-enterprise
3 language: ${{ inputs.language }}Registry & Discovery
Template Registry
The Template Registry is a centralized catalog:
1class TemplateRegistry {
2 register(entry: TemplateEntry): void
3 require(key: string): TemplateEntry // Fail if missing
4 get(key: string): TemplateEntry | undefined
5 has(key: string): boolean
6 list(): readonly TemplateEntry[]
7}Discovering Available Templates
List available templates:
1curl https://deliverable-specs-api.xema.dev/deliverable-specs \
2 -H "Authorization: Bearer $TOKEN"Response:
1{
2 "templates": [
3 {
4 "key": "agents-md.builder",
5 "name": "Agent Builder Prompt",
6 "type": "prompt",
7 "description": "System prompt for builder agents"
8 },
9 {
10 "key": "requirements-enterprise",
11 "name": "Enterprise Requirements Spec",
12 "type": "deliverable",
13 "complexity": "enterprise",
14 "description": "Full requirements specification for enterprise projects"
15 }
16 ]
17}Searching Templates
1curl https://deliverable-specs-api.xema.dev/deliverable-specs \
2 ?type=deliverable \
3 ?complexity=enterprise \
4 -H "Authorization: Bearer $TOKEN"Template Best Practices
1. Use Clear Variable Names
Good:
1
2Bad:
1
22. Provide Defaults
1
23. Document Required Fields
In template header:
1<!-- REQUIRED FIELDS:
2 - projectName: string
3 - functionalRequirements: array
4 - budget: number
5 - timeline: string
6-->4. Use Semantic Structure
1# Heading 1 (Use once per document)
2## Heading 2 (Main sections)
3### Heading 3 (Subsections)
4
5**Bold** for emphasis
6*Italic* for references5. Handle Optional Sections
1
2## Optional Section
3
46. Escape Special Characters
1<!-- For literal braces, use HTML entities -->
2
3
4<!-- For ampersands in content -->
5& instead of &Examples
Example 1: Requirements Spec Template (Enterprise)
1# Requirements Specification
2
3**Version**:
4**Date**:
5**Prepared By**:
6
7## Overview
8
9
10
11### Business Objectives
12
131.
14
15
16### Key Stakeholders
17
18- ()
19
20
21## Functional Requirements
22
23
24### FR-:
25
26**Priority**:
27**Complexity**:
28**Estimated Effort**: days
29
30**Description**:
31
32
33**Acceptance Criteria**:
34
35- [ ]
36
37
38
39**Dependencies**: ,
40
41
42
43
44## Non-Functional Requirements
45
46### Performance
47
48
49### Security
50
51
52### Scalability
53
54
55### Usability
56
57
58## Constraints & Assumptions
59
60**Constraints**:
61
62-
63
64
65**Assumptions**:
66
67-
68
69
70## Success Criteria
71
72
73
74---
75**Approved By**:
76**Approval Date**: Example 2: Agent Prompt Template
1# Role:
2
3You are a for the project.
4
5## Context
6- **Project**:
7- **Phase**:
8- **Complexity**:
9- **Timeline**:
10
11## Task
12
13
14
15## Guidelines
16
17
18-
19
20
21## Standards & Best Practices
22
23
24### .
25
26
27
28-
29
30
31
32
33## Success Criteria
34
35Your output will be evaluated on:
361.
372.
383.
39
40## Format
41
42Please structure your response as follows:
43- Use clear headings (##, ###, ####)
44- Use bullet points for lists
45- Use code blocks for technical content
46- Use tables for structured data
47- Include explanations for all recommendations
48
49---
50
51**Note**: This is a retry. Consider the previous feedback:
52
53Next: Read API Reference for REST endpoints.