Communitygithub.com

lguidolin/conventional-commits-and-releases

Útil al realizar commits, escribir mensajes de commit, abrir PRs que se fusionarán squash, o configurar versionado/changelogs automatizados. Palabras clave: conventional commits, release-please, semver, feat/fix/chore, breaking change, changelog.

¿Qué es conventional-commits-and-releases?

Esta habilidad para agentes de IA aplica las reglas de Conventional Commits y versionado semántico automatizado en flujos de trabajo de desarrollo de software. Su objetivo es garantizar que cada mensaje de commit, título de PR y configuración de release produzca versiones y changelogs precisos sin intervención manual. La habilidad soporta plataformas que usan squash-merge (como GitHub) y se integra con herramientas como `amannn/action-semantic-pull-request` y `release-please`. Define un formato estricto (`tipo(ámbito): descripción`), una tabla de tipos con efectos de versionado (feat → minor, fix → patch, etc.), y reglas como el uso del modo imperativo, la prohibición de atribución de IA, y la validación de títulos de PR en CI. También cubre racionalizaciones comunes, banderas rojas y un mecanismo de enforcement que bloquea atribuciones de IA y títulos inválidos, incluyendo una brecha conocida con autores de agente. Es ideal para equipos que desean automatizar releases y mantener un historial de commits limpio y significativo.

Compatible con✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/lguidolin/agent-skills/tree/main/skills/conventional-commits-and-releases
Ver original→Ver todas las habilidades

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentación

Conventional Commits y Releases

Resumen

Los mensajes de commit son una interfaz legible por máquina, no solo prosa. El versionado automatizado y la generación de changelogs los analizan; un mensaje mal formado produce una versión pública incorrecta o un release roto. La disciplina en lo pequeño (un mensaje bien formado) da corrección en lo grande (changelog preciso, incremento de versión correcto) de forma gratuita.

El Formato

<tipo>(<ámbito>): <descripción>

TipoEfecto / uso
featNueva funcionalidad — incremento minor
fixCorrección de error — incremento patch
docsSolo documentación
choreMantenimiento, dependencias, configuración
refactorCambio de código que preserva el comportamiento
testSolo pruebas
ci / buildCambios en pipeline / sistema de construcción
  • Modo imperativo: "añade X", no "añadido X" ni "añade X".
  • Cambios rupturistas: feat!: o un pie BREAKING CHANGE: — provoca un incremento major.
  • Ámbito opcional pero recomendado: feat(auth):, fix(db):.

Detalles Importantes

  • El vínculo tipo↔versión significa que un feat vs fix mal escrito envía una versión incorrecta. Elige el tipo deliberadamente: "add" = nueva funcionalidad, "update" = mejora a existente, "fix" = error.
  • Squash-merge: el título del PR se convierte en el commit que se envía. Debe ser en sí mismo un Conventional Commit válido, o el release será incorrecto.
  • Voz humana. Sin atribución de IA/asistente, sin líneas Co-authored-by, sin pies de página generados. Los commits deben leerse como escritos por un humano.

Racionalizaciones Comunes

ExcusaRealidad
"El mensaje realmente no importa"Conduce el changelog y el número de versión. Importa mecánicamente.
"chore está lo suficientemente cerca para esta funcionalidad"chore no incrementará la versión; los usuarios no recibirán tu funcionalidad en un release. Usa el tipo correcto.
"Arreglaré el título del PR después"En squash-merge el título es definitivo al fusionar. Arrégralo antes.
"Un pie Co-authored-by es inofensivo"La regla del proyecto prohíbe la atribución de IA. Sin excepciones.

Banderas Rojas — DETENER

  • Un mensaje de commit sin prefijo de tipo
  • Usar chore/docs para algo que añade o corrige comportamiento visible para el usuario
  • Un título de PR de squash que no sea un conventional commit válido
  • Cualquier atribución de IA o línea Co-authored-by

Cumplimiento:

  • Título del PR — validado en CI, bloqueante (amannn/action-semantic-pull-request). Al hacer squash-merge, el título es el commit que se envía, por lo que esta es la puerta que importa.
  • Atribución de IA — un trabajo bloqueante No AI Attribution rechaza pies Co-authored-by que mencionen a Claude/Anthropic y pies Generated with [Claude…], tanto en los commits de la rama como en el cuerpo del PR (el cuerpo se convierte en el cuerpo del commit squash). Los pies Co-authored-by humanos no se ven afectados.
  • Cuerpos de commits de rama — deliberadamente sin linting. El squash-merge los descarta, por lo que nunca llegan al changelog. Si cambias a merge commits, añade commitlint.

Brecha conocida: si un commit tiene como autor una cuenta de agente, GitHub compone un pie Co-authored-by al hacer squash — después de que la verificación del PR se haya ejecutado. La puerta anterior no puede detectarlo. No hagas commits como identidad de agente.

Razonamiento completo: Artículo III de la constitución, incluido en engineering-constitution/references/engineering-constitution.md.

Individual skills in this repo

This repo contains 18 individual skills — each has its own dedicated page.

lguidolin/change-hygiene-and-code-craft

Use when writing or refactoring code, structuring a commit or PR, or deciding whether to abstract duplication. Symptoms — mixing reorg with logic changes, a PR doing several things at once, a file growing large, the second copy of similar code, or unsure whether to DRY something up.

lguidolin/cloud-delivery-aks

Use when deploying to Kubernetes or Azure Kubernetes Service (AKS), configuring cloud secrets, setting up progressive rollout/canary, per-PR ephemeral environments, or k8s health probes. Keywords — Kubernetes, AKS, Key Vault, Argo Rollouts, Flagger, canary, blue-green, liveness, readiness, PodDisruptionBudget, HPA, rollback, GHCR.

lguidolin/commit-history-rewrite

Use when an existing repository has messy commit history that needs to conform to conventional commits before adopting release-please, or when intermediate WIP/fixup/merge commits need to be cleaned up.

lguidolin/defense-in-depth-security

Use when handling untrusted input, secrets, authentication/authorization, or dependencies — or threat-modeling a new surface. Keywords — STRIDE, threat model, least privilege, secrets management, supply chain, dependency scanning, input validation, audit log, defense in depth.

lguidolin/designing-before-building

Use when starting a feature, fixing a non-trivial bug, or about to write implementation code — before any code exists. Symptoms you need this: "this is simple, I'll just code it", reaching for the editor before a design is approved, or an idea that hasn't been turned into a spec and plan.

lguidolin/engineering-constitution

Use when starting work in a project that follows the engineering constitution, orienting to its rules, or deciding which engineering practice applies to a task — spec writing, commits, testing, security, deploys, database, or UI work.

lguidolin/graphql-contract-testing

Use when writing a GraphQL query/mutation that the UI and a test will share, or building route/schema contract or smoke tests. Symptoms — copying a query into a test, a test asserting on query text, schema change that didn't break the UI build, or RLS/permission drift. Keywords — graphql-codegen, typed document, contract test, route smoke test.

lguidolin/init-repo-CI

Use when setting up a new repository with conventional commits, release-please, and CI automation, or when retrofitting an existing repository that lacks automated versioning and PR validation workflows.

lguidolin/interface-craft-and-accessibility

Use when building or styling UI — components, layouts, forms, design tokens — or making accessibility decisions. Keywords — a11y, WCAG, keyboard navigation, focus state, contrast, design system, minimalist UI, component reuse, ARIA, semantic HTML.

lguidolin/merge-gates-and-automation

Use when setting up or changing CI, pre-push hooks, or a task runner, or deciding what must pass before merge. Symptoms — tempted to put authoritative checks only in a local hook, skip CI, bypass with --no-verify, or unsure what gates a merge vs. runs locally.

lguidolin/observability-and-slos

Use when adding logging, metrics, tracing, health checks, SLOs, or alerting — or when building a service surface that needs to be operable and debuggable. Keywords — structured logs, OpenTelemetry, correlation id, RED metrics, liveness, readiness, SLI, SLO, error budget, alerting.

lguidolin/performance-and-scale

Use when working on hot paths, list endpoints, pagination, data-access in loops, or public interfaces/schemas. Symptoms — unbounded queries, N+1 access, no latency budget, optimizing without measuring, or changing an interface many consumers depend on. Keywords — pagination, N+1, Hyrum's Law, performance budget, bundle size.

lguidolin/postgres-postgraphile-rls-and-sql

Use when writing PostgreSQL, PostGraphile config, Row-Level Security policies, SQL schema files, or working on the Browser→App→PostGraphile→Postgres data path. Keywords — RLS, SECURITY DEFINER, search_path, pgSettings, grants, roles, GraphQL depth limit, query cost, statement_timeout, SQL file organization.

lguidolin/recording-decisions

Use when a design or architecture decision has been made and needs to be captured — writing a decision record or ADR, updating a decision index, noting a deferred idea, or superseding a past decision. Keywords — ADR, decision record, rationale, rejected alternatives, dependency index.

lguidolin/resilience-and-deploy-safety

Use when planning a deploy, designing a rollback, or responding to an incident or writing a postmortem. Keywords — deploy safety, rollback, immutable artifact, progressive delivery, canary, blast radius, incident response, blameless postmortem, error budget.

lguidolin/ship-it

Use when the user wants to ship work — push, PR, archive decision records, merge, and clean up. Handles the full lifecycle from committing final changes through post-merge cleanup including converting specs/plans to compact decision records.

lguidolin/tests-as-a-control

Use when writing or modifying tests, when a test breaks during a refactor, or when testing permission/role rules. Symptoms — tempted to edit a test to make it pass, testing only the happy path, a deny-test that started passing, flaky tests, or unsure what to assert.

lguidolin/zero-downtime-migrations

Use when changing a database schema where data must survive the change — adding/removing/renaming columns, constraints, indexes, or backfilling. Symptoms — a destructive migration bundled with a code deploy, a NOT NULL column with a backfill, a table-locking UPDATE, or a rename. Keywords — expand/contract, parallel change, backfill, NOT VALID, CREATE INDEX CONCURRENTLY, graphile-migrate.

Skills relacionados

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community