commit-message

Estrellas9

Forks1

Actualizado21 de julio de 2026 a las 11:28

Produce a Conventional Commits message for SolTechnology.Core, using module names as scopes and surfacing semver impact in the footer.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Fuente

AdrianStrugala

AdrianStrugala/SolTechnology.Core

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

SKILL.md

readonly

name	commit-message
description	Produce a Conventional Commits message for SolTechnology.Core, using module names as scopes and surfacing semver impact in the footer.

Commit Message

Generate a commit message that matches the SolTechnology.Core convention.

Format

<type>(<scope>): <imperative summary, <= 72 chars>

<optional body — what and why, wrapped at 100 chars>

<optional footers>

Types

Type	Meaning
`feat`	New user-visible capability
`fix`	Bug fix
`refactor`	Behaviour-preserving change
`perf`	Performance improvement
`test`	Tests only
`docs`	Docs only (architecture, feature records, READMEs)
`build`	Build / packaging / `Directory.Build.props`
`ci`	CI workflow under `.github/workflows/`
`chore`	Repo housekeeping with no other category

Scopes

Use the module name in lowercase, dropping soltechnology.core.:

api, api-testing, apiclient, auid, auth, blob, cache, cqrs, faker, flow, guards, http, jobs, journey, logging, messagebus, scheduler, sql, story.

Cross-module: core (multiple modules) or repo (root files only). Sample apps: dreamtravel, talecode, elsa. Meta: docs, architecture, features, skills, build, ci.

Rules

Subject in imperative mood ("add", not "added"/"adds").
No trailing period in the subject.
Body explains what and why, never how — the diff already shows how.
Semver footer is mandatory for any change touching public symbols in src/SolTechnology.Core.*:
- Semver: PATCH — internal only / docs / tests.
- Semver: MINOR — additive public API.
- Semver: MAJOR — breaking public API. Must also include a BREAKING CHANGE: <one-line description> footer and reference the dated feature record that explains the rationale and migration.
Reference the premortem output in the body when the change required one.
No issue tracker IDs unless the user supplies them.

Process

Read the staged diff (git diff --cached).
Pick the narrowest type that fits. If two types apply, split the commit.
Pick the scope from the touched module(s). If more than two modules, use core.
Write the subject (imperative, ≤72 chars).
If non-trivial, add a body. Lead with the user-visible effect.
Add the semver footer when applicable. Add BREAKING CHANGE: when MAJOR.
Re-read against the rules above before printing.

Output format

<type>(<scope>): <subject>

<body>

Semver: PATCH | MINOR | MAJOR
BREAKING CHANGE: <only if MAJOR>

Examples

feat(story): persist interactive step inputs across host restart

Interactive workflows previously lost user-supplied inputs when the worker
process restarted between steps. Inputs are now serialized with the rest
of the story state under the existing storage contract.

Semver: MINOR

refactor(cqrs)!: return Result.Failure instead of throwing in pipeline

The MediatR pipeline behaviour now surfaces validation errors as
Result.Failure values, aligning with §3 of the Coding Guide. Consumers
that previously caught ValidationException must switch to inspecting
Result.IsFailure.

Semver: MAJOR
BREAKING CHANGE: ValidationException no longer thrown from CQRS pipeline.
See docs/features/2026-07-21-cqrs-validation-result.md.

Más de este repositorio

mismo repositorio

code-review

AdrianStrugala/SolTechnology.Core

Review a SolTechnology.Core change against the Tale Code philosophy, ClaudeCodingGuide rules, and module conventions.

2026-07-229

premortem

AdrianStrugala/SolTechnology.Core

Imagine the change has shipped exactly as planned and broken production; write concrete failure stories, then sweep SolTechnology.Core module checklists for what the stories missed. Produces a Go / Go-with-mitigations / No-Go verdict. Runs as the 00 gate of a plan, always in a session that did not author the plan.

2026-07-229

blue-red-team

AdrianStrugala/SolTechnology.Core

Evaluate a SolTechnology.Core design choice from supportive and skeptical perspectives. Records alternatives in the dated feature brief and informs current architecture after delivery.

2026-07-219

command-query-event-tale

AdrianStrugala/SolTechnology.Core

Author a use case in any app built on the `SolTechnology.Core.CQRS` / `SolTechnology.Core.Tale` NuGet packages — a command, a query, a fire-and-forget event, or a Tale (chapters). Covers simple handlers, Tales hosted in `Commands`/`Queries`, domain-model Tales in `DomainServices`, and long-running interactive Tales in `Workflows`. Use whenever adding a new command/query/event, promoting a handler past the §3 size budget into a Tale, adding a chapter, publishing or handling an `IEvent`, wiring a handler into a `ModuleInstaller`, or adding `[LogScope]` logging. Encodes the layout and rules from `ClaudeCodingGuide.md` §0/§3/§4/§11 and the DreamTravel reference app. Routes tests to `test-writing`, review to `code-review`, behaviour-preserving cleanup to `refactor`.

2026-07-219

dependency-audit

AdrianStrugala/SolTechnology.Core

Resolve a NU1901–NU1904 CVE warning, an NU1605 downgrade, or a transitive vulnerability in SolTechnology.Core. Drives the parent-lookup → fix-at-source → override-only-as-last-resort flow from CLAUDE.md §6. Companion to `package-management` (which only handles "add a package").

2026-07-219

documentation-cleanup

AdrianStrugala/SolTechnology.Core

Validate and fix documentation integrity in SolTechnology.Core — current architecture, dated feature records, module/doc parity, indexes, tables, Mermaid diagrams, links, and numbered lists.

2026-07-219

Commit Message

Generate a commit message that matches the SolTechnology.Core convention.

Format

<type>(<scope>): <imperative summary, <= 72 chars> <optional body — what and why, wrapped at 100 chars> <optional footers>

Types

Type

Meaning

feat

New user-visible capability

fix

Bug fix

refactor

Behaviour-preserving change

perf

Performance improvement

test

Tests only

docs

Docs only (architecture, feature records, READMEs)

build

Build / packaging / Directory.Build.props

ci

CI workflow under .github/workflows/

chore

Repo housekeeping with no other category

Scopes

Use the module name in lowercase, dropping soltechnology.core.:

api, api-testing, apiclient, auid, auth, blob, cache, cqrs, faker, flow, guards, http, jobs, journey, logging, messagebus, scheduler, sql, story.

Cross-module: core (multiple modules) or repo (root files only). Sample apps: dreamtravel, talecode, elsa. Meta: docs, architecture, features, skills, build, ci.

Rules

Subject in imperative mood ("add", not "added"/"adds").

No trailing period in the subject.

Body explains what and why, never how — the diff already shows how.

Semver footer is mandatory for any change touching public symbols in src/SolTechnology.Core.*:

Semver: PATCH — internal only / docs / tests.
Semver: MINOR — additive public API.
Semver: MAJOR — breaking public API. Must also include a BREAKING CHANGE: <one-line description> footer and reference the dated feature record that explains the rationale and migration.

Reference the premortem output in the body when the change required one.

No issue tracker IDs unless the user supplies them.

Process

Read the staged diff (git diff --cached).

Pick the narrowest type that fits. If two types apply, split the commit.

Pick the scope from the touched module(s). If more than two modules, use core.

Write the subject (imperative, ≤72 chars).

If non-trivial, add a body. Lead with the user-visible effect.

Add the semver footer when applicable. Add BREAKING CHANGE: when MAJOR.

Re-read against the rules above before printing.

Output format

<type>(<scope>): <subject> <body> Semver: PATCH | MINOR | MAJOR BREAKING CHANGE: <only if MAJOR>

Examples

feat(story): persist interactive step inputs across host restart Interactive workflows previously lost user-supplied inputs when the worker process restarted between steps. Inputs are now serialized with the rest of the story state under the existing storage contract. Semver: MINOR

refactor(cqrs)!: return Result.Failure instead of throwing in pipeline The MediatR pipeline behaviour now surfaces validation errors as Result.Failure values, aligning with §3 of the Coding Guide. Consumers that previously caught ValidationException must switch to inspecting Result.IsFailure. Semver: MAJOR BREAKING CHANGE: ValidationException no longer thrown from CQRS pipeline. See docs/features/2026-07-21-cqrs-validation-result.md.