T1 starter · e-commerce / personal: no infer: anywhere in this
file. A workflow engine is not an LLM wrapper: the DAG, the tools and
one CEL comparison do the whole job, deterministically, for free.
The job
You’re waiting for a price to drop. Checking the page every day is a robot’s job. This workflow pulls one structured field from the shop’s API, compares it to your target, and pings your webhook only when it’s time to buy.The shape
The file
price-watch.nika.yaml
How it works
1
Fetch ONE field, not a page
mode: jq extracts structured JSON from the API response, and the
output: block binds named fields: ${{ tasks.check.price }} is a
number, not a blob of HTML.2
CEL gates the alert
The named binding crosses in
with:
(price: ${{ tasks.check.price }}), then
when: ${{ with.price < config.alert_below }} is a plain CEL
comparison. False → the task is skipped, not failed.3
The webhook stays secret
secrets: declares a vault/env-backed reference. The URL is masked
in logs: ${{ secrets.alerts_webhook }} never appears in a trace.Constructs you just used
Make it yours
- Watch N products: lift the URL into a list input and
for_eachover it. See Competitor radar for the fan-out pattern. - Schedule it: workflow files describe a run. Your host’s cron (or
nika serve) decides when runs start. - Add a second
when:branch that notifies on price INCREASES above a ceiling.
Next · Social repurpose
The last starter introduces the diamond: one source fanning into
three parallel rewrites.