一键在 Manus 中运行任何 Skill

git-commit-formatter

星标2

分支0

更新时间2026年6月5日 09:08

Use this skill to structure and format Git commits. Trigger this whenever you are about to make a commit. This enforces the Atomic Commit Protocol (ACP), ensuring commits are self-contained, tested, documented, and conform to Conventional Commits format.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

shalomb

shalomb/agent-skills

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Commit — Atomic Commit Protocol (ACP)

You must adhere to the Atomic Commit Protocol (ACP) before making any git commit. The ACP guarantees that every commit is a complete, self-contained, and logically indivisible unit of work.

Core ACP Composition Rules

An Atomic Commit MUST contain the following elements. Do not commit until all conditions are met:

One Logical Change: Do NOT mix functional changes with refactoring or formatting. Split unrelated changes into separate commits.
Implementation & Verification:
- You MUST include TDD tests that validate the implementation. At least one test MUST have failed prior to the implementation and pass afterward.
- Run the test suite and confirm it passes. Never commit broken code.
Documentation: You MUST include updates to end-user documentation or inline code comments that reflect the change and explain non-obvious logic.
Cleanliness: You MUST remove all temporary files, build artifacts, debug statements (console.log, print), and leftover comments before committing.
Intentional Staging: Use git add <files> for specific paths. Do NOT use git add . blindly.

For the full formal specification, including rationale and TDD mapping, read: references/acp-spec.md

Commit Message Format

<type>(<scope>): <Summary starting with Capital letter>

<Body explaining the "why", wrapped at 72 chars>

<Impact and Testing evidence>

1. The Header (Subject Line)

Type (Required): feat, fix, docs, refactor, chore, test, perf, style, ci
Scope (Optional): Short noun for the affected area (e.g., auth, api)
Summary (Required):
- MUST be 50 characters or less.
- MUST be in the imperative mood (e.g., "Add feature", not "Added feature").
- SHOULD be Capitalized.
- MUST NOT end with a period.

2. The Body

MUST be separated from the header by a single blank line.
MUST explain the reasoning and context behind the change (the "why"), rather than just repeating what the code does.
SHOULD wrap lines at 72 characters.
SHOULD include an Impact: section and a Testing: section detailing how the code was verified (see Appendix B in the spec for an example).

What NOT to Do

Do NOT add Signed-off-by or sign-off footers unless explicitly requested.
Do NOT include breaking-change markers or BREAKING CHANGE footers unless explicitly requested.
Do NOT push — only commit. The user decides when to push.

Steps Before Committing

Review Diff: Run git diff --cached to catch accidental debug lines or unrelated changes.
Verify Tests: Run tests (e.g., make test, pytest, npm test) and ensure the GREEN state.
Match Conventions: Run git log -n 5 --pretty=format:%s to match existing project style.
Draft Message: Ensure it follows the ACP format and explains the "why".
Commit: Execute the commit. If the change spans multiple logical units, make separate, sequential atomic commits.

同仓库更多 Skills

同仓库

web-to-markdown

shalomb/agent-skills

Convert URLs or local files (PDF/DOCX/PPTX/HTML) to Markdown, with optional summarization. Single or batch processing. Uses markitdown for intelligent extraction, falls back to curl+pandoc. Use when fetching web pages as markdown, converting documents for analysis, or producing quick summaries.

2026-06-052

shalomb/agent-skills

Use `uv` instead of pip/python/venv. Run scripts with `uv run script.py`, add deps with `uv add`, use inline script metadata for standalone scripts.

2026-06-052

bart-adversarial-reviewer

shalomb/agent-skills

Adversarial code reviewer. Use when you need a quality agent to critically review code, a diff, test output, or a pull request — looking for bugs, edge cases, correctness failures, lazy shortcuts, and pattern violations. Works standalone (against any code/diff/worktree) or with GitHub PR mechanics (inline comments, merge decision) when a PR number is provided. Triggers: "bart", "review this", "adversarial review", "code review", "review PR", "find bugs", "QA", "quality check".

2026-06-052

agent-mux

shalomb/agent-skills

Use this skill to orchestrate multiple parallel sub-agents (Ralph/Bart) across isolated git worktrees to burn down a TODO.md backlog. Trigger this when asked to implement multiple independent features simultaneously, dispatch a "wave of agents", or perform "multi-agent orchestration". This handles complex dependency analysis, model spread, and feedback accumulation, which standard dispatch skills cannot.

2026-06-052

claude-sub-agent

shalomb/agent-skills

Launch Claude Code CLI as a headless sub-agent in a tmux pane, monitor its stream-json JSONL output, and poll for completion. Use when delegating a well-defined coding task (bug fix, feature, refactor) to a Claude agent subprocess with live observability. Triggers include "run claude agent", "delegate to claude", "claude sub-agent", or any request to run claude headlessly and monitor it.

2026-06-052

copilot-sub-agent

shalomb/agent-skills

Launch GitHub Copilot CLI as a headless sub-agent in a tmux pane, monitor its JSONL output stream, and poll for completion. Use when delegating a well-defined coding task (bug fix, feature, refactor) to a Copilot agent subprocess with live observability. Triggers include "run copilot agent", "delegate to copilot", "copilot sub-agent", or any request to run copilot headlessly and monitor it.

2026-06-052

name	git-commit-formatter
description	Use this skill to structure and format Git commits. Trigger this whenever you are about to make a commit. This enforces the Atomic Commit Protocol (ACP), ensuring commits are self-contained, tested, documented, and conform to Conventional Commits format.

Commit — Atomic Commit Protocol (ACP)

You must adhere to the Atomic Commit Protocol (ACP) before making any git commit. The ACP guarantees that every commit is a complete, self-contained, and logically indivisible unit of work.

Core ACP Composition Rules

An Atomic Commit MUST contain the following elements. Do not commit until all conditions are met:

One Logical Change: Do NOT mix functional changes with refactoring or formatting. Split unrelated changes into separate commits.
Implementation & Verification:
- You MUST include TDD tests that validate the implementation. At least one test MUST have failed prior to the implementation and pass afterward.
- Run the test suite and confirm it passes. Never commit broken code.
Documentation: You MUST include updates to end-user documentation or inline code comments that reflect the change and explain non-obvious logic.
Cleanliness: You MUST remove all temporary files, build artifacts, debug statements (console.log, print), and leftover comments before committing.
Intentional Staging: Use git add <files> for specific paths. Do NOT use git add . blindly.

For the full formal specification, including rationale and TDD mapping, read: references/acp-spec.md

Commit Message Format

<type>(<scope>): <Summary starting with Capital letter>

<Body explaining the "why", wrapped at 72 chars>

<Impact and Testing evidence>

1. The Header (Subject Line)

Type (Required): feat, fix, docs, refactor, chore, test, perf, style, ci
Scope (Optional): Short noun for the affected area (e.g., auth, api)
Summary (Required):
- MUST be 50 characters or less.
- MUST be in the imperative mood (e.g., "Add feature", not "Added feature").
- SHOULD be Capitalized.
- MUST NOT end with a period.

2. The Body

MUST be separated from the header by a single blank line.
MUST explain the reasoning and context behind the change (the "why"), rather than just repeating what the code does.
SHOULD wrap lines at 72 characters.
SHOULD include an Impact: section and a Testing: section detailing how the code was verified (see Appendix B in the spec for an example).

What NOT to Do

Do NOT add Signed-off-by or sign-off footers unless explicitly requested.
Do NOT include breaking-change markers or BREAKING CHANGE footers unless explicitly requested.
Do NOT push — only commit. The user decides when to push.

Steps Before Committing

Review Diff: Run git diff --cached to catch accidental debug lines or unrelated changes.
Verify Tests: Run tests (e.g., make test, pytest, npm test) and ensure the GREEN state.
Match Conventions: Run git log -n 5 --pretty=format:%s to match existing project style.
Draft Message: Ensure it follows the ACP format and explains the "why".
Commit: Execute the commit. If the change spans multiple logical units, make separate, sequential atomic commits.