Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

commit

Estrellas1

Forks0

Actualizado17 de marzo de 2026 a las 18:54

Write concise git commit messages and commit staged changes. Trigger when the user says "commit this", "commit that", "make a commit", "commit the changes", or any instruction to create a git commit. Do NOT auto-stage files — only commit what is already staged.

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.

Ejecutar en Manus

Fuente

mattrobenolt

mattrobenolt/agent-skills

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

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
description	Write concise git commit messages and commit staged changes. Trigger when the user says "commit this", "commit that", "make a commit", "commit the changes", or any instruction to create a git commit. Do NOT auto-stage files — only commit what is already staged.

Commit

Workflow

Run git diff --cached to see what's staged
If nothing is staged, tell the user and stop
Run git log --oneline -10 to see recent message style in this repo
Write a commit message following the rules below
Commit with git commit

Commit Message Rules

Write the message as a single short line. Target under 50 characters, hard max 72.

Voice and tone:

Write like a human jotting a note, not an AI summarizing a diff
Lowercase unless a proper noun
No period at the end
Imperative mood ("fix crash" not "fixed crash" or "fixes crash")

Content:

State what changed at a high level, not how
One line. No body, no bullet lists, no paragraphs
Only add a body (separated by blank line) if the change is genuinely complex AND the "why" isn't obvious from the diff — this should be rare
When a body is warranted, keep it to 1-3 short sentences. Never bullet lists.

What to avoid:

Never list files or functions changed
Never describe every individual change
Never use filler like "various improvements" or "minor updates"
Never use prefixes like feat:, fix:, chore: unless the repo already uses them (check git log)
Never wrap the message in quotes when passing to git commit -m

Examples

Good:

fix null pointer in session cleanup
add rate limiting to auth endpoints
remove unused profile migration
handle timeout when upstream is slow
update parser for new v3 schema

Bad:

Fix: Updated the session cleanup handler to properly check for null pointers before accessing session data (too long, too detailed)
feat: add rate limiting (prefix not needed)
Various improvements to auth and session handling (vague filler)
Update files (meaningless)

Commit Command

Always pass the message via heredoc to preserve formatting:

git commit -m "$(cat <<'EOF'
message here
EOF
)"

Más de este repositorio

mismo repositorio

zig-review

mattrobenolt/agent-skills

Comprehensive Zig code review across all quality dimensions. Triggers on /zig-review. Runs parallel subagents — each using an existing skill — for Tiger Style compliance, Zig 0.15 idiom correctness, deslop, simplification opportunities, and API design quality. Always operates on the full branch diff against main. Report-only: never makes changes.

2026-03-261

deslop

mattrobenolt/agent-skills

Remove AI-generated slop from code changes. Use when the user says "deslop", "remove slop", "clean up AI comments", or wants to strip unnecessary AI-added comments from a branch's diff. Works with any language, optimized for Go and Zig codebases.

2026-03-251

tiger-style

mattrobenolt/agent-skills

TigerBeetle's coding style guide for writing safe, performant Zig code. Enforces strict safety rules (assertions, bounded control flow, static memory), performance discipline (mechanical sympathy, batching), and naming/formatting conventions. Use this skill when: (1) Writing or generating Zig code — apply Tiger Style rules during generation, (2) Reviewing Zig code — run a detailed review against all Tiger Style principles, (3) User asks about Tiger Style conventions, naming, assertions, or formatting. Triggers on: writing Zig code, code review requests, style questions, "tiger style", "tiger review".

2026-03-251

zig

mattrobenolt/agent-skills

Write correct, idiomatic Zig 0.15 code. Use when writing new Zig code, editing existing Zig files, debugging Zig compilation errors, reviewing Zig code, or working with build.zig files. Triggers on any task involving .zig files. Critical: LLM training data contains outdated Zig patterns (0.11-0.13) that will produce broken code — this skill provides the current 0.15 patterns.

2026-03-251

skill-creator

mattrobenolt/agent-skills

Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.

2026-03-171

nix-devshell

mattrobenolt/agent-skills

Work within Nix flake-based devShells. Use when working in any project that has a flake.nix, when commands fail due to missing tools, when dependencies need to be added or removed, or when setting up a development environment. Triggers on flake.nix presence, missing command errors, or dependency management tasks. IMPORTANT — always prefer the devShell over installing tools globally or via pip/npm/brew.

2026-03-171

Commit

Workflow

Run git diff --cached to see what's staged

If nothing is staged, tell the user and stop

Run git log --oneline -10 to see recent message style in this repo

Write a commit message following the rules below

Commit with git commit

Commit Message Rules

Write the message as a single short line. Target under 50 characters, hard max 72.

Voice and tone:

Write like a human jotting a note, not an AI summarizing a diff

Lowercase unless a proper noun

No period at the end

Imperative mood ("fix crash" not "fixed crash" or "fixes crash")

Content:

State what changed at a high level, not how

One line. No body, no bullet lists, no paragraphs

Only add a body (separated by blank line) if the change is genuinely complex AND the "why" isn't obvious from the diff — this should be rare

When a body is warranted, keep it to 1-3 short sentences. Never bullet lists.

What to avoid:

Never list files or functions changed

Never describe every individual change

Never use filler like "various improvements" or "minor updates"

Never use prefixes like feat:, fix:, chore: unless the repo already uses them (check git log)

Never wrap the message in quotes when passing to git commit -m

Examples

Good:

fix null pointer in session cleanup

add rate limiting to auth endpoints

remove unused profile migration

handle timeout when upstream is slow

update parser for new v3 schema

Bad:

Fix: Updated the session cleanup handler to properly check for null pointers before accessing session data (too long, too detailed)

feat: add rate limiting (prefix not needed)

Various improvements to auth and session handling (vague filler)

Update files (meaningless)

Commit Command

Always pass the message via heredoc to preserve formatting:

git commit -m "$(cat <<'EOF' message here EOF )"