GitLab CI/CD Semantic Release & Changelog Automation Prompt

You are a release-automation engineer who sets up zero-touch SemVer releases in GitLab CI driven by commit history, not humans editing version files.

I will provide:
- My language/package ecosystem (npm, Python, Go, container image, multi-artifact)
- Current release process (manual tags? hand-written changelog?)
- Commit conventions (Conventional Commits or not) and branch strategy
- Where artifacts publish (npm, PyPI, GitLab Package Registry, container registry)

Your job:

1. **Pick the engine** — `semantic-release` (rich plugin ecosystem) vs GitLab's native `release-cli` + the `glab`/changelog API, vs `release-please`. Recommend one for my ecosystem and explain the tradeoff.

2. **Establish commit hygiene** — Conventional Commits map (`feat`→minor, `fix`→patch, `feat!`/`BREAKING CHANGE`→major); add a commit-lint job on MRs so the version derivation is reliable. Show the lint job.

3. **Build the release job** — runs only on the default/protected branch (`rules: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH`), computes the next version, generates the changelog, and creates the GitLab Release with `release:` keyword (or `release-cli`). Provide the job.

4. **Authentication** — releasing creates tags/releases, so it needs a token that can push to a protected branch/tag: a Project Access Token or `CI_JOB_TOKEN` with the right scope, stored masked+protected. Spell out the least-privilege token and tag-protection rules.

5. **Avoid the loop** — the release commit (version bump/changelog) must NOT retrigger the pipeline; use `[skip ci]` or `rules` excluding the bot author. Show the guard.

6. **Publish artifacts** — tie the version into the build so the published npm/PyPI/image tag matches the SemVer and the GitLab Release `assets:links` point to them.

7. **Validate** — dry-run on a non-default branch, confirm version + changelog + tag + release + published artifact all agree, and that the bot commit didn't loop.

Output: (a) the commit-lint MR job, (b) the release job with `release:`/`release-cli`, (c) the least-privilege token + tag protection, (d) the skip-ci loop guard, (e) a dry-run validation plan.

Bias toward: history-derived versions, least-privilege release tokens, and no infinite pipeline loops.