Quickstart

This page walks through the whole flow with one real change. It assumes you have already installed the desktop app and connected a model source under "Settings → Models"; see Install on macOS or Install on Windows.

1. Create a project for your project directory

Use the Projects section of the session list in the sidebar, or pick a real working directory from the "Runs in" row above the composer. A project is a container built around one working directory, and the sessions inside it work with real files and commands; ordinary conversations that are not attached to a project are managed separately.

A session's working directory decides where Klaus's file operations and commands happen by default, so getting the directory right in this step matters more than anything else.

2. State the goal clearly and let it produce a plan first

Describe the outcome you want in the composer, rather than prescribing a step. To agree on the approach first, turn on "Plan" in the composer's + menu and then submit your task, such as "Add CSV export to this project and describe how to verify it". Klaus investigates the code and asks structured questions when a decision needs your input. Select your answers and explicitly submit them.

The complete proposal appears as a distinct plan. Expand it, or open the right-panel editor, edit the full text, and save; resolve any conflict before proceeding. Choose "Other" to describe revisions, or "Yes, implement this plan" (⌘/Ctrl+Enter) when ready. Klaus uses the current complete version and retains the existing tool permissions. See Plan mode.

3. Approve actions through the permission cards while it works

Before it writes a file or runs a command, a permission card pops up with Deny / Allow buttons and a middle option, "Allow for this session" (shown only when the engine can derive a safe rule from this particular call). The card also carries a checkable suggested rule: tick it before allowing and you have said "do not ask again for anything of this kind". If the confirmations get in the way, configure allow and deny rules ahead of time in Settings → Pre-authorization Rules, or switch the permission mode next to the composer to "Auto-edit". See Plan Mode and Permission Confirmation.

4. Verify the changes in the changes view

The changes view on the right (called "Changes" in the interface) computes every uncommitted change this repository currently has relative to HEAD, including untracked new files and anything you edited by hand. So it answers "how does this repository differ from HEAD right now", not "what did Klaus change".

Start with the per-file statistics to locate the scope, then expand an individual file to read the specific lines.

5. Commit

Commit from the changes view. A commit here is whole-repository: everything is staged in full and then committed, with no option to commit only some files, so check the change list before committing to be sure nothing extra rides along. You can have Klaus read the diff and write the commit message.

Next

• When one thing takes many turns to finish, attach a goal to the session so it audits its own end state; see Goals and Side Tasks.
• To keep changes on independent branches that do not interfere with each other, use parallel worktrees; see Parallel Worktrees.
• To have it run on a schedule by itself, see Scheduled Tasks.
• To teach it your own way of doing something, see Skills.