Compose Templates

Keep your team’s shared task breakdowns in one place. Start with a base Template, add the task groups you need, and inspect the result before generating Tasks.

This guide explains composition behaviour. For field types, requirements, and defaults, use the Schema Reference.

Composition combines reusable task breakdowns into a Resolved Template. Use a base Template for the common structure and Mixins for task groups that several Templates share. The same composition rules apply wherever Atomize resolves an Atomize YAML File.

Inheritance (extends)

A template that declares extends inherits the filter, tasks, estimation, validation, and metadata of its base. Fields defined in the child override the corresponding fields in the base.

formatVersion: "1.0"
name: "Secure Backend API"
extends: "backend-api"        # inherits all tasks and filter from backend-api

tasks:
  - id: "pen-test"
    title: "Penetration Testing"
    estimationPercent: 10
    activity: "Testing"

The Resolved Template combines the child's tasks list with the base's, then re-validates the combined result. Inspect that result before generating Tasks so you can check both inherited and directly defined content.

Mixins (mixins)

A mixin is a partial template (typically a group of related tasks) that can be mixed into any template. The tasks from all listed mixins are appended to the template's own task list before validation.

formatVersion: "1.0"
name: "Feature With Release Checks"
extends: "feature"
mixins:
  - "security-review-tasks"
  - "release-checklist"

A Mixin file may only contain formatVersion, version, name, description, tasks, and origin. That's also how Atomize tells a standalone file apart: a file whose root keys all belong to that list is validated as a Mixin; any other root key (filter, extends, estimation, …) makes it a Template. A file referenced from mixins: is always read as a Mixin, and one referenced from extends: as a Template.

Templates and Mixins are both Catalog items. Make each referenced item available in the Template Library before resolving the composed Template. See Template Creation for authoring and Catalog workflows.

Resolution order

When Atomize processes a composed template:

1. Base template (extends) is loaded and fully resolved first
2. Mixin task lists are appended in declaration order
3. Child template fields override the merged base
4. The final result is validated as a single flat template

The Resolved Template is the content Atomize validates and uses for Task generation. Inspecting it does not create Tasks.

Inspect composition in your tool

Choose the workflow for the tool you use; a separate CLI installation is not required by the VS Code extension.

Tool	Inspecting a composed Template
VS Code extension	Open the Atomize YAML File and run Atomize: Show Effective Template to see its Resolved Template. The source keeps its inheritance and Mixin declarations. See the extension command guide.
CLI	Use atomize template resolve <template> to print the Resolved Template without changing the source. See the resolve command reference for options and exporting resolved YAML.

Compatibility

The CLI first supported extends and mixins in version 2.0.0. That historical CLI requirement is not a minimum version for the VS Code extension: each tool has its own version. Use the Schema Reference inside the extension for the format supported by your installed version. When sharing with an older tool that cannot resolve composition, upgrade it or share a flattened Resolved Template instead.

Look up composition fields

• extends: the base Template to inherit.
• mixins: reusable task groups to compose.

A file’s own fields are explained in Template structure, filters, tasks, and estimation.