How do I install the Spawn Xtm Suite skill?

Run npx skillmds@latest add mariot/spawn-xtm-suite in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Spawn Xtm Suite safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: reads secrets. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Spawn Xtm Suite?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Spawn Xtm Suite free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Spawn Xtm Suite?

mariot (@mariot) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Spawn Xtm Suite by mariot — Agent Skill

Name: Spawn Xtm Suite
Rating: 4.2 (5 reviews)
Author: mariot

Spawn Xtm Suite

Spins up any combination of the XTM suite — OpenAEV, OpenCTI, or both — each as its own isolated Docker Compose stack with its own XTM Composer instance, from released images or a local build. Use when asked to test the suite end-to-end, run OpenAEV and OpenCTI together, or when the specific platform isn't yet decided.

mariot Updated Sep 22, 2026

File contents

Spawn the XTM suite (OpenAEV, OpenCTI, or both)

When to use this

You want a running instance of the suite to test against — a connector (injector, collector, or executor), cross-product behavior, or just to click through a live deployment — without deciding up front which single platform you need.
You need OpenAEV and OpenCTI running side by side (e.g. testing a connector that talks to both, or comparing behavior across products).

This is a thin wrapper around spawn-openaev-stack and spawn-opencti-stack — use those directly (via scripts/spawn-openaev.sh / scripts/spawn-opencti.sh) if you only ever need one platform. scripts/spawn-suite.sh exists purely to spawn/tear down either or both together under one shared prefix, without you having to remember two separate project names.

Procedure

Pick your stack(s)

# OpenAEV only:
./scripts/spawn-suite.sh up --stack openaev

# OpenCTI only:
./scripts/spawn-suite.sh up --stack opencti

# Both, side by side:
./scripts/spawn-suite.sh up --stack both

Each platform becomes its own isolated compose project (xtm-dev-openaev / xtm-dev-opencti by default), each with its own Docker network, volumes, and XTM Composer instance — the two stacks never collide, and each Composer manages connectors for its own platform only.

Add -p <prefix> to change the shared prefix (useful for running multiple suites side by side, e.g. to compare a PR branch against main):

./scripts/spawn-suite.sh up --stack both -p suite-pr

Build from local checkouts instead of pulling released images

./scripts/spawn-suite.sh up --stack both \
  --build-openaev /path/to/openaev-checkout \
  --build-opencti /path/to/opencti-checkout

You can mix released + local — e.g. only --build-openaev to test an OpenAEV change against a released OpenCTI.

Watching logs / cleanup

./scripts/spawn-suite.sh logs --stack openaev            # --stack both is ambiguous for logs; pick one
./scripts/spawn-suite.sh down --stack both -p xtm-dev

Once it's up

Each spawned stack prints its own URL and admin login/password (openaev.io / opencti.io email domains by default). From there, deploy and test a connector against either platform — see test-with-suite for the full connector-testing walkthrough, including Docker-networking gotchas that apply to both platforms.

---name: spawn-xtm-suitedescription: Spins up any combination of the XTM suite — OpenAEV, OpenCTI, or both — each as its own isolated Docker Compose stack with its own XTM Composer instance, from released images or a local build. Use when asked to test the suite end-to-end, run OpenAEV and OpenCTI together, or when the specific platform isn't yet decided.---# Spawn the XTM suite (OpenAEV, OpenCTI, or both)## When to use this- You want a running instance of the suite to test against — a connector (injector, collector, or executor), cross-product behavior, or just to click through a live deployment — without deciding up front which single platform you need.- You need OpenAEV and OpenCTI running side by side (e.g. testing a connector that talks to both, or comparing behavior across products).This is a thin wrapper around[spawn-openaev-stack](../spawn-openaev-stack/SKILL.md) and[spawn-opencti-stack](../spawn-opencti-stack/SKILL.md) — use those directly(via `scripts/spawn-openaev.sh` / `scripts/spawn-opencti.sh`) if you only everneed one platform. `scripts/spawn-suite.sh` exists purely to spawn/tear downeither or both together under one shared prefix, without you having toremember two separate project names.## Procedure### Pick your stack(s)```bash# OpenAEV only:./scripts/spawn-suite.sh up --stack openaev# OpenCTI only:./scripts/spawn-suite.sh up --stack opencti# Both, side by side:./scripts/spawn-suite.sh up --stack both```Each platform becomes its own isolated compose project(`xtm-dev-openaev` / `xtm-dev-opencti` by default), each with its own Dockernetwork, volumes, and XTM Composer instance — the two stacks never collide,and each Composer manages connectors for its own platform only.Add `-p <prefix>` to change the shared prefix (useful for running multiplesuites side by side, e.g. to compare a PR branch against `main`):```bash./scripts/spawn-suite.sh up --stack both -p suite-pr```### Build from local checkouts instead of pulling released images```bash./scripts/spawn-suite.sh up --stack both \ --build-openaev /path/to/openaev-checkout \ --build-opencti /path/to/opencti-checkout```You can mix released + local — e.g. only `--build-openaev` to test an OpenAEVchange against a released OpenCTI.### Watching logs / cleanup```bash./scripts/spawn-suite.sh logs --stack openaev # --stack both is ambiguous for logs; pick one./scripts/spawn-suite.sh down --stack both -p xtm-dev```## Once it's upEach spawned stack prints its own URL and admin login/password (openaev.io /opencti.io email domains by default). From there, deploy and test a connectoragainst either platform — see[test-with-suite](../test-with-suite/SKILL.md) forthe full connector-testing walkthrough, including Docker-networking gotchasthat apply to both platforms.

Frequently asked questions