Skip to main content
Hugs
You’ll build review-batch: a page that shows a company’s documents, each with its file, asks for OK or Not OK on each one with a note saying why, and takes optional evidence. A custom agent and an LLM phase both ask with it. The finished code is examples/hugs/review-batch in the cliq repo. About 30 minutes. You need cliq with cliqd, Node 22, and a team folder (team.yml). Blocks marked (abridged) are shortened for reading; the full files are in examples/hugs/review-batch.

1. Decide whether you need a hug

form can ask “Is document 1 OK? Is document 2 OK? Notes?” — but a reviewer then matches fields to files by hand, and nothing says a rejection needs a note. A hug made for the job shows each document next to its verdict, asks for a note only where one is needed, and refuses an answer without one. That’s worth a hug.

2. Scaffold it

A hug is built with @getcliqio/hug-frontend, which comes from GitHub Packages like @getcliqio/cliq-sdk. If you haven’t set that up yet (once per machine; a GitHub token with read:packages):
In the team folder:
cliq hug new writes hugs/review-batch/ (inside a team folder; elsewhere, review-batch/) and doesn’t touch team.yml:

3. Write the definition

hug.ts says what the hug is asked and what an answer is, with Zod. Both the page and the agent import it.
hugs/review-batch/hug.ts
  • values is a function of the params here: the answer needs exactly one verdict per document asked about.
  • file() makes evidence an upload slot — the person picks a file, and the answer holds a reference to it.
  • summary is the one line shown in the inbox and notifications.
  • description is for models: an LLM phase that asks with this hug is told it (step 9).
  • .describe() gives a field its label in the default read-only view.

4. Write the page

mount_hug connects to the Hub page, keeps the answer, checks it with the definition on every change and redraws. You write the editor:
hugs/review-batch/src/main.ts (abridged)
  • initial — the answer before the person does anything: every document OK.
  • submit — the Hub’s Submit button’s label.
  • edit — draws the editor; set(path, value) changes one part of the answer, and the page redraws.
  • problems — the definition’s problems by path, so “Say what is wrong with this document” appears under the note it belongs to.
  • The UI kit (<cliq-field>, <cliq-choice-group>, <cliq-file>, <cliq-attachment>) looks like the Hub, in light and dark, and is accessible. See UI kit.

5. Work on it in the browser

Make a params.json with sample params:
params.json
cliq hug dev builds the hug, shows it on cliqd’s local Hug page — no run, no Hug — and rebuilds and reloads as you edit. A side panel shows what the page sends: the values, whether they’re valid, the problems, the Submit label and the summary. Pick Not OK on a document and leave the note empty: Submit stays disabled and the note shows why.

6. See the read-only view

After someone answers, the page draws the answer read-only. mount_hug draws a default view from the definition (labels from .describe()); check it with a sample answer:
To draw your own, add view:

7. Show the documents and take evidence

The documents reach the page as attachments — run files the agent attaches when it asks (step 9). In cliq hug dev, give it a folder of files to stand in for them:
cliq hug dev gives the folder’s files the ids dev-file-0, dev-file-1, … in name order, so point the sample params at them — { "id": "lease", "name": "Lease", "artifact_id": "dev-file-0" } — and each document shows its file. <cliq-attachment> shows each file with Preview (text, markdown and images) and Download. <cliq-file key="evidence"> asks the Hub to let the person pick a file and upload it — the page itself never touches the network.

8. Test the definition

The definition is plain code: test it like any.
hugs/review-batch/hug.test.ts (abridged)
To test the page itself, mock_host from @getcliqio/hug-frontend/testing stands in for the Hub — see Testing hugs.

9. Use it

Build it, then name it in the team:
From agent code — a custom agent attaches the documents and asks by name:
agents/batch-reviewer/agent.mjs (abridged)
From a model — an LLM phase that names the hug is told its title, description and params, and asks with it when its role says to:
team.yml (abridged)
Run the team locally:
cliq run opens the Hug’s page in your browser. Answer it — then try sending Not OK without a note through cliqd’s API (answering without a browser): the agent doesn’t count it, the page shows “1 answer couldn’t be used; waiting for a valid one”, and the Hug stays open.

10. Publish it with the team

The team’s hugs travel with it — only their built dist/. cliq team publish refuses a hug whose dist/ is missing or out of date (--build builds first). Run the team on a CliqHub realm: the first Hug asked with review-batch uploads its bundle to CliqHub, and every later one with the same build sends nothing. Change the hug, rebuild, publish a new version: new Hugs use the new bundle, open ones keep theirs.

Next steps