CLI

The tmts CLI provides a command-line interface for interacting with the API server. It is published as the @template-monorepo-ts/cli workspace package and produces two build artefacts:

• Node module (dist/index.js) — usable as bun run dist/index.js
• Self-contained binary (bin/tmts) — zero-dependency native executable built with bun build --compile

Installation

From source

# Build the binary
cd packages/cli
bun run build

# Add to PATH (example)
cp bin/tmts ~/.local/bin/tmts

Via bun link (monorepo development)

bun link @template-monorepo-ts/cli

Configuration

tmts resolves its configuration from three sources, in priority order (highest wins):

1. CLI flags — --server, --token, --key, --output
2. Environment variables — TMTS_SERVER_URL, TMTS_TOKEN, TMTS_API_KEY, TMTS_OUTPUT
3. Config file — ~/.config/tmts/config.json

The server URL is required for every command. If it cannot be resolved from any source, the CLI exits with an error message.

Config file

The config file is stored at ~/.config/tmts/config.json and contains the following keys:

Key	Type	Description
serverUrl	string	API server base URL
token	string	Bearer token (from auth login)
apiKey	string	API key alternative to token
output	"table" | "json"	Default output format

Quick setup

# Point the CLI at your running API instance
tmts config set serverUrl http://localhost:3000

# Authenticate — asks for the password without echoing it
tmts auth login --email admin@example.com

Global flags

These flags are accepted by every command and override environment variables and the config file.

Flag	Env var	Description
--server	TMTS_SERVER_URL	API server URL
--token	TMTS_TOKEN	Bearer token for authentication
--key	TMTS_API_KEY	API key for authentication
--output	TMTS_OUTPUT	Output format: table (default) or json

Output formats

All commands support two output formats controlled by --output:

• table (default) — human-readable tabular output
• json — machine-readable JSON, useful for piping into jq or scripts

tmts projects list --output json | jq '.[].name'

---

Command reference

tmts system

Commands that query the API server's operational status.

tmts system <subcommand> [flags]

Subcommand	Description
version	Show the API server version
health	Check API server health
ready	Check API server readiness
live	Check API server liveness

Examples

tmts system version
tmts system health
tmts system ready --output json

---

tmts auth

Commands for authenticating with the API server.

tmts auth <subcommand> [flags]

Subcommand	Description
login	Login with email/password or store an API key
logout	Clear stored credentials from config
whoami	Show the currently authenticated user

tmts auth login

tmts auth login [--email <email>] [--key <api-key>]

Two authentication modes are supported:

• Email/password — exchanges credentials for a bearer token via BetterAuth, then saves the token to the config file.
• API key (--key) — stores the provided API key in the config file directly (no network request needed).

Where the password comes from, in order: --password, then TMTS_PASSWORD, then a prompt. On a terminal the prompt does not echo; with stdin piped it reads one line, so unattended runs work without putting the password on the command line. The email follows the same order (--email, TMTS_EMAIL, prompt).

--password still works and still warns, because a password given as a flag is readable by any other process on the host via ps or /proc/<pid>/cmdline while the command runs, and is written verbatim into your shell history afterwards — where it survives into dotfile backups and synced repos. The same is true of --token and --key; prefer TMTS_TOKEN and TMTS_API_KEY.

Examples

# Interactive login — prompts for the password, echo off
tmts auth login --email admin@example.com

# Unattended, from an environment variable
TMTS_PASSWORD="$PASSWORD" tmts auth login --email admin@example.com

# Unattended, from stdin
printf '%s' "$PASSWORD" | tmts auth login --email admin@example.com

# Store an API key
TMTS_API_KEY=sk_live_abc123 tmts auth login --key "$TMTS_API_KEY"

tmts auth logout

Removes token and apiKey from the config file.

tmts auth logout

tmts auth whoami

Calls the API's GET /session endpoint and prints the current session.

tmts auth whoami
tmts auth whoami --output json

---

tmts projects

CRUD commands for managing projects.

tmts projects <subcommand> [flags]

Subcommand	Description
list	List all projects
get	Get a project by ID
create	Create a new project
update	Update an existing project
delete	Delete a project

tmts projects list

tmts projects list [--output json]

tmts projects get <id>

tmts projects get 01J9Z3H2X5K7M8N4P6Q0R1S2T3

tmts projects create

tmts projects create --name <name> [--description <description>]

tmts projects create --name "My Project" --description "A sample project"

tmts projects update <id>

tmts projects update <id> [--name <name>] [--description <description>]

tmts projects update 01J9Z3H2X5K7M8N4P6Q0R1S2T3 --name "Renamed"

tmts projects delete <id>

tmts projects delete 01J9Z3H2X5K7M8N4P6Q0R1S2T3

---

tmts config

Commands for reading and writing the local CLI config file (~/.config/tmts/config.json).

tmts config <subcommand>

Subcommand	Description
set <key> <value>	Set a config key to a value
get <key>	Print the value of a config key
list	List all config keys and values
delete <key>	Remove a config key

Valid keys: serverUrl, token, apiKey, output.

Token and API key values are truncated (first 8 characters + ...) when listed for security.

Examples

# Initial setup
tmts config set serverUrl https://api.example.com
tmts config set output json

# Inspect
tmts config list
tmts config get serverUrl

# Remove a stored token
tmts config delete token

generate

Local code generators — these do not talk to a running API.

tmts generate <subcommand>

Subcommand	Description
resource <name>	Scaffold a new API resource (router, business, queries, constants, index)

Flags

Flag	Description	Default
--dir	Target directory (relative to current working directory)	apps/api/src/resources
--force	Overwrite existing files in the target directory	false

Examples

# Scaffold apps/api/src/resources/tickets/
tmts generate resource tickets

# Scaffold under a non-default directory
tmts generate resource billing --dir apps/api/src/resources

# Overwrite an existing scaffold
tmts generate resource tickets --force

After running, register the new router in apps/api/src/server.ts, add the resource's Prisma model and route schemas in packages/shared/src/routes/<name>.ts, then write co-located tests.