| name | prepare-release |
| description | Use when the user asks to prepare the release of a new version of the terraform provider living in this repository. It will create a new release branch, update the version in the appropriate files, and create a changelog entry with the changes since the last release. |
Terraform Provider Cato Prepare Release Skill
Repository Boundary
Before using this skill:
- Confirm the current workspace is the
terraform-provider-cato repository.
- If the workspace is not this repository, do not apply this skill. Continue with general agent behavior and mention that the skill is repo-scoped.
- If the last commit in the current branch is a release commit, do not apply this skill. Instead, ask the user if they want to release real changes or if they want to update the release notes for the existing release commit.
Goal
Use this skill to prepare the release of a new version of the terraform provider by following the repository's release process.
Required Grounding
Before editing or advising:
- Make sure there are no uncommitted changes in the workspace.
- Make sure the workspace is on the correct branch for releasing (e.g.,
main or master).
Workflow
Follow this order:
- Identify the last release commit and the changes since that commit.
- Determine the next version number based on the changes since the last release following a semantic versioning approach. If the user specified a version number, give it priority and validate that it is greater than the last release version.
- Create a new local branch for the release (e.g.,
release/vX.Y.Z).
- Update the version number in the appropriate files:
GNUmakefile, and main.go.
- Add a new entry to the changelog at the top of the file with the following suggestions:
- Use the new version number and the current date in the format
YYYY-MM-DD for the changelog entry header.
- Use the messages from the commits since the last release to populate the changelog entry. If there are multiple commits, group them into categories (e.g., "Added", "Changed", "Fixed") based on the content of the commit messages. If the commit messages do not clearly indicate the type of change, you can use your judgment to categorize them appropriately.
- Commit the changes with a message like
vX.Y.Z.
- Push the release branch to the remote repository.
- If the github command line is available, use it to create a pull request from the release branch to the main branch with a title like
vX.Y.Z and a description that includes the changelog entry for the new version.
Constraints
Always:
- Make sure the version number is updated in both
GNUmakefile and main.go files.
- Make sure the changelog entry is well-formatted and includes all relevant changes since the last release.
- Ask the user for confirmation while grouping commits into changelog categories if the commit messages are not clear.
Never:
- Modify commit changes to the main or master branch.
- Never approve or merge the release pull request. Only create the pull request and leave it to the user to review, approve, and merge.
Examples
User request that should trigger this skill:
Release a new version of the terraform provider with the latest changes.
Expected changes in code:
@@ -4,7 +4,7 @@ NAMESPACE=catonetworks
PKG_NAME=cato
BINARY=terraform-provider-${PKG_NAME}
# Whenever bumping provider version, please update the version in cato/client.go (line 27) as well.
-VERSION=0.0.73
+VERSION=0.0.75
@@ -1,5 +1,13 @@
# Changelog
+## 0.0.75 (2026-05-18)
+- Fixed license handling for accounts with more than 1,000 sites and added defensive unit coverage.
+- Fixed `translated_subnet` handling for network range, LAN interface, and socket site native ranges to submit nil values correctly when unset.
+- Added broader Terraform acceptance test coverage across provider resources and cleanup workflows.
+- Updated the Cato Go SDK dependency.
+- Hardened socket site update flows with bounded retries for transient backend conflicts and improved connection type hydration.
+- Updated internet and WAN firewall rule hydration to send empty API objects/lists instead of null values for service and action configuration fields.
+
@@ -11,7 +11,7 @@ import (
)
var (
- version string = "0.0.15"
+ version string = "0.0.75"
)