From e68925aada413aa968abdf517e9c44660022fa9e Mon Sep 17 00:00:00 2001 From: Yoshihiro OKUMURA Date: Wed, 9 Sep 2026 12:44:47 +0900 Subject: [PATCH] chore(git-commit): remove git-commit skill from the repository --- .agents/skills/git-commit/SKILL.md | 50 ------------ .../references/conventional_commits.md | 77 ------------------- 2 files changed, 127 deletions(-) delete mode 100644 .agents/skills/git-commit/SKILL.md delete mode 100644 .agents/skills/git-commit/references/conventional_commits.md diff --git a/.agents/skills/git-commit/SKILL.md b/.agents/skills/git-commit/SKILL.md deleted file mode 100644 index 3a6816d..0000000 --- a/.agents/skills/git-commit/SKILL.md +++ /dev/null @@ -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. diff --git a/.agents/skills/git-commit/references/conventional_commits.md b/.agents/skills/git-commit/references/conventional_commits.md deleted file mode 100644 index 20277e3..0000000 --- a/.agents/skills/git-commit/references/conventional_commits.md +++ /dev/null @@ -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 -(): - -[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. |