Run any Skill in Manus with one click

Get Started

commit

Stars1

Forks0

UpdatedFebruary 13, 2026 at 20:16

Read this skill before making git commits

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

sergical

sergical/pi-config

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	Read this skill before making git commits
license	From mitsuhiko/agent-stuff

Create a git commit for the current changes using Conventional Commits format with a polished, highly descriptive message.

Format

<type>(<scope>): <summary>

type REQUIRED. Use feat for new features, fix for bug fixes. Other common types: docs, refactor, chore, test, perf.
scope OPTIONAL. Short noun in parentheses for the affected area (e.g., api, parser, ui).
summary REQUIRED. Short, imperative, <= 72 chars, no trailing period.

Notes

Body is strongly encouraged — always include one unless the change is trivially obvious (e.g., fixing a typo). The body should explain what changed, why it changed, the approach taken, and any notable decisions. A reader of git log should understand the change without looking at the diff.
Do NOT include breaking-change markers or footers.
Do NOT add sign-offs (no Signed-off-by).
Only commit; do NOT push.
If it is unclear whether a file should be included, ask the user which files to commit.
Treat any caller-provided arguments as additional commit guidance. Common patterns:
- Freeform instructions should influence scope, summary, and body.
- File paths or globs should limit which files to commit. If files are specified, only stage/commit those unless the user explicitly asks otherwise.
- If arguments combine files and instructions, honor both.

Steps

Infer from the prompt if the user provided specific file paths/globs and/or additional instructions.
Review git status and git diff to understand the current changes (limit to argument-specified files if provided).
(Optional) Run git log -n 50 --pretty=format:%s to see commonly used scopes.
If there are ambiguous extra files, ask the user for clarification before committing.
Stage only the intended files (all changes if no files specified).
Run git commit -m "<subject>" (and -m "<body>" if needed).

More from this repository

same repository

cmux

sergical/pi-config

Manage terminal sessions via cmux — spawn workspaces for dev servers, test runners, and background tasks. Read output, send commands, and orchestrate multi-terminal workflows.

2026-03-131

brainstorm

sergical/pi-config

Structured brainstorming that always follows the full execution chain: investigate → clarify → explore → validate design → write plan → create todos → create feature branch → execute with subagents. No shortcuts.

2026-03-131

visual-tester

sergical/pi-config

Visually test web UIs using Chrome CDP — spot layout issues, interaction bugs, responsive breakage, and produce a structured report

2026-03-131

semantic-compression

sergical/pi-config

Aggressively remove grammatical scaffolding LLMs reconstruct while preserving meaning-carrying content. Output may be fragments. Use when compressing text for prompts, reducing token count, preparing context for LLM input, or making documentation more token-efficient. Applies LLM-aware compression rules that delete predictable grammar while preserving semantics.

2026-03-111

system-prompts

sergical/pi-config

Write system prompts, tool docs, and agent definitions. Combines research-backed prompt engineering (+15-30% measured improvements) with project XML conventions. Covers tag hierarchy, structural templates, high-impact interventions, anti-patterns.

2026-03-111

tmux

sergical/pi-config

Remote control tmux sessions for interactive CLIs (python, gdb, etc.) by sending keystrokes and scraping pane output.

2026-03-091

name	commit
description	Read this skill before making git commits
license	From mitsuhiko/agent-stuff

Create a git commit for the current changes using Conventional Commits format with a polished, highly descriptive message.

Format

<type>(<scope>): <summary>

type REQUIRED. Use feat for new features, fix for bug fixes. Other common types: docs, refactor, chore, test, perf.
scope OPTIONAL. Short noun in parentheses for the affected area (e.g., api, parser, ui).
summary REQUIRED. Short, imperative, <= 72 chars, no trailing period.

Notes

Body is strongly encouraged — always include one unless the change is trivially obvious (e.g., fixing a typo). The body should explain what changed, why it changed, the approach taken, and any notable decisions. A reader of git log should understand the change without looking at the diff.
Do NOT include breaking-change markers or footers.
Do NOT add sign-offs (no Signed-off-by).
Only commit; do NOT push.
If it is unclear whether a file should be included, ask the user which files to commit.
Treat any caller-provided arguments as additional commit guidance. Common patterns:
- Freeform instructions should influence scope, summary, and body.
- File paths or globs should limit which files to commit. If files are specified, only stage/commit those unless the user explicitly asks otherwise.
- If arguments combine files and instructions, honor both.

Steps

Infer from the prompt if the user provided specific file paths/globs and/or additional instructions.
Review git status and git diff to understand the current changes (limit to argument-specified files if provided).
(Optional) Run git log -n 50 --pretty=format:%s to see commonly used scopes.
If there are ambiguous extra files, ask the user for clarification before committing.
Stage only the intended files (all changes if no files specified).
Run git commit -m "<subject>" (and -m "<body>" if needed).