> ## Documentation Index
> Fetch the complete documentation index at: https://docs.px0.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Quickstart
> Go from a fresh install to a scheduled workflow and a searchable library, with a short explanation of what each step actually does.
This walks the whole loop end to end: scaffold a store, get one real output with no setup at all, then build a workflow, run it, and put it on a schedule. It takes a few minutes, and nothing here is throwaway - everything you create is a file you keep.
```bash theme={null}
px0 init
```
This creates `~/.px0` and asks for your Composio API key. Skip the key if you do not have one yet; the brain in the next step needs nothing but the store, and you can add the key later with `px0 config composio `.
Using a backend other than `claude`? Point px0 at it now:
```bash theme={null}
px0 init --harness gemini # or pi, or opencode
```
The brain is the fastest thing in px0 that produces something useful, because it touches no external app at all:
```bash theme={null}
px0 brain add https://example.com/some-post
px0 brain ask "what did that post say about caching?"
```
`brain add` extracts the text locally, files it as Markdown under `brain/`, and indexes it. `ask` retrieves the passages that matter and answers from them - add `--sources` when you want to see exactly which passages it used.
Keep adding posts, papers, and internal docs as you read them. The library gets more useful the longer you use it. See [The brain](/brain/library).
px0 ships no workflows on purpose. You describe what you want, and it writes the file:
```bash theme={null}
px0 workflows new
```
That opens an interview - one question at a time, until px0 has the job, what it reads, where the result goes, when it runs, and what makes the output right. It writes the request back for you to approve or reword before anything is built. Enter on a blank line ends the questions early.
px0 then asks about anything genuinely ambiguous (which repositories, which channel), searches Composio's catalogue for the tools the job needs, and shows you the list before authorizing anything. Tools that can post or send are called out separately, so you can drop anything you did not ask for.
Then it writes the workflow file and prints its id. Pass `--id ` if you would rather name it yourself.
The whole flow, screen by screen, is in [Build a workflow](/workflows/build).
Start with a dry run. It resolves every input for real but stubs out anything that would post, send, or change something outside px0:
```bash theme={null}
px0 workflows run friday-pr-digest --dry-run
```
When the output looks right, run it for real:
```bash theme={null}
px0 workflows run friday-pr-digest
```
The first time a workflow needs Slack or Gmail, px0 hands you a URL to approve in the browser. You only ever authorize the apps you actually use, and nothing is granted until you consent. See [Connections](/tools/connections).
Forgotten the id? Leave it off and pick from a list:
```bash theme={null}
px0 workflows run
```
Your workflow already carries the schedule from the sentence you typed - `every friday at 5pm` became a cron expression in its frontmatter. What is missing is something watching the clock. Install the scheduler:
```bash theme={null}
px0 daemon install
px0 daemon status
```
px0 picks the right mechanism for your OS: launchd on macOS, a systemd user service on Linux, cron everywhere else. If your laptop was closed when a fire was due, px0 notices on the next tick and runs what it owes you. See [Schedules and the daemon](/workflows/schedule).
Every run leaves a record: the inputs it resolved, the guideline versions it inlined, every tool call with its timing, and the outcome.
```bash theme={null}
px0 workflows list # what you can run
px0 status # is anything broken
px0 runs # browse past runs interactively
px0 runs why # how one run reached its result
```
`px0 runs` is an interactive browser - filter by workflow, outcome, or age, drill into a run, and rerun it without copying ids between commands. See [Browse runs](/runs/browse).
## Teach it how you work
Generated output is only as good as the conventions behind it. Guidelines are Markdown files describing how you work - how you word a commit message, what your Go reviews check, how blunt your review comments are. A workflow lists the guidelines it needs, and those files are inlined verbatim into the prompt, so output comes back in your voice instead of the model's default.
You never write one from scratch. When `px0 workflows new` finds that a workflow leans on a convention you have no file for, it drafts that guideline from the workflow, shows it to you, and lists it on the workflow so every run inlines it. Editing the draft is how it becomes yours:
```bash theme={null}
px0 guidelines list
px0 guidelines edit commit-messages
```
## Where your data lives
Your store is `~/.px0`. Set `PX0_HOME` to move it somewhere else.
| Folder | What is in it |
| :------------ | :---------------------------------------------- |
| `workflows/` | The jobs px0 can run |
| `guidelines/` | How you work |
| `brain/` | What you have read and kept |
| `output/` | What runs produced |
| `tools/` | Tools you declared yourself, one TOML file each |
All of it is plain Markdown you can open in any editor. Edit a workflow by hand and the next run picks it up, with no compile step. px0 keeps its own history, so you can always see what changed and undo it:
```bash theme={null}
px0 changes list
px0 changes show
```
## Where to go next
The vocabulary: store, workflow, tool, guideline, brain, run.
Every screen of the builder, and what each decision costs you.
How apps authorize themselves, and what to do when one lapses.
Every `px0 doctor` check, what it means, and how to clear it.