configure

name	configure
description	Walks through full ops-suite setup: asks about all infrastructure components and writes config.yaml. Use when setting up ops-suite for the first time or when config.yaml is missing.

UI Rules — MANDATORY

Always use AskUserQuestion for every selection in this wizard. Never present choices as plain text lists.

• Single-choice questions → multiSelect: false
• Multi-choice questions (environments, services) → multiSelect: true
• Text inputs (slugs, ports, commands) → group as a follow-up AskUserQuestion with an "Other" option that prompts the user to type
• Use preview on options when showing side-by-side comparisons (e.g. port mappings)
• Run auto-detection silently first; use detected values as the first/recommended option
• Batch up to 4 independent questions per AskUserQuestion call to minimize round-trips

Overview

Full interactive wizard. Asks the user about every infrastructure component one section at a time. Auto-detection is used only to suggest defaults — every question is always asked explicitly, never skipped.

Resolve the user config directory as ${XDG_CONFIG_HOME:-$HOME/.config}/ops-suite. Store it as {config_dir}. Create it with mkdir -p {config_dir} before writing.

---

Section 1 — Orchestrator

Ask:

"What container orchestrator do you use?"

• kubernetes — kubectl + cluster contexts
• docker-compose — local or remote compose files
• ecs — Amazon Elastic Container Service
• none — no container orchestrator

Store as {orchestrator}.

---

Section 2 — Environments

2a — Which environments

Ask:

"Which environments do you want to configure?" (multi-select)

• dev
• staging
• prod
• other — user types the name(s) in notes

Store the list as {envs}.

2b — Load orchestrator adapter

Read adapters/{orchestrator}.md for all orchestrator-specific detection commands and questions. If the adapter does not exist, tell the user the orchestrator is not yet supported and skip environment-specific detection (ask manually).

Follow the adapter instructions for each environment to collect:

• {env.context} or equivalent connection identifier
• {env.ns_apps} / service scope (where app services run)
• {env.ns_infra} / infra scope (where broker and DB run)
• {env.local_port} (local port for DB port-forwarding)

---

Section 3 — Message Broker

Ask:

"Which message broker do you use?"

• rabbitmq
• azure-service-bus
• sqs
• kafka
• none

Store as {broker}.

If broker = rabbitmq

For each environment, follow the orchestrator adapter's "Detect broker service" instructions (if available) to optionally suggest a default. Then ask:

Ask per environment:

1. "{env_name} — RabbitMQ service name?" (suggest detected or rabbitmq)

2. "{env_name} — Pod name pattern (e.g. rabbitmq-*)?"

3. "{env_name} — Management port?" (default 15672)

4. "{env_name} — AMQP port?" (default 5672)

5. "{env_name} — vhost?" (default /)

If broker = sqs / azure-service-bus / kafka

Ask per environment for the connection string or region/endpoint relevant to that broker.

---

Section 4 — Database

Ask:

"Which database do you use?"

• postgresql
• mysql
• mongodb
• none

Store as {database}.

If database = postgresql or mysql

For each environment, follow the orchestrator adapter's "Detect database service" instructions (if available) to optionally suggest a default. Then ask:

Ask per environment:

1. "{env_name} — DB proxy/service name?" (suggest detected)

2. "{env_name} — Port?" (default: 6432 pgbouncer / 5432 postgres / 3306 mysql)

3. "{env_name} — Default database name?"

If database = mongodb

Ask per environment for service name and port (default 27017).

---

Section 5 — CI/CD Pipeline

Ask:

"Which CI/CD provider triggers your deployments?"

• github-actions
• gitlab-ci
• none

Store as {ci_provider}.

If ci_provider ≠ none

Ask:

1. "How is the image tag determined after a CI run?"

   • run-id (most common), commit-sha, tag
   • Store as {image_tag_source}

2. "Repository slug? (e.g. my-org/my-repo)"

   • Store as {repo_slug}

---

Section 6 — Migrations

Ask:

"Which database migration tool do you use?"

• mikro-orm, typeorm, knex, flyway, none

Store as {migration_tool}.

If migration_tool ≠ none

Ask:

"Migration command? (e.g. npm run migrations:up)" Store as {migration_command}.

---

Section 7 — Primary service

Follow the orchestrator adapter's "Detect primary service" instructions (if available) to optionally suggest defaults. Then ask:

"Primary application service name? (used for health checks and log tailing after deploys)"

• List up to 4 detected services (if detection ran) + "I'll type it manually"

Store as {primary_service}.

---

Section 8 — Service registry (optional)

Ask:

"Register additional services for port-forwarding? (e.g. internal APIs, admin panels)"

• yes / no

If yes, repeat until done:

1. Friendly name (e.g. my-api)
2. Service identifier (e.g. svc/my-api for k8s, service name for compose/ECS)
3. Namespace / cluster (if applicable)
4. Port
5. Health check URL (optional, e.g. http://localhost:{port}/health)
6. Add another?

---

Section 9 — Write config.yaml

Assemble and write to {config_dir}/config.yaml:

# ops-suite configuration — generated by /ops-suite:configure on {YYYY-MM-DD}

orchestrator: {orchestrator}
message_broker: {broker}
database: {database}
service: {primary_service}

environments:
  {env_name}:
    context: "{env.context}"
    namespaces:
      apps: "{env.ns_apps}"
      infra: "{env.ns_infra}"
    services:
      broker:
        name: "{broker_service}"
        namespace: "{env.ns_infra}"
        management_port: {mgmt_port}
        amqp_port: {amqp_port}
        vhost: "{vhost}"
        pod_pattern: "{pod_pattern}"
      database:
        name: "{db_service}"
        namespace: "{env.ns_infra}"
        port: {db_port}
        default_db: "{default_db}"

deploy:
  ci_provider: {ci_provider}
  repo: "{repo_slug}"
  image_tag_source: {image_tag_source}
  migration_tool: {migration_tool}
  migration_command: "{migration_command}"
  local_ports:
    {env_name}: {env.local_port}

service_registry:
  {name}:
    namespace: {ns}
    service: {svc}
    port: {port}
    verify: "{health_check}"

Omit blocks for none values.

---

Section 10 — Cache session

mkdir -p /tmp/ops-suite-session

Write /tmp/ops-suite-session/config.json with equivalent JSON so all skills can use it immediately.

---

Section 11 — Final summary

✓ ops-suite configured successfully
────────────────────────────────────────────────────
  Orchestrator:    {orchestrator}
  Environments:    {env_name_1}, {env_name_2}, ...
  Broker:          {broker}
  Database:        {database}
  CI provider:     {ci_provider}
  Migrations:      {migration_tool}
  Primary service: {primary_service}

  Config written → {config_dir}/config.yaml
  Session cache  → /tmp/ops-suite-session/config.json

Skills now available:
  /ops-suite:service-status     check service health & restarts
  /ops-suite:service-logs       tail and search logs
  /ops-suite:queue-status       inspect queues            [if broker ≠ none]
  /ops-suite:queue-triage       diagnose DLQs             [if broker ≠ none]
  /ops-suite:db-query           run read-only SQL         [if database ≠ none]
  /ops-suite:db-migrate         apply migrations          [if migration_tool ≠ none]
  /ops-suite:port-forward       connect to services       [if orchestrator ≠ none]
  /ops-suite:workflow-deploy    guided interactive deploy [if ci_provider ≠ none]
────────────────────────────────────────────────────