@quietflow/cli

qf is the human-readable builder and release surface for Quiet Flow. It publishes apps to private sandboxes, sends immutable versions for review, promotes reviewed builds, and supports safe rollback.

npm install -g @quietflow/cli
qf login

npm comes with Node, which is the only thing qf needs on your machine. If your terminal answers npm: command not found:

| Where | How | |---|---| | macOS, Homebrew | brew install node | | macOS or Windows, no package manager | The installer at nodejs.org — take the LTS build | | Windows, winget | winget install OpenJS.NodeJS.LTS | | Linux, Debian or Ubuntu | sudo apt install nodejs npm, or nodesource for a current release |

Anything from Node 20 upwards works. If npm install -g reports a permissions error, install Node through one of the routes above rather than reaching for sudo — needing root for a global install usually means Node itself was installed somewhere it should not have been.

qf login signs you in and then offers to connect your AI assistant. It registers Quiet Flow's tools and installs the instructions for using them. It shows every file it would touch and does nothing without a yes.

That is the whole setup. Ask your assistant to publish something.

Commands

| | | |---|---| | qf login | Sign in, and set up your AI assistant | | qf init | Create quietflow.yaml in this folder | | qf dev <command> | Run your app here, with company data and no passwords | | qf publish | Build and publish to your private sandbox | | qf submit | Ask for approval to go live | | qf status | See where your apps are, and what the cluster last said about them | | qf data · qf data ask | See who is deciding about your company data, or ask for some | | qf doctor | Check that everything is set up correctly | | qf promote | Publish an approved version as a release administrator | | qf versions · qf rollback | Inspect versions or return to a reviewed one | | qf connect · qf disconnect | Set up your AI assistant, or undo it | | qf logout | Sign out |

When a project began on the dashboard's Build page, the assistant stores a non-secret .quietflow/project.json link beside quietflow.yaml. qf publish passes that link back to the API so the new Application is attached to its browser brief; the file is never included in the source archive.

qf login --no-connect signs in and stops. --yes answers the setup questions for scripts.

qf data — asking a colleague, from the terminal

If your app reads something real — customer records, documents, a calendar — a person at your company has to allow it. That person is a colleague, not a setting, and you never see a password, a field list, or the name of the system it lives in.

qf data ask

Four questions about your own work: what the app will do with the data, what it needs in your words, where it ends up, and how long the app keeps it. Testing with real records and letting the live app read them are two separate decisions, so you are asked which one you mean and neither is ever evidence for the other.

If your app reads the same kind of data from two places — you gave each one a name in quietflow.yaml — say which one you mean:

qf data ask --as customers

Each place is decided separately, often by a different person, so leaving it off when there are two is refused rather than guessed at, and the refusal lists the names you gave them.

qf data

What has been asked, what was decided and by whom, and what to do next about each one. While somebody still has your request it says who has it and since when, and what happens if they do nothing — which is nothing: a request does not expire and nobody is chased for you. It will never tell you when an answer is coming, because nobody here knows.

You do not have to wait. qf dev serves records in the same shape from the moment the request exists, so the same code starts reading real ones when it is allowed.

qf dev — company data on your laptop, without a password

qf dev npm start

Your app runs as normal. When it asks for company data, it asks a local address Quiet Flow is listening on, and Quiet Flow asks your company's systems. You are never given a password, a key, or a connection string, and nothing is written to your project folder — there is no .env to leak, commit, screenshot, or paste into a chat window.

Your app receives exactly three settings:

| | | |---|---| | QF_CAPABILITY_ENDPOINT | The local address to ask through. | | QF_DEV_SESSION | A one-off pass for this run. Worthless anywhere else. | | QF_DATA_SOURCE | company, sample, or mixed — say which on screen. |

Your app should POST to ${QF_CAPABILITY_ENDPOINT}/v1/data with that pass in an x-qf-dev-session header, and a body naming what it wants:

{ "capability": "crm.read", "operation": "list_accounts" }

That is the same request the published app makes, so nothing has to change when you publish.

If nobody has approved this app to read that data yet, you still get to work. Quiet Flow gives you made-up rows in the real shape, built from the list of information you asked for — never from real records — and says so on screen. Ask for access from the app's data page and the same code starts getting real records when it is approved.

Your own sign-in and your assistant's credentials are not passed to your app. Press Ctrl-C to stop; the connection closes and the session ends with it.

Where things are kept

| | | |---|---| | ~/.config/quietflow/config.json | Your sign-in. Written 0600. | | ~/.config/quietflow/assistant.json | Your assistant's separate sign-in. |

Two credentials, deliberately. Cancelling your assistant's does not sign you out, and signing out does not leave a program authenticated in your name. No token is ever written into your assistant's own configuration file.

Claude Code receives the skill at ~/.claude/skills/quiet-flow. Codex receives the same native skill at ~/.agents/skills/quiet-flow; Quiet Flow never edits your global AGENTS.md.

The released CLI connects to https://api.quietflow.net. QF_API_URL points local development or a self-hosted install at a different control plane. QF_TOKEN overrides the stored credential for CI.

What it does not do

The CLI implements no lifecycle, policy, or authorization rules. It never asks you to write a Dockerfile, configure sign-in, choose a release artifact, or think about servers. If it ever does, that is a bug.