تشغيل أي مهارة في Manus بنقرة واحدة

git-commit-assistant

النجوم١٠٨

التفرعات٤٠

آخر تحديث٢ يناير ٢٠٢٦ في ١٠:٢٥

Generate high-quality conventional git commit messages and, with user approval, run the commit. Use when drafting or refining commit messages, validating commit quality, or committing staged work while avoiding noisy histories.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

dmitriiweb

dmitriiweb/extract-emails

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·SOC 15-1252

مستكشف الملفات

2 ملفات

SKILL.md

readonly

name	git-commit-assistant
description	Generate high-quality conventional git commit messages and, with user approval, run the commit. Use when drafting or refining commit messages, validating commit quality, or committing staged work while avoiding noisy histories.

Git Commit Assistant

Quick start

Review staged changes and ensure they cover a single concern.
Choose <type>(optional-scope) and write an imperative 50-72 character summary.
Add body for why/decisions/trade-offs; footers for breaking changes or issue references.
Show the message in a fenced code block, ask for approval to commit, then commit only if approved.
See references/commit_rules.md for full rules and examples.

Workflow

Inspect changes
- Check git status and git diff --cached to confirm what will be committed.
- If changes mix concerns or include formatting noise, ask to split or stage appropriately.
Select type/scope
- Allowed types: feat, fix, refactor, docs, test, chore, build, ci, perf, style.
- Scope is optional; keep it short (e.g., api, auth, deps).
Draft the message
- Summary: imperative, no trailing period, describe what/why, not implementation detail.
- Body (only if valuable): why the change was needed, key decisions, trade-offs; wrap to ~72 chars.
- Footers (when relevant): breaking changes, migration notes, issue references (e.g., Closes #123).
Quality gate
- Message intent must match the staged diff; avoid kitchen-sink commits.
- Do not mix formatting-only changes with functional work.
- Avoid noisy summaries like update, fix stuff, changes, wip.

Confirmation and commit

Present the message in a fenced code block and ask the user to accept.
On approval:
- Confirm staged changes are correct; surface unstaged items before committing.
- Run git commit -m "<summary>" with additional -m "<body>" / -m "<footers>" as needed.
- If the commit fails, report the error and pause for guidance.
If the user declines, revise the message or wait for more information.

Reference

references/commit_rules.md: conventional format, output pattern, quality gate, example output.

المزيد من هذا المستودع

نفس المستودع

agents-md-assistant

dmitriiweb/extract-emails

Inspect a repository and draft an AGENTS.md file using the standard template, capturing commands, structure, and workflow rules.

2026-01-02108

code-review-assistant

dmitriiweb/extract-emails

Perform structured, actionable code reviews for Python code with clear findings and suggestions.

2026-01-02108

debug-logging-assistant

dmitriiweb/extract-emails

Add purposeful debug logging to improve observability without changing behavior.

2026-01-02108

format-lint-assistant

dmitriiweb/extract-emails

Run the project's formatter, linters, and mypy checks in the required order, fixing issues and managing any needed stub dependencies via uv.

2026-01-02108

google-docstring-assistant

dmitriiweb/extract-emails

Write Python docstrings following the Google Python Style Guide, using clear sections and examples.

2026-01-02108

pytest-testing-assistant

dmitriiweb/extract-emails

Write focused pytest tests as standalone functions (one test per function), avoiding test classes.

2026-01-02108

Git Commit Assistant

Quick start

Review staged changes and ensure they cover a single concern.

Choose <type>(optional-scope) and write an imperative 50-72 character summary.

Add body for why/decisions/trade-offs; footers for breaking changes or issue references.

Show the message in a fenced code block, ask for approval to commit, then commit only if approved.

See references/commit_rules.md for full rules and examples.

Workflow

Inspect changes

Check git status and git diff --cached to confirm what will be committed.
If changes mix concerns or include formatting noise, ask to split or stage appropriately.

Select type/scope

Allowed types: feat, fix, refactor, docs, test, chore, build, ci, perf, style.
Scope is optional; keep it short (e.g., api, auth, deps).

Draft the message

Summary: imperative, no trailing period, describe what/why, not implementation detail.
Body (only if valuable): why the change was needed, key decisions, trade-offs; wrap to ~72 chars.
Footers (when relevant): breaking changes, migration notes, issue references (e.g., Closes #123).

Quality gate

Message intent must match the staged diff; avoid kitchen-sink commits.
Do not mix formatting-only changes with functional work.
Avoid noisy summaries like update, fix stuff, changes, wip.

Confirmation and commit

Present the message in a fenced code block and ask the user to accept.

On approval:

Confirm staged changes are correct; surface unstaged items before committing.
Run git commit -m "<summary>" with additional -m "<body>" / -m "<footers>" as needed.
If the commit fails, report the error and pause for guidance.

If the user declines, revise the message or wait for more information.

Reference

references/commit_rules.md: conventional format, output pattern, quality gate, example output.