Skip to main content
ring-generating-release-guides Generating an internal Operations-facing update/migration guide from the git diff between two refs, documenting per-change client impact, deploy ordering, monitoring, and rollback notes in English, pt-br, or both. Use when preparing a version release or recording what changed for the Ops team. Runs read-only by default and previews before writing. Skip with no git repo or a trivial single-file change.
Aller à l'installation Skills Marketplace Découvrez et explorez les compétences IA créées par la communauté.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Afficher les détails du prompt Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
npx skills add https://github.com/LerianStudio/ring --skill ring-generating-release-guidesLa commande reste sur une seule ligne. Faites défiler horizontalement pour la vérifier avant de la copier.
Vous préférez une copie locale ? Téléchargez les fichiers actuellement disponibles dans SkillsMP.
Télécharger Zip Téléchargement... Métiers associés SOC
Basé sur la classification professionnelle SOC
name ring:generating-release-guides description Generating an internal Operations-facing update/migration guide from the git diff between two refs, documenting per-change client impact, deploy ordering, monitoring, and rollback notes in English, pt-br, or both. Use when preparing a version release or recording what changed for the Ops team. Runs read-only by default and previews before writing. Skip with no git repo or a trivial single-file change.
Release Guide — Ops Update Guide Generator
When to use
Preparing to release a new version
Need to document what changed between refs
Creating operational update guide
Communicating version updates to Ops team
Skip when
No git repository available
Single file change (too small for formal guide)
Customer-facing release notes only (use simpler template)
Inputs
BASE_REF (string, required): e.g. main, v1.0.0TARGET_REF (string, required): e.g. HEAD, v1.1.0VERSION (string, optional): auto-detected from tags if not providedLANGUAGE (enum, optional, default en): en, pt-br, bothMODE (enum, optional, default STRICT_NO_TOUCH): STRICT_NO_TOUCH, TEMP_CLONE_FOR_FRESH_REFS
Produce an internal Operations-facing update/migration guide from git diff analysis.
Safety Modes
STRICT_NO_TOUCH (default): Read-only git commands only. Forbidden: fetch,
pull
push
checkout
switch
reset
commit
merge
rebase
TEMP_CLONE_FOR_FRESH_REFS: Clone to temp dir, fetch refs there, run all analysis in clone, cleanup after. Never touches current repo.
Process
Step 0: Execution Location Determine mode. In TEMP_CLONE mode, create isolated clone before proceeding.
Step 1: Resolve Refs git rev-parse --verify BASE_REF^{commit}
git rev-parse --verify TARGET_REF^{commit}
BASE_SHA=$(git rev-parse --short BASE_REF)
TARGET_SHA=$(git rev-parse --short TARGET_REF)
Step 1.5: Version Detection
if git tag -l "$TARGET_REF " | grep -q .; then
AUTO_VERSION=$(echo "$TARGET_REF " | sed -E 's/^[Vv]//;s/^[Rr]elease[-_]?//;s/^[Vv]ersion[-_]?//' )
fi
Step 1.6: Commit Log Analysis git log --oneline --no-merges BASE_REF...TARGET_REF
git log --pretty=format:"%h %s%n%b" --no-merges BASE_REF...TARGET_REF
Parse commit prefixes: feat: → Feature, fix: → Bug Fix, refactor: → Improvement, breaking: / BREAKING CHANGE: → Breaking.
Step 2: Produce Diff git diff --find-renames --find-copies --stat BASE_REF...TARGET_REF
git diff --find-renames --find-copies BASE_REF...TARGET_REF
Step 3: Build Change Inventory From diff, identify: endpoints (new/changed/removed), DB schema/migrations, messaging (topics/payloads), config/env vars, auth changes, performance (timeouts/pools), dependency bumps with runtime impact, observability changes.
Step 4: Write Guide Use language-appropriate template based on LANGUAGE parameter.
English title: # Ops Update Guide — <repo> — <VERSION> — <TARGET_SHA>Portuguese title: # Guia de Atualização (Ops) — <repo> — <VERSION> — <TARGET_SHA>BASE_REF → TARGET_REF instead of <VERSION>)
Header block: Mode, Comparison, Base SHA, Target SHA, Date, Source.
Per section format: ## N. Descriptive Title [Category Emoji]
Category English Portuguese Emoji Feature Feature Funcionalidade ✨ Bug Fix Bug Fix Correção 🐛 Improvement Improvement Melhoria 🆙 Breaking Breaking Breaking ⚠️ Infrastructure Infrastructure Infra 🔧 Observability Observability Observabilidade 📊 Data Data Dados 💾
Each section contains (in order):
Contextual narrative (1-3 paragraphs) — business/operational context, why this changedWhat Changed / O que mudou — bullet list with file:line referencesWhy It Changed / Por que mudou — infer from code; if uncertain mark as ASSUMPTION + HOW TO VALIDATE Client Impact / Impacto para clientes — who's affected, risk level (Low/Medium/High)Required Client Action / Ação necessária do cliente — "None" or exact stepsDeploy/Upgrade Notes / Notas de deploy/upgrade — ordering, rolling deploy safetyPost-Deploy Monitoring / O que monitorar pós-deploy — logs in table format (Level | Message | Meaning), tracing spans in table formatRollback — Safety: Safe/Conditional/Not recommended (or pt-br equivalents) + steps Special sections when applicable:
### ⚠️ Attention Point — confusing but expected behaviorsBackward compatibility table for data/schema changes
Step 5: Summary Section English: Summary table (Features/Bug Fixes/Improvements/Data counts) + Rollback Compatibility matrix (| Item | Rollback | Justification |).
Portuguese: ## Resumo + ## Análise de Compatibilidade de Rollback with same structure.
Step 6: Preview Before Saving (MANDATORY) Show before writing to disk:
Repository, comparison range, version detected, language(s), mode
Change summary table (categories + counts)
Top 5 key changes
Output file path(s)
Wait for user confirmation.
Step 7: Save File Output directory: notes/releases/
Has Version? LANGUAGE Filename Yes en{DATE}_{REPO}-{VERSION}.mdYes pt-br{DATE}_{REPO}-{VERSION}_pt-br.mdNo en{DATE}_{REPO}-{BASE}-to-{TARGET}.mdNo pt-br{DATE}_{REPO}-{BASE}-to-{TARGET}_pt-br.mdAny bothBoth files above
Confirm after saving: file path(s), refs/SHAs used, version, language(s).
Hard Rules Rule Requirement No invented changes MUST: All changes traceable to diff — nothing invented Uncertain info MUST: Mark uncertain claims as ASSUMPTION + HOW TO VALIDATE Preview required MUST: Show preview before saving — never skip User confirmation MUST: Wait for explicit user confirmation before writing files Special change types MUST: Explicitly document DB migrations, breaking API, feature flags, security/auth, log level changes
Blocker Conditions Condition Action Ref cannot be resolved in STRICT mode STOP — suggest TEMP_CLONE mode Not in git repository STOP — skill requires git context diff returns empty STOP — verify refs have commits between them User declines preview STOP — ask for corrections or abort confirmation
Plus depuis ce dépôt ring-declaring-plugin-permissions Interactively authoring an access-manager permission-declaration manifest (permissions.yaml) for the access-manager "inversão de responsabilidade": drives a plugin team through discovering its real Authorize() surface, normalizing every action to the SEMANTIC standard (never HTTP verbs), declaring roles/group grants and the M2M contract, then emits and validates a manifest that matches the lib-auth/v3 auth/declaration schema. Use when a plugin must publish its own permissions at boot (WireFromEnv) instead of the access-manager seed owning them, or when writing/fixing a permissions.yaml. It also bumps the repo's github-actions-shared-workflows CI pin to the release carrying the permission-manifest nudge. Skip when the plugin has no auth guards, or you only need the wiring (see WireFromEnv) and the manifest already exists.
Writing a rolling-wave phased implementation plan from a spec before coding: a phase-epic-task hierarchy where Phase 1 is detailed into dispatch-ready tasks and later phases stay epic-level for elaboration during execution. Use when a multi-file feature needs decomposition; runs after ring:exploring-codebases or pre-dev gates, hands off to ring:executing-plans or ring:running-dev-cycle. Skip for single-file changes or spikes.
Applying or switching a repository's license (Apache 2.0, Elastic License v2, or Proprietary): rewrites the LICENSE file, updates Go/TS source headers, sets SPDX identifiers, and validates consistency after user confirmation. Use when asked to set, apply, or switch a license, or when scaffolding a service with no LICENSE. Skip when license, headers, and SPDX already match, or for non-code repos.
