원클릭으로 Manus에서 모든 스킬 실행

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 저장소 열기 Creator 저장소 보기

다운로드

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.