# Create Ticloud CLI Command > Builds TiDB Cloud CLI commands. Use when creating new commands. - Skill: `tomevault-io/create-ticloud-cli-command` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/create-ticloud-cli-command` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/create-ticloud-cli-command/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - License: Complete terms in LICENSE.txt - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/create-ticloud-cli-command --- # Create TiCloud CLI Command This skill builds TiDB Cloud CLI commands, helping users create new commands with production-ready code. ## When to use - The user asks to create new CLI commands or subcommands. - Do not use when the agent does not support plan mode. ## About TiDB Cloud CLI TiDB Cloud CLI (TiCloud CLI) is a command-line interface for interacting with TiDB Cloud, built on the Cobra library. Key design of TiDB Cloud CLI: - Built on the Cobra library. - Uses the TiDB Cloud Open API as the client and keeps the SDK inside the project. - Every command supports both interactive and non-interactive modes. - More about TiDB Cloud CLI: `references/tidbcloud-cli.md`. - More about Cobra: `references/cobra.md`. ## Core Principles ### Plan first The AI agent must switch to plan mode to collect information from the user and generate a plan first. Then use agent mode to generate the code. ### Test first If the user requires testing, testing takes precedence over implementation. Write tests first, then implement, and finally validate against the tests. ### Declarative The user must declare the command format; the implementation must comply with that declared format. ## Workflow Must follow the workflow below: ### Generate SDK phase Always prompt the user: "Do you need to add or update swagger? Please provide the swagger path if you need." Skip this phase if user does not need. Once in this phase, follow the guide in `references/sdk.md` to generate the SDK. After SDK is generated, ask user to use go>=1.24 to run `make generate-mocks` manually! ### Plan phase The agent must switch to plan mode in this phase. The agent must ask the user for the following information during the plan phase: 1. **Command format**: If the user does not provide the command format, ask them to provide it first. See `assets/command.md` for the command format template. The commnad flags can be omitted as it can be inferred from swagger. 2. **Tests**: Ask whether the user needs tests. Tests are recommended. 3. **Other necessary information** Generate the plan after the user confirms all the information. ### Agent phase The agent must switch to agent mode in this phase. Follow the workflow below: 1. **Ensure the generate SDK phase** 2. **Write unit tests** 3. **Implement command** 4. **Run tests** #### Ensure the sdk Ensure generate SDK phase has been done. #### Write unit tests Skip this step if the user does not need tests. Write unit tests following `references/ut.md`. If the tests need to invoke the command, create the empty command first. See `assets/empty.go`. #### Implement command Implement the command following the patterns in `assets/example`. The implementation must meet the following requirements: 1. **Command definition**: Include name, aliases, example, and other necessary attributes. 2. **Flags definition**: Include flag type, description, default value, etc. Infer flag information from the Swagger spec and SDK client parameters. See `references/flag.md` for more details. Please get customer confirmation once the flags are set. 3. **Flags retrieval**: Implement retrieval logic for both interactive and non-interactive modes. For interactive mode, UI is required. The UI is based on the Bubbletea library. See `references/ui.md` for more details. 4. **Dual mode support**: Support both interactive and non-interactive modes. Rules: 1. **Detect mode** with `MarkInteractive`: - Default to interactive. - If any non-interactive flag is provided, switch to non-interactive and mark required flags. 2. **Interactive constraints**: - If `!h.IOStreams.CanPrompt`, return an error instructing the user to use non-interactive flags. 5. **SDK calls**: Use the SDK client in `api_client.go` to call the corresponding method. Note that `assets/example` does not include this part (it is only a template); it must be included when implementing the actual command. #### Run the tests Skip this step if the user does not need tests. Run tests with: `go test -race -cover -count=1 path -v` For example, to run tests under `internal/cli/serverless/branch`: `go test -race -cover -count=1 ./internal/cli/serverless/branch -v`. Ensure all tests pass. If they do not pass, fix the implementation or the tests. ## Final Code Structure The final code structure must follow the structure in `assets/example`: - Command Go files. - UI Go files. - Test files if needed. Command output should follow the patterns in `assets/example`: - **Human output**: Print a concise, user-friendly message; use `color.GreenString` for success. Avoid raw JSON in human mode. - **JSON output**: Use `output.PrintJson` with a stable, predictable payload (e.g. keys like `message`, resource IDs, `items`). - **No TTY**: Default to JSON output for list/describe-style commands (see `assets/example/list.go`). - **Examples**: Include `Example` blocks for both interactive and non-interactive usage (see `assets/example/create.go` and `assets/example/list.go`). --- > Converted and distributed by [TomeVault](https://tomevault.io/claim/tidbcloud) — claim your Tome and manage your conversions.