use-miren

Use Miren

Preflight

Before any operation, verify context:

command -v miren          # CLI installed
miren version           # check CLI version

If the CLI is missing, guide the user to install it.

Discovering commands

Use the built-in help system to learn about miren commands:

miren help --commands             # list all available commands
miren help app.list               # help for a specific command (use . for spaces)
miren help "app list"             # alternative: quote the command
miren help doctor.server          # help for doctor server

When unsure about a command's flags or behavior, always check miren help first rather than guessing.

Cluster targeting

Most miren commands accept -C <cluster> to target a specific cluster. When the user refers to a cluster by name (e.g., "how's the garden cluster doing", "check on staging"), pass that name with -C:

miren app list -C garden
miren doctor server -C garden
miren logs -a myapp -C garden --lines 50

If the user doesn't specify a cluster, omit -C to use the default.

Specialized agents

For complex workflows, delegate to a specialized agent using the Agent tool. Match the user's intent to the right agent:

• app-setup (agents/app-setup.md): Use when the user wants to set up a new app, onboard an existing project to miren, or understand what an application needs to run. This agent analyzes source code for env vars, databases, services, and walks the user through configuration.
• app-health (agents/app-health.md): Use when the user asks about a specific app's health, status, logs, or issues.
• cluster-health (agents/cluster-health.md): Use when the user asks about overall cluster health, all apps status, or wants a system-wide overview.

When the user's request matches one of these agents, invoke it with the Agent tool rather than handling it directly.

Execution rules

1. Prefer the miren CLI for all operations.
2. Use miren help to learn about commands before running them.
3. Use --json or --format json where available for reliable, parseable output. Prefer structured JSON over grepping raw text output.
4. For destructive actions, confirm intent and state impact before executing.
5. After mutations, verify the result with a read-back command.

Response format

For all operational responses, return:

1. What was done (action and scope).
2. The result (IDs, status, key output).
3. What to do next (or confirmation that the task is complete).

Keep output concise. Include command evidence only when it helps the user understand what happened.