Terragrunt Skill Generate

Generate Terragrunt skills

Discover releases

1. Use WebFetch to retrieve every page of https://api.github.com/repos/gruntwork-io/terragrunt/releases?per_page=100 needed to cover the previous three years.
2. Treat the Terragrunt GitHub repository as the release authority. Consider only published, non-draft, non-prerelease releases whose tag matches vM.N.0 exactly.
3. Exclude patch releases, release candidates, betas, alphas, development builds, test releases, and moving tags.
4. Use each release's published_at date in ISO YYYY-MM-DD form and keep candidates published on or after the date exactly three years before today.
5. Sort candidates by numeric major and minor version.
6. Check for ../terragrunt-M-N/SKILL.md before retrieving detailed notes. Skip existing version skills without replacing, merging, or regenerating them.

Do not infer releases or dates from schedules, branches, discussions, draft notes, search snippets, tag timestamps, or model memory.

Retrieve official notes

For each missing release, use WebFetch to retrieve its complete GitHub release body. Follow official Terragrunt documentation, migration guides, experiment pages, announcements, and GitHub Discussions only when the release body links them or they unambiguously identify the same M.N release.

Accept official material from:

• github.com/gruntwork-io/terragrunt;
• docs.terragrunt.com;
• legacy terragrunt.gruntwork.io documentation linked by the release.

Keep the GitHub release authoritative for the release version and publication date. Do not use third-party summaries, issue commentary, pull-request descriptions, patch-release notes, or prerelease announcements as substitutes for the stable release body.

Select useful changes

Extract changes that affect how practitioners configure, migrate, validate, plan, or operate Terragrunt:

• HCL blocks, attributes, functions, includes, dependencies, locals, inputs, hooks, and generated files;
• units, stacks, catalog and scaffold workflows, discovery, filters, run queues, DAG behaviour, and execution ordering;
• CLI commands, flags, environment variables, strict controls, logging, reports, and exit behaviour;
• remote state, backend bootstrapping, source retrieval, content-addressable storage, caching, and provider cache behaviour;
• OpenTofu and Terraform invocation, compatibility constraints, argument forwarding, and authentication;
• deprecations, removals, breaking changes, migration requirements, and supported replacements;
• experiments, explicitly labelled with their activation mechanism and stability status;
• security, release verification, and concurrency changes that alter operational decisions.

Leave out ordinary bug fixes, dependency bumps, contributor lists, project news, event announcements, download instructions, documentation-only reorganisation, internal refactors, and performance claims without practitioner impact.

Do not transfer Terraform or OpenTofu release changes into a Terragrunt release skill merely because the Terragrunt test matrix or bundled development dependency changed.

Create the dispatcher

Create ../terragrunt/SKILL.md with the skill-creator initialisation script when it does not exist. Its frontmatter must be:

---
name: terragrunt
description: Configure, review, migrate, and verify Terragrunt orchestration workflows while loading release-specific guidance newer than the model's knowledge cutoff. Use for terragrunt.hcl and terragrunt.stack.hcl files, Terragrunt CLI commands, units, stacks, dependencies, remote state, source management, and OpenTofu or Terraform orchestration.
---

Give the dispatcher these responsibilities:

1. Determine the target Terragrunt binary version from an explicit user request, CI or installation pins, or terragrunt --version, in that order. Never treat terragrunt_version_constraint or terraform_version_constraint as the installed Terragrunt version.
2. Determine the OpenTofu or Terraform binary and version separately whenever compatibility or delegated CLI behaviour matters.
3. Compare the target and model knowledge cutoff with a release table, then load applicable sibling release skills oldest first.
4. Preserve project conventions and consult documentation matching the target Terragrunt version when exact HCL, command, flag, environment-variable, or experiment syntax is uncertain.
5. Use target-version-supported read-only validation, such as terragrunt hcl validate when available. Run plans only when local execution is safe and useful.
6. Never apply, destroy, import, move state, force-unlock, mutate backends, or otherwise change managed infrastructure unless the user explicitly requests it.

Add agents/openai.yaml with display name Terragrunt, short description Build and maintain Terragrunt workflows, and a one-sentence default prompt that explicitly mentions $terragrunt.

Write each release skill

Create ../terragrunt-M-N/SKILL.md with the skill-creator initialisation script and no optional resource directories.

Normalise each description to this exact template, replacing the placeholders with the discovered version and release date:

description: Apply Terragrunt M.N HCL, CLI, orchestration, migration, and behaviour changes. Load for Terragrunt work targeting M.N or later when the model's knowledge may predate the YYYY-MM-DD release.

Keep the description on one physical line. Write a concise factual body that:

1. States that the overview applies to target Terragrunt versions of at least M.N.
2. Explains practitioner-facing capabilities and their relevant situations without prescribing universal adoption.
3. Pairs deprecated or removed HCL, commands, flags, environment variables, and workflows with their supported replacements.
4. Distinguishes Terragrunt behaviour from behaviour delegated to OpenTofu or Terraform.
5. Labels breaking changes, experiments, completed experiments, and stability guarantees at the point they are mentioned.
6. Includes compact HCL or command examples only when needed to clarify syntax or migration.
7. Excludes earlier-version advice unless needed to explain a migration introduced by this release.
8. Contains no claims absent from the official release body or the qualifying official material retrieved for that release.
9. Remains concise enough to load cumulatively with later release skills.

Use descriptive, non-imperative wording in release bodies. Avoid directive openings such as “Use”, “Do”, “Prefer”, “Replace”, “Run”, “Enable”, or “Require”.

Add agents/openai.yaml with display name Terragrunt M.N, short description Apply Terragrunt M.N release guidance, and a one-sentence default prompt that explicitly mentions $terragrunt-M-N.

Register and validate

1. Add a dispatcher table row containing version M.N, the ISO release date, and skill terragrunt-M-N for every generated skill.
2. Preserve rows for existing skills and sort the table by numeric major and minor version.
3. Validate every created skill and the dispatcher with the skill-creator quick_validate.py script.
4. Confirm that every directory name matches its frontmatter name and every agents/openai.yaml default prompt names the corresponding skill.
5. Confirm that every registered date came from the stable GitHub release's published_at value rather than an announcement date.
6. Report existing skipped skills separately from newly generated skills.

If one release fails retrieval, generation, or validation, do not register it; continue with later independent candidates.