Templates

Import managed templates at @latest unless you have a concrete reason to pin. The trade-off:

@latest follows the registry head, and the template-subscription sweep (a background scan every five minutes) pushes new versions to Sync-enabled projects automatically — no human notices or bumps anything. This is how every managed import in this repo is tracked.
A pin (@auto/pr-review@1.5.0/…) opts out of push-apply. Pins are for temporary holds — riding out a version you’re not ready for — not a steady state, because a pinned agent silently stops improving. A pin to a version the deployed registry doesn’t know fails loudly with Agent import not found rather than resolving stale.

Keep the tenant file thin: a name, the managed import, and variables. This repo’s entire production PR reviewer is:

.auto/agents/pr-review.yaml (abridged)

name: pr-review
imports:
  - "@auto/agents@latest/pr-review.yaml"
  - ../fragments/environments/agent-runtime-base.yaml
variables:
  repoFullName: fractal-works/auto
  githubConnection: github-fractal-works

Tailor by overriding, not forking: fields in the importing file win the merge, triggers merge by their authoring name:, and remove: drops inherited tools or triggers. When a followed template moves versions, the next push apply carries non-blocking info diagnostics — template_capability_expanded when the new version added files (review what connections they need), and template_override_outdated when a file you shadow changed upstream (your copy is kept; reconcile it). Read them; they are the upgrade review queue. Details in managed templates. Each reference example in the sidebar ships as a managed template named @auto/<name> — a two-line import plus variables is a complete install. See fragments for layering local overrides on top of template imports.

Get Started

Concepts

Examples

Reference