A first build is rarely the last one. Check the CLI against what your users need. Then pick the smallest change that fixes what you found.
Check the CLI
- Read
my-cli --help, then the help of the commands your users need most. - Sign in the way your users will.
- Try a read, a list that needs more than one page, an error, and a safe write.
- Confirm it calls the right API base URL before you point it at real customer data.
The Validate and Package stages build the CLI and run it in live checks. Only you know your product's permissions and workflows, so test those yourself.
Pick the change
| What you found | What to do | What it builds |
|---|---|---|
| A command's name, group, or help should change | Accept a suggestion or edit okibi.yml | A new version |
| The spec is wrong, and the build is paused on it | Send the spec back | Nothing yet. The agent revises the spec |
| The plan needs to change for next time | Change the spec without building | Nothing |
| A finished build has a bug | Repair the build | The same build and version, fixed |
| The source changed, or you want more commands | Build a new version | A new version |
| You changed the generated code yourself | Publish your commits | A new version |
None of these move the official release. You choose that in Releases and install.
Change commands with okibi.yml
For a CLI created in the app, review agent ready optimization's suggestions on its ready page and accept the ones you want. Accepted suggestions go into okibi.yml and ship in a new build. To make a change yourself, edit okibi.yml in the CLI's repository; the next build applies it. See Customise it with okibi.yml.
Send the spec back
Type what to change in the box under the chat and send it. On the project's Builds page, Request changes opens the same chat.
Say what to change and why, one change per line. The agent revises the spec, and the build pauses again for you to approve. See Approve the spec.
Change the spec without building
Edit cli-spec.md yourself:
okibi spec show my-cli > cli-spec.md okibi spec edit my-cli --file ./cli-spec.md
Or let the agent propose a new spec from your code:
okibi generate ./my-api --name my-cli --spec-onlyBoth need a CLI that has been generated once, and neither builds. The next generation starts from the new spec. --spec-only needs a codebase source, and it pauses so you can approve the proposal first.
Repair the build
Send the fix to the build's agent with okibi message. This works on a build that succeeded and still has its conversation.
okibi message <run-id> --text "Task search should accept a project filter" --wait okibi status <run-id> okibi pull <run-id>
- The agent repairs that same build and version, at no extra generation charge.
--waitwaits until the agent accepts the message, not until the fix is done. Follow the repair withokibi status, then pull again.- Release pins don't change. If the repair fails, the earlier artifact stays.
- To retry without sending twice, reuse the same
--request-id.okibi message status <run-id> <message-id>shows one delivery.
See Builds and chat for more on talking to the agent.
Build a new version
Click Regenerate on the CLI page, or run okibi generate again with the same --name. A CLI with that name already in the workspace is updated, not duplicated.
The new build starts from the current spec. For a CLI created in the app, it rebuilds from your OpenAPI spec and keeps everything in okibi.yml. In the terminal, add --review to read the updated spec before it builds (codebase sources only).
Publish your commits
The generated code lives in the CLI's own repository. If you commit changes there, publish them as the next version:
okibi clis changes my-cli okibi clis publish my-cli --commit <commit-sha>
Use the commit that clis changes prints. In the app, open Settings > Updates and click Check for changes. See Publish edits to the generated repository.