niu/celloc3d.brain.riken.jp
8
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

chore(git-commit): remove git-commit skill from the repository

Browse Source
This commit is contained in:
Yoshihiro OKUMURA
2026-09-09 12:44:47 +09:00
parent 3f684a90b4
commit e68925aada
2 changed files with 0 additions and 127 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agents/skills/git-commit/SKILL.md
-50
View File
@@ -1,50 +0,0 @@
---
description: Analyze repository changes, gather contextual intent from the current codebase status, and generate structurally compliant Git commit messages.
metadata:
github-path: skills/git-commit
github-ref: refs/heads/main
github-repo: https://github.com/orrisroot/agent-skills
github-tree-sha: 332b6fc533ae9085eafbba6827ff7798c85e4b38
name: git-commit
---
# Git Commit Operator
## 1. Purpose
Analyze repository changes, gather contextual intent from the current codebase status, and generate structurally compliant Git commit messages.
## 2. Goals
* **Atomic Evaluation:** Review diffs to ensure changes represent a single, focused utility. Suggest breaking up large, mixed changes into distinct, atomic commits.
* **Contextual Analysis:** Cross-reference physical changes with the recent discussion history to understand not just *what* changed, but *why* it changed.
* **Executable Output:** Provide ready-to-run terminal commands that apply the correct formatting flags, paragraph separators, and line-wrapping behaviors.
## 3. Operational Workflow for Commits
You must execute the following sequential workflow whenever a commit task is initiated or modifications are targeted for staging:
### Step 1: Diff and Intent Inspection
1. Run `git diff --cached` to evaluate the staged modifications.
2. Cross-reference the structural changes against recent code review comments, commit messages, or the active chat context to confirm the primary engineering objective.
3. If those sources do not clearly explain the change, ask one concise clarifying question before generating the draft.
### Step 2: Message Draft Formulation
1. Construct the message draft strictly using the type classifications and syntax limits specified in `references/conventional_commits.md`.
2. Present the drafted structure to the user for validation, highlighting the assigned commit type and scope.
### Step 3: Message Validation
1. After drafting the message in Step 2, validate it against **every rule** listed in `references/conventional_commits.md` before proceeding. Check the following:
* **Type:** The commit type must be one of the allowed types (feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert).
* **Language:** The entire message must be in English (unless the user explicitly requested another language).
* **Case & Punctuation:** The description must be lowercase and must NOT end with a period.
* **Imperative Mood:** The description must use imperative mood (e.g., "add", not "added" or "adds").
* **Line Length:** The subject line must not exceed 72 characters. **Every line in the body must also be wrapped at 72 characters or less.** If any line exceeds this limit, insert line breaks to fix it.
* **`-m` Flags:** The command must use at most three `-m` flags (one per structural part). Body lines must NOT be split across multiple `-m` flags.
* **Literal Newlines:** Multi-line body/footer content must use **literal newlines** inside double-quoted strings, NOT `\n` escape sequences (which shells commit as literal backslash-n).
* **Co-authored-by:** No `Co-authored-by:` trailers unless explicitly requested.
2. If **any** rule is violated, fix the draft and re-validate from step 1. Repeat this loop until all checks pass. Only proceed to Step 4 once the message passes every validation check.
### Step 4: Terminal Command Delivery
1. Upon user confirmation, output the explicit, single-line terminal command using at most three `-m` flags as specified in the formatting policy.
* **CRITICAL:** Use at most one `-m` flag per structural part (Subject, Body, and Footer).
* **NEVER** use multiple `-m` flags for individual lines or bullet points within the body. Doing so causes Git to insert unwanted blank lines.
* **CRITICAL:** For multi-line body or footer content, you must use a single double-quoted string containing **literal newlines (actual line breaks)** within the command. Do NOT use escape sequences like `\n` (which shell command execution will commit literally) or additional `-m` flags.
Process each step in order and complete the current step before moving to the next.
.agents/skills/git-commit/references/conventional_commits.md
-77
View File
@@ -1,77 +0,0 @@
# Reference: Conventional Commits Guidelines
When drafting, validating, or executing Git commits, you must strictly adhere to the specification and specific formatting rules defined below.
## Message Format
```plain
<type>(<scope>): <description>
[optional body]
[optional footer(s)]
```
## Allowed Types
* **feat**: A new feature for the user.
* **fix**: A bug fix for the user.
* **docs**: Documentation only changes.
* **style**: Changes that do not affect the meaning of the code (formatting, missing semi-colons, etc).
* **refactor**: A code change that neither fixes a bug nor adds a feature.
* **perf**: A code change that improves performance.
* **test**: Adding missing tests or correcting existing tests.
* **build**: Changes that affect the build system or external dependencies.
* **ci**: Changes to CI configuration files and scripts.
* **chore**: Other changes that do not modify src or test files.
* **revert**: Reverts a previous commit.
## Strict Constraints
1. **Default Message Language**:
* **The commit message must be written exclusively in English** unless the user provides explicit, specific instructions to use another language for that particular commit.
2. **Line Length Limits**:
* The subject line (first line) must not exceed 72 characters, ideally 50 characters or less.
* **Every single line within the commit message body must also be wrapped at 72 characters or less.** If an explanation runs longer, you must manually insert line breaks to keep each line under the 72-character threshold.
3. **Part Separation via Multiple `-m` Flags (At Most Three)**:
* Use at most one `-m` flag per structural part: the subject line, the body, and the footer. Use at most three `-m` flags in total.
* **NEVER split body lines or bullet lists across multiple `-m` flags.** Doing so inserts unwanted blank lines because Git automatically treats each `-m` flag as a separate paragraph.
* **DO NOT use escape sequences like `\n` in double quotes.** Shells like bash will treat `\n` as literal backslash-n characters and commit them as-is.
* **Use literal newlines (actual line breaks)** inside double quotes to write multi-line bodies or footers.
* *Example:*
```bash
git commit -m "feat(auth): add jwt authentication" -m "Validate tokens on every incoming request.
Secure endpoints by rejecting expired credentials.
- Added middleware for token validation
- Removed legacy session handling" -m "BREAKING CHANGE: The old session-based cookie auth is deprecated."
```
4. **Co-authored-by Restriction**:
* **Do not include any `Co-authored-by:` trailers** in the commit message or footer unless the user explicitly requests you to add credit for a co-author.
5. **Case and Punctuation**:
* The description line must be written in lowercase and must not end with a period.
6. **Imperative Mood**:
* Always use the imperative mood in the description (e.g., use "add", "fix", "change" instead of "added", "fixes", "changed").
## Validation Checklist
When validating a draft commit message, check **every** item below. If any check fails, fix the issue and re-validate until all pass.
| # | Check | Rule |
|---|-------|------|
| 1 | **Type valid** | The type must be one of: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert. |
| 2 | **Language** | The message must be in English (unless the user explicitly requested another language). |
| 3 | **Lowercase** | The description must be lowercase. |
| 4 | **No period** | The description must NOT end with a period. |
| 5 | **Imperative mood** | Use imperative mood (e.g., "add" not "added", "adds"). |
| 6 | **Subject ≤ 72 chars** | The subject line must not exceed 72 characters. |
| 7 | **Body lines ≤ 72 chars** | **Every line in the body must be wrapped at 72 characters or less.** |
| 8 | **At most 3 `-m` flags** | Use at most one `-m` per structural part; do NOT split body lines across multiple `-m` flags. |
| 9 | **Literal newlines** | Multi-line body/footer must use literal newlines inside double quotes, NOT `\n` escape sequences. |
| 10 | **No Co-authored-by** | Do not include `Co-authored-by:` unless explicitly requested. |