The repo must already be registered in config.yaml under repos:
The template must already exist and be listed in config.yaml under templates:
Cargo must be available to build the tmpl8 renderer (for validation)

Usage

# Interactive mode - will ask which template and repo
/enroll-repo-in-template

# Specify template and repo
/enroll-repo-in-template --template shellcheck --repo coreos-assembler

# With variable overrides
/enroll-repo-in-template --template shellcheck --repo coreos-assembler --vars 'branches: [main, rhel-*]'

Workflow

Step 1: Gather Inputs

If the user did not provide arguments, determine the template and repo interactively.

Get the template name:

Read config.yaml and extract the templates: list to show available templates:

grep -A 100 '^templates:' config.yaml

Ask the user which template they want to enable if not specified.

Get the repo name:

Read config.yaml and extract the repos: list to show available repos:

grep -E '^\s{2}\w' config.yaml | sed 's/://g' | awk '{print $1}'

Ask the user which repo they want to enroll if not specified.

Step 2: Validate Prerequisites

Check repo exists in config.yaml:

grep -q "^  REPO_NAME:" config.yaml

If the repo does NOT exist, stop and tell the user to add it first (or suggest running the "onboard-repo" skill if it exists).

Check template is registered:

Verify the template appears in the templates: list in config.yaml.

Check repo is not already enrolled:

For each template config YAML file, check that the repo is not already listed:

grep -q "repo: REPO_NAME" TEMPLATE_DIR/CONFIG.yaml

If already enrolled, inform the user and stop.

Step 3: Identify Template Config Files

Templates may have one or more YAML config files. Determine which ones exist:

ls TEMPLATE_DIR/*.yaml

For example:

shellcheck has script.yaml AND workflow.yaml (both need entries)
gemini has just config.yaml (one entry needed)
dependabot has just dependabot.yaml (one entry needed)

Read each YAML config file to understand:

The default vars: at the top of the file
The path: pattern used by existing entries
Whether entries typically include vars: overrides

Step 4: Determine Entry Details

For each config YAML file:

Determine the path: - Look at existing entries. If all repos use the same path, use that. If paths vary, ask the user.
Determine vars: overrides - Read the template-level vars: defaults. Ask the user if they need to override any variables. Present the available variables and their defaults.
Find insertion point - Entries in the files: list should be in alphabetical order by repo name. Find the correct position.

Step 5: Edit the Config Files

For each template config YAML file, use the Edit tool to insert the new entry.

Format for entry WITHOUT vars overrides:


  - repo: REPO_NAME
    path: OUTPUT_PATH

Format for entry WITH vars overrides:


  - repo: REPO_NAME
    path: OUTPUT_PATH
    vars:
      VAR_NAME: VAR_VALUE

Important formatting rules:

Entries are separated by blank lines
Use 2-space indentation for the - repo: line (under files:)
Use 4-space indentation for path: and vars:
Use 6-space indentation for individual var key-value pairs
Maintain alphabetical order by repo name within the files: list
Match the exact indentation style used by surrounding entries

Step 6: Validate

After making changes, validate the template renders correctly:

# Build the renderer if not already built
cd tmpl8 && cargo build

# Render all templates and show diffs
make diff

Or just render the output tree:

make output

Check that:

No rendering errors occurred
The new repo's rendered file appears in output/REPO_NAME/OUTPUT_PATH
The rendered content looks correct (template variables substituted properly)

Step 7: Report Results

Tell the user:

Which files were modified
What the rendered output looks like
Remind them to commit, PR, and let CI validate

Template Quick Reference

Templates with a single config file (simple):

container/container.yaml -> .github/workflows/container.yml
container/container-rebuild.yaml -> .github/workflows/container-rebuild.yml
copr/Makefile.yaml -> Makefile
dependabot/dependabot.yaml -> .github/dependabot.yml
fcos/release-checklist.yaml -> .github/ISSUE_TEMPLATE/{stream}.md
gemini/config.yaml -> .gemini/config.yaml
go/release-checklist.yaml -> .github/ISSUE_TEMPLATE/release-checklist.md
go/signing-ticket.yaml -> signing-ticket.sh
go/tag_release.yaml -> tag_release.sh
go/tests.yaml -> .github/workflows/go.yml
go/tests-ignition.yaml -> .github/workflows/go.yml
owners-file-action/owners-file-action.yaml -> .github/workflows/owners-file-action.yml
release-notes/require-release-note.yaml -> .github/workflows/require-release-note.yml
rust/release-checklist.yaml -> .github/ISSUE_TEMPLATE/release-checklist.md
rust/rpm-test.yaml -> .github/workflows/rpm-test.yml
rust/tests.yaml -> .github/workflows/rust.yml

Templates with multiple config files (need entries in ALL):

shellcheck/ -> script.yaml (path: ci/shellcheck) + workflow.yaml (path: .github/workflows/shellcheck.yml)
find-whitespace/ -> script.yaml (path: ci/find-whitespace) + workflow.yaml (path: .github/workflows/find-whitespace.yml)
docs/ -> coreos.yaml covers both docs/_config.yml and docs/assets/css/coreos.scss

Checklist Coverage

This skill automates the following manual steps:

Finding the correct template config YAML file(s)
Understanding available variables and defaults
Determining the correct output path
Adding the entry in alphabetical order
Handling multi-file templates consistently
Validating the rendered output

What's NOT covered

Adding a new repo to config.yaml (use the "onboard-repo" skill or do manually)
Creating a brand new template type (different workflow)
Modifying template content (the .yml Tera template files themselves)
Pushing changes to remote or creating PRs

Example Output

When you run /enroll-repo-in-template --template gemini/config --repo fedora-coreos-pipeline:

Validating prerequisites...
  Repo 'fedora-coreos-pipeline' exists in config.yaml
  Template 'gemini/config.yml' is registered in config.yaml
  Repo is not already enrolled in gemini/config

Reading template config: gemini/config.yaml
  Default vars: branches: [main]
  Common path: .gemini/config.yaml
  Config files to update: 1

Adding entry to gemini/config.yaml...
  Inserted after 'fedora-coreos-config', before 'ignition'

Validating render...
  make output completed successfully
  Output file: output/fedora-coreos-pipeline/.gemini/config.yaml

Done! Files modified:
  - gemini/config.yaml (+3 lines)

Next steps:
  1. Review the changes with 'git diff'
  2. Commit and create a PR
  3. CI will validate rendering and show diffs against downstream repos

References

DESIGN.md - Detailed design document with analysis
Example 1 - Simple single-file enrollment
Example 2 - Multi-file enrollment with vars
Example 3 - Enrollment with custom vars
config.yaml - Central registry of repos and templates
README.md - Template system architecture documentation

name	enroll-repo-in-template
description	Enable an existing Tera template for a downstream repo in the repo-templates system