Clix Personalization
Use this skill to help developers write personalized Clix campaigns using
template-based variables and light logic in:
- Message content (title, body, subtitle)
- Links (dynamic URL or deep link params)
- Audience targeting (conditional include/exclude rules)
What the official docs guarantee (high-signal)
- Data namespaces:
user.* (user traits/properties)
event.* (event payload properties)
trigger.* (custom properties passed via API-trigger)
- Device/system vars:
device.id, device.platform, device.locale,
device.language, device.timezone, plus user.id, event.name
- Missing variables render as an empty string.
- Output: print values with
{{ ... }}.
- Conditionals:
{% if %}, {% else %}, {% endif %} with operators
== != > < >= <= and or not. Invalid conditions evaluate to false.
- Loops:
{% for x in y %} / {% endfor %} (use guards for empty lists).
- Filters:
upcase, downcase, capitalize, default, join, split,
escape, strip, replace (chain with |).
- Errors: template rendering errors show up in Message Logs.
MCP-first (source of truth)
If the Clix MCP tools are available, treat them as the source of truth:
clix-mcp-server:search_docs for personalization behavior and supported
syntax
If MCP tools are not available, use the bundled references in references/.
Workflow (copy + check off)
Personalization progress:
- [ ] 1) Identify where the template runs (message / URL / audience rule)
- [ ] 2) Identify trigger type (event-triggered vs API-triggered)
- [ ] 3) Confirm available inputs (user.*, event.*, trigger.*, device.*)
- [ ] 4) Draft templates with guards/defaults
- [ ] 5) Validate template structure (balance tags, avoid missing vars)
- [ ] 6) Verify in Clix (preview/test payloads, check Message Logs)
1) Confirm the minimum inputs
Ask only what’s needed:
- Where used: title/body/subtitle vs URL/deep link vs audience targeting
rule
- Campaign trigger:
- Event-triggered →
event.* is available
- API-triggered →
trigger.* is available
- Inputs:
- Which
user.* properties are set by the app
- Which
event.* / trigger.* properties are passed (include example
payload)
- Fallback policy: what to show when data is missing (default strings,
guards)
2) Produce a “Template Plan” (before tweaking lots of templates)
Return a compact table the user can approve:
- field (title/body/url/audience)
- template (Liquid)
- required variables (and their source: user/event/trigger/device)
- fallbacks (default filter and/or conditional guards)
- example payload + expected rendered output
3) Authoring guidelines (what to do by default)
- Prefer simple variables +
default over complex branching.
- Add guards for optional data and for arrays (
size > 0) before looping.
- Prefer pre-formatted properties from your app (e.g.,
"7.4 miles",
"38m 40s") instead of formatting inside templates.
- Keep logic minimal; complex branching belongs in the app or segmentation
setup.
4) Validation (fast feedback loop)
If you have a template file (recommended for review), run:
bash <skill-dir>/scripts/validate-template.sh path/to/template.liquid
This script does lightweight checks (matching {% if %}/{% endif %},
{% for %}/{% endfor %}, and brace balancing). It can’t guarantee the
variables exist — you still need a payload + console verification.
5) Verification checklist
- Missing data: does the template still read well with empty strings?
- Trigger type: API triggers use
trigger.* (not event.*).
- Message Logs: check rendering errors and fix syntax issues first.
- Upstream data:
- If
user.* is missing → fix user property setting (see
clix-user-management)
- If
event.* is missing → fix event tracking payload (see
clix-event-tracking)
Progressive Disclosure
- Level 1: This
SKILL.md (always loaded)
- Level 2:
references/ (load when writing/debugging templates)
- Level 3:
scripts/ (execute directly, do not load into context)
References
references/template-syntax.md - Variables, output, conditionals, loops,
filters
references/common-patterns.md - Copy/paste patterns for messages + URLs +
guards
references/debugging.md - Troubleshooting missing variables and Message Logs
1---2name: clix-personalization3description: Helps developers author and debug Clix personalization templates (Liquid-style) for message content, deep links/URLs, and audience targeting. Use when the user mentions personalization variables, Liquid, templates, conditional logic, loops, filters, deep links, message logs, or when the user types `clix-personalization`.4---5
6# Clix Personalization
7
8Use this skill to help developers write **personalized Clix campaigns** using
9template-based variables and light logic in:
10
11- **Message content** (title, body, subtitle)
12- **Links** (dynamic URL or deep link params)
13- **Audience targeting** (conditional include/exclude rules)
14
15## What the official docs guarantee (high-signal)
16
17- **Data namespaces**:
18 - `user.*` (user traits/properties)
19 - `event.*` (event payload properties)
20 - `trigger.*` (custom properties passed via API-trigger)
21 - Device/system vars: `device.id`, `device.platform`, `device.locale`,
22 `device.language`, `device.timezone`, plus `user.id`, `event.name`
23- **Missing variables** render as an **empty string**.
24- **Output**: print values with `{{ ... }}`.
25- **Conditionals**: `{% if %}`, `{% else %}`, `{% endif %}` with operators
26 `== != > < >= <= and or not`. Invalid conditions evaluate to `false`.
27- **Loops**: `{% for x in y %}` / `{% endfor %}` (use guards for empty lists).
28- **Filters**: `upcase`, `downcase`, `capitalize`, `default`, `join`, `split`,
29 `escape`, `strip`, `replace` (chain with `|`).
30- **Errors**: template rendering errors show up in **Message Logs**.
31
32## MCP-first (source of truth)
33
34If the Clix MCP tools are available, treat them as the source of truth:
35
36- `clix-mcp-server:search_docs` for personalization behavior and supported
37 syntax
38
39If MCP tools are not available, use the bundled references in `references/`.
40
41## Workflow (copy + check off)
42
43```
44Personalization progress:
45- [ ] 1) Identify where the template runs (message / URL / audience rule)
46- [ ] 2) Identify trigger type (event-triggered vs API-triggered)
47- [ ] 3) Confirm available inputs (user.*, event.*, trigger.*, device.*)
48- [ ] 4) Draft templates with guards/defaults
49- [ ] 5) Validate template structure (balance tags, avoid missing vars)
50- [ ] 6) Verify in Clix (preview/test payloads, check Message Logs)
51```
52
53## 1) Confirm the minimum inputs
54
55Ask only what’s needed:
56
57- **Where used**: title/body/subtitle vs URL/deep link vs audience targeting
58 rule
59- **Campaign trigger**:
60 - Event-triggered → `event.*` is available
61 - API-triggered → `trigger.*` is available
62- **Inputs**:
63 - Which `user.*` properties are set by the app
64 - Which `event.*` / `trigger.*` properties are passed (include example
65 payload)
66- **Fallback policy**: what to show when data is missing (default strings,
67 guards)
68
69## 2) Produce a “Template Plan” (before tweaking lots of templates)
70
71Return a compact table the user can approve:
72
73- **field** (title/body/url/audience)
74- **template** (Liquid)
75- **required variables** (and their source: user/event/trigger/device)
76- **fallbacks** (default filter and/or conditional guards)
77- **example payload** + **expected rendered output**
78
79## 3) Authoring guidelines (what to do by default)
80
81- Prefer **simple variables + `default`** over complex branching.
82- Add **guards** for optional data and for arrays (`size > 0`) before looping.
83- Prefer **pre-formatted** properties from your app (e.g., `"7.4 miles"`,
84 `"38m 40s"`) instead of formatting inside templates.
85- Keep logic minimal; complex branching belongs in the app or segmentation
86 setup.
87
88## 4) Validation (fast feedback loop)
89
90If you have a template file (recommended for review), run:
91
92```bash
93bash <skill-dir>/scripts/validate-template.sh path/to/template.liquid
94```
95
96This script does lightweight checks (matching `{% if %}`/`{% endif %}`,
97`{% for %}`/`{% endfor %}`, and brace balancing). It can’t guarantee the
98variables exist — you still need a payload + console verification.
99
100## 5) Verification checklist
101
102- **Missing data**: does the template still read well with empty strings?
103- **Trigger type**: API triggers use `trigger.*` (not `event.*`).
104- **Message Logs**: check rendering errors and fix syntax issues first.
105- **Upstream data**:
106 - If `user.*` is missing → fix user property setting (see
107 `clix-user-management`)
108 - If `event.*` is missing → fix event tracking payload (see
109 `clix-event-tracking`)
110
111## Progressive Disclosure
112
113- **Level 1**: This `SKILL.md` (always loaded)
114- **Level 2**: `references/` (load when writing/debugging templates)
115- **Level 3**: `scripts/` (execute directly, do not load into context)
116
117## References
118
119- `references/template-syntax.md` - Variables, output, conditionals, loops,
120 filters
121- `references/common-patterns.md` - Copy/paste patterns for messages + URLs +
122 guards
123- `references/debugging.md` - Troubleshooting missing variables and Message Logs