Skip to main content
Presets are reusable config bundles โ€” task router rules, agent features, theme, instruction files, custom providers โ€” that merge into your AppConfig at boot. Useful for syncing settings across machines, sharing a team setup, or pinning a known-good config to a repo.

Three ways to load

Presets resolve in this order โ€” later wins:
  1. Global โ€” ~/.soulforge/config.json โ†’ presets[]
  2. Project โ€” <cwd>/.soulforge/config.json โ†’ presets[]
  3. CLI โ€” --plugin <spec> (stackable) or SOULFORGE_PRESETS=spec1,spec2

Spec formats

Specs must be at least 2 characters and match ^(https?:\/\/|\.\/|\.\.\/|\/|~\/)|^[a-zA-Z0-9][a-zA-Z0-9._/-]{1,}$. Invalid specs are logged and skipped.

Wizard

Interactive picker โ€” browse the registry, preview overlays, add to global or project scope.

Boot output

By default preset resolution is silent on success. Failures print one short line to stderr (one bad preset never blocks boot โ€” fail-open). For full traces:
Youโ€™ll see one line per spec (ok or fail) with the resolved source.

How merging works

Presets are resolved to plain AppConfig patches, then merged on top of DEFAULT_CONFIG in load order. The diff against defaults becomes the presetOverlay โ€” applied before loadConfig() returns, so every consumer sees the merged shape transparently. Your ~/.soulforge/config.json is never rewritten. Removing the preset entry restores the prior behaviour on next launch.

Authoring

A preset is a JSON file (or registry-hosted JSON) with any subset of AppConfig fields:
Drop it under ~/.soulforge/presets/<name>.json to make it discoverable, or host anywhere reachable by HTTPS.

Environment

See also

  • Configuration โ€” the AppConfig shape presets layer onto.
  • Task router โ€” the most-changed slot in shared presets.