arthai-marketplace

/arth-setup

Availability: Local is GA for every layer. Per-layer cloud endpoints (telemetry ingest at ingest.getarth.ai, your org’s own arth-memory server) work today; the unified Arth Cloud sign-in (one login for intelligence + memory + router + orchestrate) is pre-GA, /arth-setup says so when you pick cloud.

Set up the whole Arth stack in one command: intelligence (/otel-setup), memory (/memory-setup), router (/router-setup), and decisions (the Jev decision layer, set up internally by the umbrella) behind a single umbrella. Local: pick any subset, zero login. Cloud: sign in once (Google or email SSO) and get all four + orchestrate as one product. Also handles switch and uninstall; both are reversible and never touch data or keys.

Synopsis

/arth-setup
/arth-setup switch <local|cloud|off> [intelligence|memory|router|decisions|all]
/arth-setup switch <off|shadow|enforce> decisions
/arth-setup uninstall [intelligence|memory|router|decisions|all] [--purge-data]

When to use it

You want the whole Arth stack (or any subset of it) set up in one sitting instead of running the per-product setup skills by hand
You’re switching posture, local ↔ cloud ↔ off, for one product or all of them (env rewrite only; data untouched)
You’re removing one or more products and want the removal to be surgical: exactly what setup created, nothing else, data volumes preserved
Not for: configuring a single product with its full option set, go straight to /otel-setup, /memory-setup, or /router-setup; the umbrella delegates to them anyway

Quickstart

/arth-setup

What you’ll see: a per-product state check, then one question, local or cloud? Local: pick any subset of intelligence / memory / router / decisions and each product’s own setup skill runs in sequence (no login anywhere, local services trust your machine). Cloud: one browser SSO sign-in wires all four + orchestrate together. Either way it ends with a combined health line: otel: arth ✓ (:4319) · memory: arth ✓ (local) · router: arth ✓ (:8600) · decisions: jev ✓ (enforce, direct), followed by the links to open: the intelligence dashboard (http://localhost:3100), the router (http://localhost:8600/health), the memory dashboard when a server URL is configured, and the jev.sh stats command for decisions (it has no browser UI). With decisions on, setup also prints a short “Where you will see Jev act” walkthrough: the triage router on your next message, then /qa, /pr, /ci-fix, /implement, /fix, /review-pr, /autopilot and /incident, and where the decision log and stats live. Then open a new session, the env files it wrote load at session start.

Examples

/arth-setup                              # interactive — local/cloud, then (if local) pick a subset
/arth-setup switch off all               # back to the stock toolkit next session; data untouched
/arth-setup switch local router          # re-point just the router at localhost:8600
/arth-setup switch cloud all             # move every product to your org's Arth Cloud (needs ARTH_CLOUD_URL)
/arth-setup uninstall memory             # remove memory's env + MCP entry; prints the compose-down command
/arth-setup switch off decisions         # gates back to today's heuristics next session; key and decision log untouched
/arth-setup switch shadow decisions      # Jev logs only, today's logic decides; asks nothing else
/arth-setup switch enforce decisions     # back to the default: confident answers act from the next session
/arth-setup uninstall all --purge-data   # the only path that can delete data — typed confirmation required

Typical runs:

First time, solo dev → local → tick memory (router is org-shaped , skip it solo, see the router guide) → /memory-setup runs with its own prompts → combined health line
Trying cloud before your org has a deployment → cloud → clear message: “cloud posture requires an Arth Cloud deployment, coming at cloud GA; use local for now” (no cryptic failure)
Leaving → switch off all → next session behaves exactly like a toolkit without Arth; containers and data still there if you come back

Arguments & flags

Argument	Values	Default	What it does
(none)	:	:	Interactive setup: local/cloud question, then (local) product subset. Ticking decisions is the consent for the Jev decision layer: it prints a terminal command for entering the TypeSafe key (never pasted into the chat; probed once), asks one optional question — add a Cloudflare or Vercel backup for outages? — chooses the backend from the keys present, then asks How should Jev decide? (enforce, the default / shadow / off)
`switch`	`local` \| `cloud` \| `off` + optional product	product: `all`	Rewrites ONLY that product’s namespaced env file(s) and re-probes. Never migrates or deletes data. `off` removes the env files: next session is stock toolkit.
`switch`	`shadow` \| `enforce` \| `off` + `decisions`	:	Decisions only: rewrites the `JEV_MODE` line of `.claude/.arth-jev.env` and asks nothing else. `enforce` on a local-runtime backend still resolves to shadow (uncalibrated).
`uninstall`	optional product	product: `all`	Removes env files + the MCP registrations setup created, then prints the per-product compose-down command.
`--purge-data`	:	off	With `uninstall` only: additionally offers to delete data volumes: gated behind an explicit typed confirmation (`purge <product>`). Never implied.

What it does

Detects current state, probes each product independently (health endpoints, env files, markers) with short timeouts; a down service is reported, never an error.
Asks local or cloud, a user-confirmation checkpoint (always asked, never inferred).
Local path, a second user-confirmation checkpoint: a multi-select of intelligence / memory / router / decisions. Each chosen product’s existing setup skill then runs in sequence with its own prompts and confirmations, the umbrella delegates, it doesn’t reimplement. No login anywhere: local services bind localhost and trust the machine boundary. decisions is the one product with no service to run: the checkbox text is the disclosure (hosted sends trimmed diffs and log tails to TypeSafe: no screenshots, no secrets; the local-runtime preset keeps everything on your machine, shadow-only), ticking it is the consent. A missing key is entered in your own terminal: setup prints bash ~/.claude-agents/scripts/arth-keys.sh set TYPESAFE_API_KEY (or the $CLAUDE_PLUGIN_ROOT/scripts/ form), waits on a Done / Skip for now checkpoint, detects the key by name in ~/.arthai/.env (mode 600) and probes it once; the value never passes through the chat. Setup then asks How should Jev decide?, a user-confirmation checkpoint with three answers in this order: enforce (the default: Jev’s confident answers act, today’s logic runs otherwise), shadow (gates log their answer next to today’s decision and change nothing), off (no calls). The answer is written as JEV_MODE in .claude/.arth-jev.env.
Cloud path, no subset: cloud is the integrated product (all four + orchestrate, per-org). If ARTH_CLOUD_URL isn’t configured it stops with a clear “coming at cloud GA” message. If it is: one browser SSO flow (Google OAuth or email magic-link) issues one Arth JWT; the skill writes that one token to ~/.arthai/.env as ARTH_PLATFORM_TOKEN (the single value every Arth service reads, chmod 600) plus the remote URLs into the namespaced env files (confirmed before writing) and verifies all healths in one pass.
Switch / uninstall, reversible by construction: switch touches env files only; uninstall removes exactly what setup created and prints (never silently runs) the compose-down commands. Data volumes require --purge-data plus a typed confirmation.
Finishes with a combined health line per configured service, matching the session-briefing style, and reminds you to open a new session: the namespaced env files only load at session start, so the current session keeps stock behavior until you do.

Everything is fail-open: any product that’s absent or unhealthy simply falls back to today’s toolkit behavior (markdown KB, kg-query, static routing ladder) for that product only, the others keep working.

Output & artifacts

Per-product namespaced env files: .claude/.arth-otel.env (intelligence), .claude/.arth-memory.env (memory), the ARTH_ROUTER_URL key in ~/.claude/settings.json (router), and .claude/.arth-jev.env (decisions: JEV_MODE=<shadow|enforce|off> as chosen at setup, backend, base URL, health), the ONLY things switch rewrites
Whatever the delegated skills produce (containers, markers, MCP entries) , see each product’s own page
A combined health line: otel: arth ✓ · memory: arth ✓ · router: arth ✓ · decisions: jev ✓ (enforce, direct), then one link per configured product to open
On uninstall: the printed per-product compose-down commands (data volumes arthai_data / arth-memory-data / ~/.arthai/arth-router/ are never removed without --purge-data + typed confirmation)

Troubleshooting

Problem	Fix
“cloud posture requires an Arth Cloud deployment: coming at cloud GA”	Expected until your org has a hosted deployment. Use `/arth-setup` → local for now; set `ARTH_CLOUD_URL` and re-run when it ships.
One product’s setup failed mid-run	The umbrella continues with the rest (fail-open). Re-run `/arth-setup`: each delegated skill is idempotent and only redoes what’s missing.
Services show ✗ in the combined health line	Informational, not fatal: that product falls back to stock behavior. Check its container (`docker ps`) or re-run its per-product skill.
Switched posture but sessions unchanged	Env files load at session start: open a new session.
`switch off` but the containers are still running	By design: `off` is a config change, not an uninstall. Run `/arth-setup uninstall <product>` for the printed compose-down command.
Worried uninstall will delete your data	It can’t: data volumes are only touched with `--purge-data` AND an exact typed confirmation (`purge <product>`). Plain uninstall preserves everything.
`decisions: jev ✗ (fallback: heuristics)` in the briefing	The key probe or backend is down; every gate silently takes today’s path. Re-run `/arth-setup` → decisions to re-probe (a dead key is never wired in; `arth-keys.sh unset TYPESAFE_API_KEY` removes it).
Setup printed a command instead of asking for the key	By design: keys are entered in your own terminal (`scripts/arth-keys.sh set <NAME>`), never in the chat. Run it in another window, then pick Done. `arth-keys.sh list` shows which names are stored.
Ticked decisions but nothing in `/qa` changed	You chose shadow: gates log their answer next to today’s decision and change nothing. `/qa-learn` shows the per-question stats. To have confident answers act, `/arth-setup switch enforce decisions` (the setup default), or pick enforce when re-running setup.
Chose enforce but the briefing says `shadow`	Your backend is the local runtime, which is uncalibrated and always resolves to shadow. Switch the stack to `Claude only` or `Claude + one cloud provider` in `/arth-setup` to use the hosted backend.

/otel-setup, intelligence (telemetry + dashboard); the umbrella’s first delegate
/memory-setup, the org decision/memory layer; the umbrella’s second delegate
/router-setup, plan/credit-aware routing; the umbrella’s third delegate
/router, day-to-day router operation once set up
/qa-learn, the per-question Jev decision stats once decisions is on

Router prerequisite: /router-setup needs read access to the private ArthTech-AI/arth-router repo, separate from the plugin-repo invite. Ask productive@getarth.ai before ticking router, or it stops at the clone step.