agentleFS
PixiBixiPixiBixi/claude-skills/skills/tf-module-release/SKILL.md

tf-module-release

Skill0 starsChanged 9 days agoApache-2.0View on GitHub

Use right after a Terraform module MR is merged, to tag the new version and bump its callers: "fais le tag & bump module.hcl", "<n> est merge, tag". Not for Helm chart releases.

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Follow the existing tag scheme exactly.

    line 29
  2. Very specific:

    Commit chore(<scope>): bump <module> to <version> with the ticket key, body saying whether the plan is expected to be empty.

    line 54

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Terraform module release

A module version is a signed annotated tag on the default-branch merge commit; callers pin it with ?ref=<version> in their .hcl or .tf source. No CI job tags for you.

1. Tag

In the module's local clone (fetch, never check out the user's branch):

M=~/path/to/module-clone
git -C "$M" fetch origin --tags
B=$(git -C "$M" symbolic-ref --short refs/remotes/origin/HEAD)   # origin/main, origin/master...
git -C "$M" tag --sort=-v:refname | head -3      # the existing scheme: bare X.Y.Z or vX.Y.Z
git -C "$M" log --oneline -5 "$B"
Change since the last tagBump
Removed or renamed input, new required input, resource replaced for existing callersmajor
New optional input or output, new feature, behavior unchanged when unsetminor
Fix, docs, CI onlypatch

Follow the existing tag scheme exactly. Message: subject = the change in one line with the ticket key; body = what callers see, and whether bumping plans no change.

Gate, before any command below: confirm $B is the merge commit of the MR, show the tag name and message, and wait for a yes. A pushed tag is consumed immediately and is never re-pointed. Signed through tag.gpgsign:

VERSION=16.3.0                                   # the version chosen above, in the existing scheme
git -C "$M" tag -a "$VERSION" "$B" -F "$MSG"
git -C "$M" tag -v "$VERSION"
git -C "$M" push origin "$VERSION"

2. Find every caller

On the fetched default branch of each live repo, not the working tree (a stale checkout shows old refs):

L=~/path/to/live-repo
git -C "$L" fetch origin
git -C "$L" grep -n '<module-name>.git' "$(git -C "$L" symbolic-ref --short refs/remotes/origin/HEAD)" -- '*.hcl' '*.tf'

List callers in a table: repo, file, current ref. A caller more than one major behind gets its own decision, never a silent multi-major jump.

3. Bump MR per caller repo

  • Commit chore(<scope>): bump <module> to <version> with the ticket key, body saying whether the plan is expected to be empty. Bump alone: an input change is its own feat() commit. One MR per repo (mr-open).
  • The MR plan (gitlab-job-triage to read it) must match the tag message: "no change" means zero add/change/destroy on every caller unit.
  • In repos that apply on merge, merging is the user's call.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.