Workflow templates

The curated starter catalog: real workflows you can instantiate in one click instead of authoring from scratch. Each entry is a complete, compiler-valid definition with a handful of parameters — the author-time literals only you can supply (a repo, a schedule, a webhook URL) — rendered as a form. Fill in the form on the platform hub's Workflows page and the workflow is live.

Templates are also the fastest way to learn the format: instantiate one, then read and edit its YAML. The YAML reference explains every construct they use. Triggers that listen to a provider (github, gmail, …) need that provider connected on the hub first.

Code Review

PR Review

The starter everyone installs first: every newly opened pull request gets a structured review from a code-review agent — the PR head is cloned into a sandbox, the agent reads the diff and surrounding context, and the finished review is posted back as a PR review comment. One trigger, two steps, no parameters: the cleanest example of provider_event → agent.run with source → integration.invoke.

PR review panel

The multi-perspective upgrade: each opened PR is reviewed by three specialists — security, correctness, and performance — fanning out in parallel through the graph (needs), then a synthesizer merges their verdicts into one review that is posted to the PR. Use it when a single reviewer misses whole categories of issues, and as the reference shape for DAG fan-out/join.

Review via sub-workflow

Composability in one lesson: a webhook-triggered parent workflow hands the review to a separate child workflow (workflow.run) and parks until the child finishes, then posts the verdict. Use it when the review logic has its own lifecycle — reused by several repos, versioned independently, or maintained by another team. Parameters: the review workflow's id, and the webhook URL to post the verdict to.

Triage

Issue Triage

Every newly opened GitHub issue is read by an agent granted hub access (connections: [github]), which triages it and posts a concise assessment back as a comment — the canonical read-decide-act-in-one-step pattern, where the agent itself calls hub actions from inside its sandbox. No parameters; needs a connected GitHub account.

Inbound email support

Point your mail provider's inbound webhook (or relay) at the workflow's hook URL: each inbound support email is triaged, a reply is drafted — and a human gate (decision) holds the run until someone approves, so no customer ever gets an unreviewed machine reply. The reference for on: webhook + decision + guarded send.

Outbound call (ph0ny)

For each lead posted to the workflow's hook, place a consented outbound ph0ny voice call, then park the run (wait.event) until the call-complete callback arrives, and post the follow-up with the outcome. The reference for event-driven suspension: how a run waits hours for an external system and resumes exactly where it left off. Parameters: the ph0ny agent id, the caller number, and a follow-up webhook URL.

Reports

Daily quote

The smallest possible useful workflow: on a schedule, a stateless model call (topology: inference — no sandbox, no compute bill) generates a short motivational quote and posts it to a webhook. Two steps, no connections — the fastest way to see a workflow run end to end. Parameters: the cron schedule and the webhook URL.

Email security digest

A daily briefing: every morning an agent pulls the last day of security/development email, summarizes it into one digest, and posts it as a comment on a tracking GitHub issue. Use it for any "read a firehose, post a summary" job. Parameters: the cron schedule, plus the owner/repo/issue that collects the digest.

Hub ops digest

Code mode meets the hub: a script.run node granted a Gmail connection searches and invokes hub actions directly (HubClient — no per-provider HTTP to write), summarizes the last day's mail, and posts the digest to your webhook. The reference for hub codemode from a script. Parameters: the cron schedule and the webhook URL.

Multi-agent

Ralph loop

The guarded-cycle teaching example, no connections required: a drafter writes release notes, a reviewer returns VERDICT: approve or VERDICT: revise, a steering editor turns revise verdicts into notes for the next draft — looping through a guarded back-edge until approval, when the final draft is posted to your webhook. Every loop construct (needs[].when, if routing, maxNodeVisits) in 40 lines. Parameter: the publish webhook URL.

Fanout review

Multi-model comparison on a schedule: one builder drafts a report, three specialist reviewers score it in parallel, and a synthesizer merges the verdicts into a final assessment. The reference for both graph-level parallelism (needs fan-out) and reading parallel-style branch outputs. No parameters, no connections.

Trace steer loop

Self-improving agents: run an agent, feed its archived execution trace to the platform's trace analyst (trace.analyze), and steer it again whenever the analyst finds failure modes — looping until the trace comes back clean, then posting the result. The reference for traceRef wiring and quality-gated loops. Parameter: the result webhook URL.

Code-mode supervisor

A whole agentic system inside one node: post a brief to the workflow's hook URL, and a single script.run uses the bundled loop engine (loops.mjs) and sandbox SDK to fan the brief out to three sandbox workers, score their answers, and return the winner. When your orchestration logic is easier to express as code than as YAML, this is the escape hatch. No parameters.

Feature dev loop

The full autonomous-development shape: a labeled GitHub issue triggers a draft/review loop on a persistent dev sandbox (sandbox.spawn with resume: true + sandbox.snapshot, so the work survives across runs), and a human decision gates the final merge. Draft, review, steer, re-draft — with durable disk and a human at the only irreversible step. No parameters; needs a connected GitHub account.

Software factory

The full issue-to-production loop with the owner asked only by text. Add the trigger label to an issue and a System One model triages it as a typed choice with probabilities: build it (only when it picks automatable with p ≥ 0.8), write a spec first, ask the owner a question, or park it. A question or a spec goes to the owner as a coded text on a Hub line (decision with line), and a reply such as D42 approve or D42 answer only the Mac resumes the run. A build runs the implementer, then a reviewer and a verifier, each in its own fresh sandbox on the pull request head; anything short of an approve and a pass goes back to a fixer without asking anyone, and each round is posted on the pull request. Only a change that passed both reaches the owner: D42 ship merges exactly the head the verifier passed, D42 hold <note> sends the note to a fixer and asks again, and silence parks after 72 hours, never ships. After a soak period a monitor agent checks the shipped change, and a regression becomes a new labeled issue, which starts the loop again. An output the factory cannot route, or a failed step, is reported on the issue. Parameters: the trigger label, the decision model, the Hub line and owner member that receive the questions, and the soak time; needs a connected GitHub account, a line the owner has texted with REMINDERS ON, and an owner session or Line-authority key to save it.

The implementer and fixers push with source.push: true, a token that can write any branch. Protect the default branch before enabling this template; on an unprotected branch the owner's ship decision is enforced only by the agents' instructions.

Beyond the catalog

Every template is ordinary YAML — after instantiating, export it with tangle workflows get <id>, edit, and re-apply with tangle workflows update <id> file.yml. The platform hub's assistant can also author workflows conversationally (it teaches itself from these same templates), and the YAML reference documents the complete surface.