# Review and iterate > Check a new CLI against real work, then make the smallest change that fixes it. 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](#change-commands-with-okibi-yml) | A new version | | The spec is wrong, and the build is paused on it | [Send the spec back](#send-the-spec-back) | Nothing yet. The agent revises the spec | | The plan needs to change for next time | [Change the spec without building](#change-the-spec-without-building) | Nothing | | A finished build has a bug | [Repair the build](#repair-the-build) | The same build and version, fixed | | The source changed, or you want more commands | [Build a new version](#build-a-new-version) | A new version | | You changed the generated code yourself | [Publish your commits](#publish-your-commits) | A new version | None of these move the official release. You choose that in [Releases and install](https://okibi.ai/docs/guides/releases.md). ## 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](https://okibi.ai/docs/guides/create-a-cli.md#customise-it-with-okibi-yml). ## Send the spec back **In the app** 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. **In the CLI** ```sh okibi spec show my-cli okibi spec reject --feedback "Add project search and paginate the task list" ``` 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](https://okibi.ai/docs/guides/approve-the-spec.md). ## Change the spec without building Edit `cli-spec.md` yourself: ```sh 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: ```sh okibi generate ./my-api --name my-cli --spec-only ``` Both 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. ```sh okibi message --text "Task search should accept a project filter" --wait okibi status okibi pull ``` - The agent repairs that same build and version, at no extra generation charge. - `--wait` waits until the agent accepts the message, not until the fix is done. Follow the repair with `okibi 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 ` shows one delivery. See [Builds and chat](https://okibi.ai/docs/guides/runs-and-chat.md#chat-with-the-agent) 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: ```sh okibi clis changes my-cli okibi clis publish my-cli --commit ``` 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](https://okibi.ai/docs/guides/runs-and-chat.md#publish-edits-to-the-generated-repository). ## Next steps - [Releases and install](https://okibi.ai/docs/guides/releases.md): Make the fixed version the one your users install. - [Testers](https://okibi.ai/docs/guides/testers.md): Let testers try a version before it becomes official. - [okibi message](https://okibi.ai/docs/cli/reference/message.md): Every flag for messages and delivery checks.