Run any Skill in Manus with one click

commit

Stars1

Forks0

UpdatedMarch 17, 2026 at 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.

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

mattrobenolt

mattrobenolt/agent-skills

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	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
)"

More from this repository

same repository

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

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
)"