Communitygithub.com

lguidolin/conventional-commits-and-releases

À utiliser lors des commits, de la rédaction d'un message de commit, de l'ouverture d'une PR qui sera fusionnée par squash, ou de la configuration du versionnement/des changelogs automatiques. Mots-clés — conventional commits, release-please, semver, feat/fix/chore, breaking change, changelog.

Qu'est-ce que conventional-commits-and-releases ?

Cette règle (skill) définit une discipline stricte autour des *Conventional Commits* et du versionnement sémantique automatisé, en liant chaque message de commit à une version publique et un changelog corrects. Elle s'applique à tous les projets utilisant des PR avec squash-merge, release-please et GitHub Actions. La règle exige un format précis (`<type>(<scope>): <description>`) avec des types prédéfinis (`feat`, `fix`, `docs`, `chore`, `refactor`, `test`, `ci/build`), où `feat` déclenche un bump *minor*, `fix` un bump *patch*, et `feat!:` ou un footer `BREAKING CHANGE:` un bump *major*. Elle met en garde contre les erreurs courantes (utiliser `chore` pour une fonctionnalité, négliger le titre de PR, ou tenter d'attribuer une IA). L'application se fait via une CI bloquante : validation du titre de PR (`amannn/action-semantic-pull-request`) et un job dédié rejetant toute attribution IA (`Co-authored-by` ou footer `Generated with [Claude…]`). Les commits de branche ne sont pas lintés (car perdus lors du squash), mais les titres de PR le sont rigoureusement. Un piège connu est qu'un commit *authored* par un compte agent ajoute un `Co-authored-by` après la vérification CI. La règle s'appuie sur l'Article III de la constitution du projet (fichier `engineering-constitution.md`).

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/lguidolin/agent-skills/tree/main/skills/conventional-commits-and-releases
Voir l'original→Voir toutes les compétences

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentation

Conventional Commits et Releases

Vue d'ensemble

Les messages de commit sont une interface lisible par machine, pas seulement de la prose. Le versionnement automatisé et la génération de changelogs les analysent ; un message mal formé produit une version publique erronée ou une release cassée. La discipline dans le petit (un message bien formé) offre gratuitement la correction dans le grand (changelog précis, bon bump de version).

Le format

<type>(<scope>): <description>

TypeEffet / utilisation
featNouvelle fonctionnalité — bump minor
fixCorrection de bug — bump patch
docsDocumentation uniquement
choreMaintenance, dépendances, configuration
refactorChangement de code sans changement de comportement
testTests uniquement
ci / buildModifications du pipeline / système de build
  • Impératif : « ajoute X », pas « a ajouté X » ou « ajoute X ».
  • Breaking changes : feat!: ou un footer BREAKING CHANGE: — déclenche un bump major.
  • Scope facultatif mais encouragé : feat(auth):, fix(db):.

Détails importants

  • Le lien type↔version signifie qu'un feat ou fix mal typé livre une version erronée. Choisissez le type délibérément : « ajouter » = nouvelle fonction, « mettre à jour » = amélioration d'existant, « corriger » = bug.
  • Squash-merge : le titre de la PR devient le commit qui est livré. Il doit lui-même être un Conventional Commit valide, sinon la release est fausse.
  • Voix humaine. Pas d'attribution IA/assistant, pas de ligne Co-authored-by, pas de pied de page généré par. Les commits doivent se lire comme écrits par un humain.

Rationalisations courantes

ExcuseRéalité
« Le message n'a pas vraiment d'importance »Il pilote le changelog et le numéro de version. Il compte mécaniquement.
« chore est assez proche pour cette fonctionnalité »chore ne bump pas la version ; les utilisateurs ne recevront pas votre fonctionnalité dans une release. Utilisez le bon type.
« Je corrigerai le titre de la PR plus tard »En squash-merge, le titre est définitif à la fusion. Corrigez-le avant.
« Un trailer Co-authored-by est inoffensif »La règle du projet interdit l'attribution IA. Aucune exception.

Drapeaux rouges — ARRÊTEZ-VOUS

  • Un message de commit sans préfixe de type
  • Utiliser chore/docs pour quelque chose qui ajoute ou corrige un comportement utilisateur
  • Un titre de PR squash qui n'est pas un conventional commit valide
  • Toute attribution IA ou ligne Co-authored-by

Application :

  • Titre de PR — validé dans la CI, bloquant (amannn/action-semantic-pull-request). En squash-merge, le titre est le commit livré, donc c'est la barrière importante.
  • Attribution IA — un job bloquant No AI Attribution rejette les lignes Co-authored-by nommant Claude/Anthropic et les pieds de page Generated with [Claude…], à la fois dans les commits de la branche et dans le corps de la PR (le corps devient le corps du commit squash). Les lignes Co-authored-by humaines ne sont pas affectées.
  • Corps des commits de branche — délibérément non lintés. Le squash-merge les jette, donc ils n'atteignent jamais le changelog. Si vous passez aux merge commits, ajoutez commitlint.

Faiblesse connue : si un commit est authored par un compte agent, GitHub compose un Co-authored-by au moment du squash — après l'exécution du check de PR. La barrière ci-dessus ne peut pas le voir. Ne committez pas en tant qu'identité agent.

Raison détaillée : Article III de la constitution, embarqué dans 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 associés

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