Skills and workflows

In Zyx, how a piece of work is done is a file you can read and change, not code. Code holds only the mechanisms.

Skills

A skill is a folder with a SKILL.md file, and optionally scripts/ and references/. Its head follows the open Agent Skills format: name, description and a few optional fields, with Zyx’s own keys under metadata.

• Library skills ship with Zyx: more than 180 today, from mail triage and a morning brief to supplier invoices and website checks. They hold placeholders only, never client data. A pack installs the skills of one department in one go.
• Company skills live in the company folder: a filled-in copy of a library skill, or a process only that company has.
• Signed. The library ships signed. An imported skill with no valid signature, or a skill whose bytes changed after signing, runs with no automatic approvals: every change is a card.
• Declared permissions. A skill may list the tools, folders and hosts it needs. While it runs, any call outside that list waits for a person.
• A free text check. A skill may carry pattern rules that run on every mail, app write or push before it leaves, with no model and no tokens. On a hit the model gets the hints once and rewrites.

Workflows: a skill with typed steps

Each line under ## Steps can say who does it:

Tag	Who does it	Cost
[script: name.sh]	a script in the skill’s folder, run in the sandbox; gets the previous step’s output	zero tokens
[light], [deep], or no tag	an AI step on a cheap or a strong model	tokens
[decide: a, b]	one small call picks a label from the list	one small call
[human]	the job stops and waits for a person	zero tokens

An example:

---
name: invoice-check
description: Fetch new invoices, flag the odd ones, ask the owner about big ones.
---
# Invoice check

## Steps
1. Fetch new invoices from the inbox folder. [script: fetch.sh]
2. Flag invoices that look wrong and say why. [light]
3. Anything over 5,000 EUR: the owner decides. [human]
4. File the rest into Accounting/. [script: file.sh]

Scripts are pinned by their SHA-256 hash when the job is approved. A changed script does not run until it is approved again. A script that prints nothing means “nothing to do”: the job ends quietly.

Jobs

Bigger work becomes a job: a plan with an outcome, numbered steps and checks, on one card. After approval it runs step by step. Each AI step runs on the cheapest model that can do it; a failed step retries with more effort, then one level up. A restart loses nothing: a job is rebuilt from the event log.

Schedules and triggers

A routine says when a skill runs.

• On a clock: hourly, daily, weekly, an interval like 30m or 6h, or a cron line.
• On an event: a new mail in a mailbox, a new file in a folder, a new file in any Inbox/ folder at or below the routine’s folder (Your Inbox), a webhook from another system, or a merged pull request.

Rules that keep this safe:

• A routine runs on its own only after the owner agreed on a warning screen. Any edit asks again.
• A routine started by an event (a mail, a webhook) always stops at approval cards. A stranger’s mail cannot steer a routine that runs alone.
• A routine sees only its own folder. A scheduled run asks at most one question.
• Each event runs once, in its own chat. At most three jobs per trigger run at a time; the rest wait.
• Incoming data is untrusted and passes the privacy gate. A payload that carries a key is refused.
• A webhook can be checked with an HMAC signature (GitHub, Stripe, Standard Webhooks).
• The routine pins its skill’s hash. A changed skill stops the routine until the owner saves it again.

Zyx gets cheaper over time

Every step is measured. When a step always succeeds, Zyx tries a cheaper model on a sample, and when an AI step is simple enough, it proposes turning it into a script. It only proposes; the owner decides.