Templates System

This document explains how templates work in Xema Workflows, including prompt templates, deliverable specs, and customization.

Table of Contents

  1. Overview
  2. Template Types
  3. Prompt Templates
  4. Deliverable Specs
  5. Template Rendering
  6. Handlebars Syntax
  7. Customization
  8. 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

text
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 specifications
  • agents-md.gate-reviewer — Review phase outputs
  • agents-md.clarification-coordinator — Handle clarifications
  • agents-md.interactive — Interactive session guide

Example:

markdown
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:

text
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:

markdown
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:

json
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:

KeyPurposeUsed When
agents-md.builderCreate deliverablesAgent builds specs/plans
agents-md.gate-reviewerReview phase outputsGate review (automated)
agents-md.clarification-coordinatorHandle clarificationsClarification phase
agents-md.scope-validatorValidate scopeScope validation
agents-md.interactiveInteractive sessionChat/collaboration

Template Context

When rendering a template, provide context:

typescript
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

yaml
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 Corp

Deliverable 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 specifications
  • architecture-* — Architecture design
  • delivery-plan-* — Implementation roadmap
  • governance-* — Quality & compliance
  • implementation-* — Development report

Selecting a Template

In workflow:

yaml
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

  1. Overview — High-level summary
  2. Functional Requirements — What the system does
  3. Non-Functional Requirements — Performance, security, etc.
  4. Dependencies — External systems
  5. Success Criteria — How to measure success
  6. Assumptions — Underlying assumptions
  7. Constraints — Limitations and boundaries

Architecture Spec Sections

  1. System Overview — Big picture
  2. Architecture Layers — Component organization
  3. Technology Stack — Tools and frameworks
  4. Data Model — Entity relationships
  5. Integration Points — External systems
  6. Security Architecture — Security design
  7. Scalability Plan — Growth considerations

Template Rendering

Handlebars Syntax

Templates use Handlebars for dynamic content:

handlebars
1{{variable}}              → Substitute variable
2
3{{#if condition}}         → Conditional block
4  Content
5{{/if}}
6
7{{#unless condition}}     → Negation
8  Content
9{{/unless}}
10
11{{#each array}}           → Loop over array
12  Item: {{this}}
13{{/each}}
14
15{{#with object}}          → Change context
16  {{property}}
17{{/with}}
18
19{{../parent.value}}       → Access parent context
20
21{{variable | uppercase}}  → Helper functions

Common Helpers

Built-in Helpers

  • if — Conditional rendering
  • each — Loop iteration
  • with — Context change
  • unless — Negation

Custom Helpers

Available custom helpers:

handlebars
1{{and condition1 condition2}}      → Logical AND
2{{cond condition yes no}}          → Ternary operator
3{{includes array item}}            → Array membership
4{{equals a b}}                     → Equality check

Template Examples

Example 1: Conditional Sections

handlebars
1# Requirements Specification
2
3{{#if includeExecutiveSummary}}
4## Executive Summary
5{{executiveSummary}}
6{{/if}}
7
8{{#each requirements}}
9### {{this.id}}: {{this.title}}
10Priority: {{this.priority}}
11{{#if this.optional}}
12*This is an optional requirement*
13{{/if}}
14{{/each}}

Example 2: Nested Loops

handlebars
1# Architecture Design
2
3{{#each architectureLayers}}
4## {{this.name}}
5
6{{#each this.components}}
7### {{this.componentName}}
8- Technology: {{this.technology}}
9- Responsibility: {{this.responsibility}}
10
11{{#if this.dependencies}}
12**Dependencies:**
13{{#each this.dependencies}}
14- {{this}}
15{{/each}}
16{{/if}}
17
18{{/each}}
19
20{{/each}}

Example 3: Context Switching

handlebars
1# Project Details
2
3{{#with project}}
4**Name**: {{name}}
5**Owner**: {{owner}}
6
7## Team Members
8
9{{#each team}}
10- {{this.name}} ({{this.role}})
11{{/each}}
12
13{{/with}}

Customization

Creating Custom Templates

Define custom templates for your organization:

markdown
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:

yaml
1metadata:
2  name: requirements-spec
3  version: 2.1.0
4  lastUpdated: 2026-04-27
5  author: platform-team

Changes are tracked; old versions remain available.

Template Localization

Support multiple languages:

text
1specs/
2├── en/
3│   ├── requirements-enterprise/
4│   └── ...
5├── es/
6│   ├── requirements-enterprise/
7│   └── ...
8└── fr/
9    └── ...

Select language at render time:

yaml
1with:
2  template: requirements-enterprise
3  language: ${{ inputs.language }}

Registry & Discovery

Template Registry

The Template Registry is a centralized catalog:

typescript
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:

bash
1curl https://deliverable-specs-api.xema.dev/deliverable-specs \
2  -H "Authorization: Bearer $TOKEN"

Response:

json
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

bash
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:

handlebars
1{{projectName}}
2{{functionalRequirements}}

Bad:

handlebars
1{{pn}}
2{{fr}}

2. Provide Defaults

handlebars
1{{projectName | default "Untitled Project"}}
2{{preparedBy | default "Unknown"}}

3. Document Required Fields

In template header:

handlebars
1<!-- REQUIRED FIELDS:
2  - projectName: string
3  - functionalRequirements: array
4  - budget: number
5  - timeline: string
6-->

4. Use Semantic Structure

handlebars
1# Heading 1 (Use once per document)
2## Heading 2 (Main sections)
3### Heading 3 (Subsections)
4
5**Bold** for emphasis
6*Italic* for references

5. Handle Optional Sections

handlebars
1{{#if includeOptionalSection}}
2## Optional Section
3{{optionalContent}}
4{{/if}}

6. Escape Special Characters

handlebars
1<!-- For literal braces, use HTML entities -->
2{{variable}}
3
4<!-- For ampersands in content -->
5&amp; instead of &

Examples

Example 1: Requirements Spec Template (Enterprise)

handlebars
1# {{projectName}} Requirements Specification
2
3**Version**: {{version}}  
4**Date**: {{date}}  
5**Prepared By**: {{preparedBy}}  
6
7## Overview
8
9{{overview}}
10
11### Business Objectives
12{{#each businessObjectives}}
131. {{this}}
14{{/each}}
15
16### Key Stakeholders
17{{#each stakeholders}}
18- {{this.name}} ({{this.role}})
19{{/each}}
20
21## Functional Requirements
22
23{{#each functionalRequirements}}
24### FR-{{this.id}}: {{this.title}}
25
26**Priority**: {{this.priority}}  
27**Complexity**: {{this.complexity}}  
28**Estimated Effort**: {{this.estimatedDays}} days
29
30**Description**:  
31{{this.description}}
32
33**Acceptance Criteria**:
34{{#each this.acceptanceCriteria}}
35- [ ] {{this}}
36{{/each}}
37
38{{#if this.dependencies}}
39**Dependencies**: {{#each this.dependencies}}{{this}}{{#unless @last}}, {{/unless}}{{/each}}
40{{/if}}
41
42{{/each}}
43
44## Non-Functional Requirements
45
46### Performance
47{{nfr.performance}}
48
49### Security
50{{nfr.security}}
51
52### Scalability
53{{nfr.scalability}}
54
55### Usability
56{{nfr.usability}}
57
58## Constraints & Assumptions
59
60**Constraints**:
61{{#each constraints}}
62- {{this}}
63{{/each}}
64
65**Assumptions**:
66{{#each assumptions}}
67- {{this}}
68{{/each}}
69
70## Success Criteria
71
72{{successCriteria}}
73
74---
75**Approved By**: {{approver}}  
76**Approval Date**: {{approvalDate}}

Example 2: Agent Prompt Template

handlebars
1# Role: {{role | capitalize}}
2
3You are a {{role}} for the {{organization}} project.
4
5## Context
6- **Project**: {{projectName}}
7- **Phase**: {{phase | capitalize}}
8- **Complexity**: {{complexity}}
9- **Timeline**: {{timeline}}
10
11## Task
12
13{{task}}
14
15## Guidelines
16
17{{#each guidelines}}
18- {{this}}
19{{/each}}
20
21## Standards & Best Practices
22
23{{#each standards}}
24### {{@index | plus 1}}. {{this.name}}
25{{this.description}}
26
27{{#each this.practices}}
28- {{this}}
29{{/each}}
30
31{{/each}}
32
33## Success Criteria
34
35Your output will be evaluated on:
361. {{successCriteria.first}}
372. {{successCriteria.second}}
383. {{successCriteria.third}}
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{{#if hasRetryContext}}
51**Note**: This is a retry. Consider the previous feedback:
52{{retryFeedback}}
53{{/if}}

Next: Read API Reference for REST endpoints.