engine-setup

engine-setup

Gets someone from nothing to a working home.

Run it once per project. It is also re-runnable, and doctor.py is there as an optional health check when something looks wrong — never a step to clear before work can start.

Paths in this file: shared/… means the gtm home (~/gtm by default, or $GTM_HOME); templates/, inputs/, runs/ and reports/ mean the engine folder you're running, wherever it lives. The scripts resolve both through ~/gtm/engines.json, so read them as names rather than literal paths.

Read the onboarding script first

docs/onboarding.md in the repo is the script for the conversation: what to warn about, what to offer, which question to ask and in what order. Read it before you touch their disk. This file is the mechanics.

What you're building

Three separate things, and keeping them separate is the point:

• The clone (~/.gtm-engine): the engines' logic. One per machine, updated by git pull. Nothing personal in it, nothing to gitignore in anyone's project.
• The home (~/gtm): their brand, accounts, keys, assets, insights, and engines.json. One per person. Never touched by an update.
• The engines: one self-contained folder per channel. These can live anywhere, and where they go is the one real question of setup.

~/.gtm-engine/               the clone (read-only, git pull)
~/gtm/                       the home
├── AGENTS.md  CLAUDE.md
├── engines.json             the registry: every engine and where it lives
├── shared/                  brand, channels, .env, assets, insights
├── published/
└── engines/                 engines kept in one place, named
                             engine-<type>-<project>/
~/.agents/skills/            the skills themselves (step 4)
~/Desktop/                   two symlinks, so neither is buried (step 5)
├── gtm     ->  ~/gtm
└── skills  ->  ~/.agents/skills

Where the engines live

The default is ~/gtm/engines/, and you ask before using it. Not a required-choices screen: one question, with the answer already suggested.