# Genotype CLI
[The Genotype installation](https://genotype-lang.org/docs/getting-started/installation) includes the `gt` binary, which you can use to run Genotype commands.
## Project Paths
Genotype resolves a project by searching for `genotype.toml` in a starting directory and then its parents. The first configuration file found defines the project. An explicit configuration path bypasses this search.
Paths can be absolute or relative to the working directory. The resolved [configuration](configuration.md#root---project-root) determines the project root, source files, and output directories.
## `gt init`
`gt init` starts an interactive wizard that creates `genotype.toml` and a `src` directory, with optional example types:
```sh
gt init [PATH]
```
`PATH` is the directory to create the project in. It defaults to the current directory:
```sh
gt init ./bookstore-types
```
The wizard helps you choose target languages, generate standalone packages or integrate into existing ones, optionally add example types, and install the Genotype agent skill as the final step. You can adjust these choices later in [genotype.toml](configuration.md).
## `gt skill`
### `gt skill install`
Install the bundled Genotype agent skill or update existing installations:
```sh
gt skill install [PATH] [--agent AGENT]
gt skill update [PATH]
```
`PATH` defaults to the current directory. Installation prompts for an agent unless `--agent` is specified. Update discovers installed skills in known agent directories under `PATH` and replaces their bundled files with the content from your installed CLI.
See [Agent Skill](https://genotype-lang.org/docs/toolchain/skill/) for more info and installation instructions.
### `gt skill update`
## `gt build`
`gt build` builds the project using the configuration in `genotype.toml` or a specified configuration file or directory.
```sh
gt build [PATH] [--config CONFIG]
```
`PATH` is the starting directory for [project resolution](#project-paths). It defaults to the current directory:
```sh
gt build
```
Source selection and target options come from [genotype.toml](configuration.md).
### Configuration File
`--config` selects a configuration file explicitly, instead of searching for `genotype.toml`:
```sh
gt build --config ./genotype.release.toml
```
The path is relative to the working directory, even when you also pass a project path. Paths inside the configuration are resolved from its directory; see [project root](configuration.md#root---project-root).
**Note:**
`gt build` generates target code. Use the target language's tools to install dependencies, compile
the generated package, or run its tests.
### Exit Status
For scripts and CI, a successful build exits with status `0`. Build errors exit with status `1`. Warnings alone don't cause a build failure.
## `gt version`
`gt version` updates package versions in `genotype.toml`. It has two subcommands: `set` and `bump`.
Changes are saved to the configuration. Run `gt build` afterward to update generated package manifests.
### Version Fields
Package versions come from the [global version](configuration.md#version---package-version) and any overrides in [target manifests](configuration.md#targetmanifest---package-metadata). Existing overrides are updated even when their targets are disabled.
### `gt version set`
`gt version set` assigns a version to the existing [version fields](#version-fields):
```sh
gt version set VERSION [PATH] [--ts VERSION] [--py VERSION] [--rs VERSION]
```
`PATH` selects the starting directory for [project resolution](#project-paths) and defaults to the current directory.
`VERSION` is required and accepts a semantic version string, e.g., `0.2.0`:
```sh
gt version set 0.2.0
```
If no version fields exist, this adds a global `version`. Otherwise, it updates the fields already present without adding missing global or target fields.
#### Target Version Overrides
Use `--ts`, `--py`, or `--rs` to assign a different version to an existing target override. `--rust` is an alias for `--rs`:
```sh
gt version set 0.3.0 --ts 0.4.0 --py 0.5.0 --rs 0.6.0
```
These flags require an existing version in the target manifest. Targets without an override inherit the global version.
The positional `VERSION` must be at least as high as every existing version field, including targets with an override flag.
### `gt version bump`
`gt version bump` increments a version component in every existing [version field](#version-fields):
```sh
gt version bump [PART] [PATH]
```
`PATH` selects the starting directory for [project resolution](#project-paths) and defaults to the current directory.
`PART` accepts `major`, `minor`, or `patch` and defaults to `minor`:
```sh
gt version bump
```
Starting from `1.2.3`, each choice produces:
| `gt version bump major` | `2.0.0` |
| `gt version bump minor` | `1.3.0` |
| `gt version bump patch` | `1.2.4` |
Each version is bumped independently. E.g., a patch bump changes a global version of `0.2.0` to `0.2.1` and a TypeScript override of `0.3.4` to `0.3.5`.
To bump another project, specify the part before its path:
```sh
gt version bump patch ./bookstore-types
```
If no version fields exist, the command reports an error. Use `gt version set` to assign an initial version first.
## Help and CLI Version
Run `gt` without arguments to show the available commands. You can also use `--help` or `-h`:
```sh
gt --help
```
Use `--help` with a command to see its arguments and options:
```sh
gt build --help
```
To print the installed CLI version, use `--version` or `-V`:
```sh
gt --version
```
The [`gt version`](#gt-version) command manages your project's package versions.