ReferenceCLI

`intropy` CLI

Authoritative reference for the intropy command-line interface.

The CLI is the build-side primitive: it scaffolds integrations from the official template library, assembles them into a System host, renders and creates Kubernetes manifests, publishes immutable releases, and moves components between environments through the GitOps repository and ArgoCD. Everything it does not do (authentication, execution, cluster access, observability) lives in the system that owns each concern. Installation is covered in Install the CLI.

Command groups

Group	Purpose
`intropy int`	Create integrations from templates and read their scaffold records.
`intropy sys`	Assemble scaffolded integrations into a System host.
`intropy template`	List the template library and inspect template manifests and parameter schemas.
`intropy manifests`	Inspect the deployment model, render Kubernetes YAML, and create manifests on a GitOps review branch.
`intropy release`	Publish and inspect immutable release manifests.
`intropy deploy`	Pin, promote, review, and apply deployments through the GitOps repository and ArgoCD.
`intropy dashboard`	Serve the local integration dashboard.
`intropy version`	Print version information.
`intropy completion <shell>`	Generate the shell completion script (`bash`, `zsh`, `fish`, `powershell`).

Global flags

Every command accepts:

Flag	Description
`-C`, `--directory <dir>`	Change to `<dir>` before running the command.
`--no-color`	Disable colored output.
`-v`, `--version`	Print version information (root command only).

Flag conventions

-o means --output everywhere except the two scaffolding commands. In int create and sys create, -o is --out-dir (the destination directory, the same split as dotnet new), and machine-readable output is requested with the long form --output json. In every other command, -o is --output and takes plain or json.
Template pinning is --template-version everywhere. Every command that resolves the template library accepts --template-repo <owner/repo> and --template-version <tag>; unpinned, the latest GitHub release is used.
Progress goes to stderr, results to stdout. Pipes stay clean: manifests render writes only YAML to stdout, and --output json documents are the only thing on stdout when requested.

Configuration

Settings that belong to a person and a machine (rather than to a project) resolve in a fixed order: flag, then environment, then file, then the built-in zero value.

Setting	Flag	Environment	File key
GitOps repository URL	`--gitops-repo`	`INTROPY_GITOPS_REPO`	`gitopsRepo`
ArgoCD server address	`--argocd-server`	`ARGOCD_SERVER`	`argocdServer`
Template library (`owner/repo`)	`--template-repo`	`INTROPY_TEMPLATE_REPO`	`templateRepo`

The file is ~/.config/intropy/config.yaml (or $XDG_CONFIG_HOME/intropy/config.yaml when XDG_CONFIG_HOME is set). It is optional: a missing file is the zero configuration, but a file that exists and cannot be parsed, or that carries an unknown key, is an error.

Two of the environment variables are borrowed, not owned: ARGOCD_SERVER and ARGOCD_AUTH_TOKEN are the argocd CLI’s own variables, honoured deliberately so an existing ArgoCD setup works with no extra configuration. For the ArgoCD server specifically, a deploy.yaml in the GitOps repository beats the user configuration file (--argocd-server, then ARGOCD_SERVER, then deploy.yaml, then argocdServer): the setting travels with the repository the overlays live in.

Exit codes

Code	Meaning
`0`	Success, or a safe no-op (a digest already pinned, an identical release re-published).
`1`	Runtime error. The `error: …` line names the cause.
`2`	Usage error: unknown command, missing required flag, bad argument.
`127`	A required external binary is missing from `PATH` (`git`, `kustomize`).
`130`	Interrupted (Ctrl-C).

Two reporting commands never gate: deploy diff exits 0 on a non-empty diff, and deploy status exits 0 even when environments disagree (read consistent from its --output json form to gate in CI).

What the CLI does not do

Concern	Where it lives instead
Login and accounts	There are none. Registry access uses the standard Docker credential chain (`docker login`, `gh auth login`); ArgoCD access uses the `argocd` CLI’s own configuration or `ARGOCD_AUTH_TOKEN`.
Talking to the cluster	Never. The CLI never invokes `kubectl`; deployment goes through the GitOps repository, and ArgoCD applies it.
Running integrations	The System host (`dotnet run`) locally; the cluster in every other environment.
Logs, metrics, traces	The observability stack (see intropy.run).
CLI self-update	The install script or your package manager.

This boundary is deliberate. If a workflow does not appear above, it is not a CLI gap; it is somewhere else by design.