release

name	release
description	Use when the user wants to release, tag, publish, or deploy a new version to dev. Triggers on "release", "tag", "nueva versión", "bump version", "subir versión", "publicar versión", "deploy dev", "sacar release", or any mention of creating a v* tag. Use this skill whenever the user wants to cut a new version of any Afianza service, even if they don't say "release" explicitly.
allowed-tools	Bash AskUserQuestion

Afianza — Release to Dev

Creates a new version tag in the current service, pushes it, and triggers the CI/CD pipeline that builds and deploys to dev.

Step 1 — Verify context

# Must be in a service repo with a package.json
git rev-parse --show-toplevel
cat package.json | grep '"name"\|"version"'
git branch --show-current

If not on main, warn the user, and also check whether main is actually up to date with the real work — a stale main (e.g. only the raw af-service-template scaffold, with the real changes sitting in an open PR) would mean releasing from main tags the wrong content:

git fetch origin --quiet
git merge-base --is-ancestor <branch> origin/main && echo "merged" || echo "NOT merged"
gh pr list --state open --json number,title,baseRefName

If the branch is not merged and there's an open PR with the real work, ask the user explicitly:

"main no tiene el trabajo de <branch> — está en la PR #, sin mergear. ¿Quieres que la mergee antes de releasear?"

Never merge that PR on a timeout or lack of response — only on an explicit yes. Merging into main is a shared-state action; silence is not consent, even if the user already said "sí, lánzalo" about the release itself (that authorizes the release, not a merge without review).

Check the working tree is clean:

git status --porcelain

If there are uncommitted changes, stop and tell the user to commit or stash them first.

Step 2 — Resolve current version

# Latest git tag
git tag --sort=-version:refname | grep '^v' | head -1

# Version in package.json
node -p "require('./package.json').version"

If there is no tag at all yet, this is the service's first release. Ask the user whether to tag the current package.json version as-is (typical for a brand-new service) or bump it:

"No hay tags previos — es el primer release. ¿Taggeamos v<package.json version> tal cual, o prefieres bumpear primero?"

If a tag exists, compare it with package.json. If they differ (e.g., tag is v0.11.3 but package.json says 0.10.0):

1. Sync package.json to the latest tag without creating a new commit yet:

   npm version <latest-tag-version> --no-git-tag-version
   git add package.json package-lock.json
   git commit -m "chore: sync version to $(git tag --sort=-version:refname | grep '^v' | head -1)"
   git push
   

2. Inform the user: "He sincronizado package.json con el último tag (<tag>) antes de hacer el bump."

Step 3 — Choose bump type

Skip this step if Step 2 already resolved a first-release tag-as-is.

Ask the user:

"¿Qué tipo de bump quieres hacer?

• patch — corrección (0.11.3 → 0.11.4)
• minor — nueva funcionalidad (0.11.3 → 0.12.0)
• major — cambio breaking (0.11.3 → 1.0.0)"

Show the current version and what the resulting tag will be for each option.

Step 4 — Verify GitOps onboarding (first release only)

Every service deploys via GitOps through infra-gitops-state (see gitops-deploy.md). The deploy-to-dev CI job only edits apps/<service>/envs/dev.yaml (yq -i) — it does not create it. If this is the service's first-ever release, confirm the service is already onboarded before tagging, otherwise the pipeline will fail on that step:

1. Check whether infra-gitops-state is cloned locally; clone it if not (git clone https://github.com/afianza-ac/infra-gitops-state.git).
2. Confirm these exist for the service: apps/<service>/values.yaml, apps/<service>/envs/dev.yaml, and an entry in the domain's ApplicationSet (argocd/dev/applicationsets/<domain>.yaml).
3. If missing, stop and tell the user — onboarding (usually a PR to infra-gitops-state) needs to land first. Don't create these files yourself without asking; ApplicationSet list-generator entries and env secrets are typically reviewed.

Step 5 — Create the release

For a normal bump:

npm version <patch|minor|major> -m "chore(release): %s"
git push --follow-tags

For a first release tagged as-is (no package.json bump):

git tag v<version>
git push origin v<version>

npm version updates package.json, creates a commit, and creates the git tag. --follow-tags pushes both the commit and the tag.

Step 6 — Show CI/CD link

# Get the repo remote URL to build the Actions link
git remote get-url origin

Extract the owner/repo from the remote URL and show:

Tag <v0.11.4> pushed. CI/CD en marcha:
https://github.com/<owner>/<repo>/actions

Tell the user: "El pipeline de GitHub Actions se ha disparado. Cuando la imagen esté lista, se desplegará automáticamente en dev. Usa /deploy-prod cuando quieras subir esta versión a producción."