Run any Skill in Manus with one click

generate-commit-message

Stars15

Forks5

UpdatedApril 28, 2026 at 06:01

Generate git commit messages from the current repository diff. Use when asked for a commit message, commit summary, or to review staged or unstaged changes before writing a commit message. Always inspect the git diff first and return the suggested message in markdown.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

kaladron

kaladron/galactic-bloodshed

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	generate-commit-message
description	Generate git commit messages from the current repository diff. Use when asked for a commit message, commit summary, or to review staged or unstaged changes before writing a commit message. Always inspect the git diff first and return the suggested message in markdown.
argument-hint	Optional scope such as staged, unstaged, or a note about the intended change
user-invocable	true

Generate Commit Message

Use this skill when the task is to draft a git commit message from the repository state.

Required Behavior

Always inspect the full current repository diff before suggesting a message.
Review both staged and unstaged changes unless the user explicitly narrows the scope.
Start with a repository-wide scope check such as git status --short, git diff --stat, and git diff --cached --stat or equivalent tooling.
If the diff summary is ambiguous, read the changed files or diff hunks before drafting the message.
Make sure the proposed message covers all meaningful changes in the diff, not just the most recent file.
Return the result in markdown.

Procedure

Check the current git changes first. Use repository-wide diff tooling before writing anything.

Minimum check:
```
git status --short
git diff --stat
git diff --cached --stat
```
If that output suggests broader work than a single summary can safely capture, inspect the relevant diff hunks or changed files before drafting.
Identify the real change set. Group the edits into the smallest honest summary that explains what changed and why.
Write an imperative subject line. Keep it concise, specific, and scoped to the actual diff.
Add a body only when it improves clarity. Include the body when the diff has multiple related parts, test updates, refactors, or behavior changes that would be unclear from the subject alone.
Present the result in markdown. Preferred format:

<subject line>

<body paragraphs if needed>

Output Rules

Do not invent changes that are not present in the diff.
Do not summarize only the last file you touched when the repository diff contains broader changes.
Do not omit tests, refactors, or infrastructure changes when they are a material part of the change set.
Prefer one primary commit message suggestion.
If useful, include one short alternate subject line after the primary suggestion.
If there is no diff, say that no commit message can be drafted yet because there are no changes to summarize.

Good Subjects

refactor: add readonly entity list iterators
test: cover readonly ship and entity list iteration
fix: preserve const iteration for inline readonly lists

Notes

Match the repository's existing commit style when it is obvious from context.
If the user asks for a conventional commit, follow that style after reviewing the diff.

More from this repository

same repository

add-field-to-serialized-entity

kaladron/galactic-bloodshed

Add a new field to a persisted entity (Race, Ship, Planet, Sector, ServerState, etc.). Use when extending a struct that is stored as JSON in SQLite, adding a flag/counter/name to an existing entity, or migrating a feature from filesystem state to database state. Covers struct edit, Glaze meta update, default values, optional schema/index changes, and updating call sites and tests.

2026-04-2815

clang-query-refactoring

kaladron/galactic-bloodshed

Use clang-query AST matchers to find every call site that needs to change before a codebase-wide refactor (e.g. migrating direct field access to accessor methods, finding all uses of a deprecated API). Use when a refactor touches dozens of files and grep would over-match, when verifying every mutation site has been migrated, or when planning a safe API change. Covers compile_commands.json setup, writing matchers, running across the tree, and pairing matcher output with replacement.

2026-04-2815

command-implementation

kaladron/galactic-bloodshed

Implement a new player-facing game command in gb/commands/. Use when adding a command, registering a command alias, validating scope/permissions, parsing argv, or producing player output. Covers the command file template, registration in GB_server.cc, CMakeLists wiring, and the standard validate/parse/act/respond structure.

2026-04-2815

database-test-pattern

kaladron/galactic-bloodshed

Write unit tests that exercise EntityManager and repositories against an in-memory SQLite database. Use when adding a *_test.cc file under gb/, verifying database persistence, testing a command end-to-end, or debugging segfaults caused by missing schema initialization. Covers the in-memory DB setup, schema init order, cache-clear verification, GameObj construction in tests, and CMake/CTest wiring.

2026-04-2815

entity-list-iteration

kaladron/galactic-bloodshed

Iterate over collections of game entities (races, stars, planets, ships, commodities) using XxxList helpers. Use when scanning every race/star/planet/ship in a command, turn-processing loop, or test, when deciding between read-only and mutable iteration, or when migrating a numeric for-loop to the entity list pattern. Covers ::readonly() factory, mutable handle iteration, composite-key lists (PlanetList), ShipList iteration modes, and when raw numeric loops are still appropriate.

2026-04-2815

entity-manager-access

kaladron/galactic-bloodshed

Access game entities (races, ships, stars, planets, sectors, commodities) through EntityManager. Use when reading or modifying any persistent game entity in commands, services, or turn processing. Covers peek_* vs get_*, the two-step RAII handle pattern, EntityNotFoundError handling, and validated vs user-input ID rules.

2026-04-2815

name	generate-commit-message
description	Generate git commit messages from the current repository diff. Use when asked for a commit message, commit summary, or to review staged or unstaged changes before writing a commit message. Always inspect the git diff first and return the suggested message in markdown.
argument-hint	Optional scope such as staged, unstaged, or a note about the intended change
user-invocable	true

Generate Commit Message

Use this skill when the task is to draft a git commit message from the repository state.

Required Behavior

Always inspect the full current repository diff before suggesting a message.
Review both staged and unstaged changes unless the user explicitly narrows the scope.
Start with a repository-wide scope check such as git status --short, git diff --stat, and git diff --cached --stat or equivalent tooling.
If the diff summary is ambiguous, read the changed files or diff hunks before drafting the message.
Make sure the proposed message covers all meaningful changes in the diff, not just the most recent file.
Return the result in markdown.

Procedure

Check the current git changes first. Use repository-wide diff tooling before writing anything.

Minimum check:
```
git status --short
git diff --stat
git diff --cached --stat
```
If that output suggests broader work than a single summary can safely capture, inspect the relevant diff hunks or changed files before drafting.
Identify the real change set. Group the edits into the smallest honest summary that explains what changed and why.
Write an imperative subject line. Keep it concise, specific, and scoped to the actual diff.
Add a body only when it improves clarity. Include the body when the diff has multiple related parts, test updates, refactors, or behavior changes that would be unclear from the subject alone.
Present the result in markdown. Preferred format:

<subject line>

<body paragraphs if needed>

Output Rules

Do not invent changes that are not present in the diff.
Do not summarize only the last file you touched when the repository diff contains broader changes.
Do not omit tests, refactors, or infrastructure changes when they are a material part of the change set.
Prefer one primary commit message suggestion.
If useful, include one short alternate subject line after the primary suggestion.
If there is no diff, say that no commit message can be drafted yet because there are no changes to summarize.

Good Subjects

refactor: add readonly entity list iterators
test: cover readonly ship and entity list iteration
fix: preserve const iteration for inline readonly lists

Notes

Match the repository's existing commit style when it is obvious from context.
If the user asks for a conventional commit, follow that style after reviewing the diff.