Skip to main content
px0 init ships no workflows at all. That is the point - you describe what you want in plain English and get a working file back, rather than adapting a template someone else wrote.
Behind that one command, px0 runs an interview and four model passes, stopping for your confirmation at the points where a wrong answer would actually cost you something:
  1. Interview - one question at a time, until the request is concrete.
  2. Clarify - what is still genuinely ambiguous about the request?
  3. Discover - search Composio’s catalogue for the tools it needs.
  4. Confirm - you approve the tool set before anything is authorized.
  5. Plan - write the workflow against exactly those tools.

​
1. The interview

px0 workflows new opens an interview, one question at a time, until px0 has what a workflow file must pin down:
One question per turn, and the model sees every answer before writing the next one - so answering “razorpay/api, every Friday” in one breath skips the two questions that would have asked for those separately. Enter on a blank line ends the interview early and the request is written from what you did say, and the interview stops after eight questions regardless. The request is shown before the build spends a planning call on it: edit rewrites it, n cancels, anything else builds.

​
2. It asks what is still ambiguous

Only things that would change the generated workflow get asked - which account, which channel, how often, where output goes. The model is explicitly told not to ask about anything it can pick a sane default for, because an interrogation is worse than an assumption. You are never trapped in this. Press Enter to skip a question; skip everything in a round and the loop ends. It asks at most three rounds regardless. --no-clarify skips the pass entirely and builds from the description as written. Whatever you answer is carried into every later pass, so the plan reflects your answers rather than re-guessing them.

​
2. It searches Composio’s catalogue

Notice what the model writes here: searches, not tool names. A toolkit plus a short capability phrase. It cannot know Composio’s naming conventions - there is no GMAIL_GET_EMAIL, for instance - so it describes the action and px0 does the lookup. Nothing is invented along the way: a slug that does not appear in the search results is discarded. This is why a generated workflow gets the tool that actually fits rather than the nearest of px0’s ten curated ones. Composio’s catalogue runs to thousands of tools, and px0 workflows new searches all of it. --no-discover skips the search and restricts the plan to the curated tools.

​
3. You confirm the tools

This is the gate before anything is authorized or written, and it is worth reading rather than reflexively accepting. The model chose these tools; picking up a write tool your request never asked for is exactly the mistake this screen exists to catch. Access is stated per tool and comes from Composio’s own metadata - px0 never infers it from the name: The selection pass is told to prefer the fewest tools, prefer reads over writes, include a write only when the request explicitly asks to change something, and never include a destructive tool unless you asked to delete something. Confirmed tools are recorded in the store, so the plan, its validation, and every future run resolve them without another catalogue lookup. A workflow keeps working offline and unchanged after it is written.

​
4. It authorizes what the plan needs

It asks before minting anything. Answer n and nothing is prepared - the first run that needs the app will offer a link instead. Anything already authorized is skipped:
Authorization happens before planning, so a build that cannot possibly work - a toolkit Composio refuses to authorize at all - stops before spending a planning call on it. A pending consent is different from a blocked one, and it does not throw away your work. The workflow file is valid either way, so px0 writes it and tells you what is still waiting in the browser.

​
5. It writes the plan

Read tools land in inputs, which run before the prompt to gather context. Write tools land in tools, which the model calls during the run. px0 enforces that split: a write tool in inputs is a validation error, because inputs run unconditionally and a workflow should not post something just by starting. Because this workflow carries a schedule, its output goes to a file. A scheduled run has no terminal to print to, so px0 treats schedule-plus-stdout as a validation error rather than losing the output. Then two checks print:
  • Feasibility. A tool that does not exist, an input with no tool, an invalid cron expression, an output path that escapes the store. These stop the build, and nothing is saved.
  • Write access. The write tools this workflow would be granted, named again now that the plan is concrete.

​
6. Confirm and name it

Accept the suggested id or type your own. For scripted use, --yes skips every prompt in this flow - clarifying questions, tool confirmation, authorization, and this one - and --id <id> names it directly.

​
What you get

Guidelines are matched to the task by topic, and a file is attached only if it genuinely matches. Every guideline is inlined verbatim into the prompt, so an unrelated one costs tokens and actively misleads the model. A commit-message workflow gets commit-messages.md; a workflow about haikus gets none. The file itself is plain Markdown, and every field in it is documented in Workflow files.

​
Guidelines it offers to write for you

Partway through a build, px0 may stop and say something like:
This is for standards px0 cannot guess: what counts as worth flagging in a review, how blunt your comments are, the voice a summary is written in. Answer in your own words - a couple of lines is plenty - and finish with an empty line:
px0 shapes what you wrote into ## sections, shows you the draft, and takes again if you want another pass. What gets saved is an ordinary guideline file: it has version history from v1, so px0 guidelines log works on it, and it is added to this workflow’s guidelines: list - which means its text is inlined into every run from now on. This is the only way a guideline gets created - there is no px0 guidelines new. Asking someone to compose a convention from a blank page is the step that stopped guidelines from being written at all, so the build drafts a defensible version and leaves editing to you. Nothing is proposed for a workflow that already says what to do, and nothing on a topic you already have a guideline for. --yes skips the step entirely, since there is no sensible default for “what is your commit message convention”.

​
Revise a workflow

px0 shows you the sentence you originally typed, and takes a new one:
This rebuilds the workflow rather than opening the file, and that is on purpose: the tools, inputs, and guideline list all follow from the request, so revising the request and regenerating keeps them consistent with each other. Hand-editing the body is still perfectly fine for a wording change. Just know that a hand edit will not notice when your new instruction needs a tool the workflow does not have - that is the trade you make by skipping the rebuild. The rebuild saves under the same id, and the old version stays in the store’s history:

​
Flags for revisions

While px0 workflows new relies entirely on the interactive interview, px0 workflows edit supports these flags to skip prompts:

​
Next steps

Run a workflow

Dry runs, inputs, stdin, and what failure looks like.

Workflow files

Every frontmatter field, and the four kinds of input.

Connections

What happens when a consent is pending or lapses.

Schedules

Make trigger.schedule actually fire.