Atmos Init

Atmos Init

Use this skill for bootstrapping a brand-new Atmos project from the built-in template catalog via atmos init.

atmos init is a thin, project-bootstrap-scoped wrapper around the exact same engine atmos scaffold generate uses (pkg/generator/ui.InitUI). For authoring a new template — custom fields, conditional when: on fields/files, hooks — load atmos-scaffold instead; everything documented there (field types, conditional prompts/files, spec.hooks:, 3-way merge mechanics) applies unchanged to project templates consumed via init. This skill only covers what's specific to init.

Quick Shape

atmos init basic ./my-project
atmos init aws/landing-zone ./my-project
atmos init                          # interactive template + target selection

Built-in templates: basic (minimal cloud-agnostic layout), simple, atmos (atmos.yaml only), aws/app (SDLC repo: dev/staging/prod, native CI, emulator-enabled), aws/landing-zone, gcp/landing-zone, azure/landing-zone. Run atmos scaffold list to see all templates, including remote/catalog ones not built in.

atmos init ships experimental — behavior may change between releases.

Shared Template Contract

Every init template is an AtmosScaffoldConfig, so it uses the same contract as atmos scaffold generate: spec.fields, spec.files, and spec.hooks. Fields and files can use when: predicates or CEL expressions over earlier answers; generation hooks run at before.scaffold.generate or after.scaffold.generate. Scaffold hooks deliberately support only kind: step and ordered kind: steps, even though stack lifecycle hooks support more kinds.

Load atmos-scaffold before authoring or changing any of those template features. It contains the field, CEL, file-condition, hook, and template-context rules that init consumes unchanged.

Differences from atmos scaffold generate

Both share every other flag: --force, --update, --base-ref, --interactive/-i, --set key=value, --source-override (env ATMOS_INIT_SOURCE_OVERRIDE, also accepts ATMOS_SCAFFOLD_SOURCE_OVERRIDE), --ref, --no-git, --merge-strategy, --skip-hooks (env ATMOS_INIT_SKIP_HOOKS) — same semantics as documented in atmos-scaffold.

Project Record

A successful atmos init writes .atmos/scaffold.yaml into the generated project — the same AtmosScaffoldConfig manifest kind, now carrying the user's answers (spec.values) and provenance (spec.source, spec.baseRef). This record makes later atmos init --update re-runs against the same template possible without re-answering every question, and is what --update's 3-way merge uses as the base-ref default source of truth for "what generated this."

Updating an Existing Project

cd my-project
atmos init --update
atmos init --update --merge-strategy=theirs

Same 3-way merge mechanics as atmos scaffold generate --update — see atmos-scaffold's references/merge-strategy.md for the full mechanics (base storage, conflict strategies, the "offer to update instead of failing" interactive prompt, shared verbatim between both commands).

Routing

Guardrails

• atmos init is for consuming the built-in project-template catalog to bootstrap a new repo. Authoring a new template — even one you intend to use via init — is atmos-scaffold territory.
• --git defaults to true here (opposite of scaffold generate) — an accidental atmos init in an existing git repo will create an initial commit unless --no-git is passed.