AgentSkillsCN

commit

严格遵循提交信息的编写规则与风格规范，撰写清晰明了的提交说明。

SKILL.md
--- frontmatter
name: commit
description: Create a commit following message rules and writing style guidelines
license: MIT
compatibility: opencode
metadata:
  category: git

Read current changes and create a proper commit following commit message rules and writing style guidelines.

What This Command Does

Input: None (examines current git state)

Output: A commit with a properly formatted message

Does NOT:

  • •Run tests
  • •Run cleanup commands
  • •Modify code
  • •Stage files (assumes files are already staged or will stage all changes)

Workflow

Step 1: Read Rules

Read the following rules files in order:

  1. •~/.ai/rules/6_commit.md - Commit message rules
  2. •~/.ai/rules/7_writing_style.md - Writing style guidelines

Step 2: Examine Changes

Run these git commands to understand what's being committed:

  1. •

    Check status: git status

    • •See what files are staged/unstaged
    • •Understand overall scope of changes
  2. •

    View diff: git diff HEAD or git diff --cached (if files are staged)

    • •See actual changes being committed
    • •Understand what was added, modified, or removed
  3. •

    Check recent commits: git log -3 --oneline

    • •Understand commit message style in this repo
    • •See what's been done recently for context

Step 3: Determine What to Stage

If files are already staged:

  • •Use staged files as-is

If no files are staged:

  • •Stage all modified/new files: git add -A

Step 4: Draft Commit Message

Following rules from 6_commit.md and 7_writing_style.md:

Structure:

code
[First line: concise description of what changed]

[Optional body: additional context if needed]

> [!NOTE]
> This comment was generated by Claude Code, an AI assistant. Please review it carefully before taking any action.

Rules to follow:

  • •First line: Short, direct, describes final state (not process)
  • •Active voice: "Add feature" not "Added feature" or "Feature was added"
  • •Focus on what changed: Only mention differences from last commit
  • •No process details: Don't mention "first tried X, then Y"
  • •Simple language: Use common words, be direct (per 7_writing_style.md)
  • •No buzzwords: No corporate speak or passive voice
  • •Body optional: Only add if explaining why or if not easily inferred

Step 5: Create Commit

Create the commit using heredoc format for proper formatting:

bash
git commit -m "$(cat <<'EOF'
[Commit message first line]

[Optional body]

> [!NOTE]
> This comment was generated by Claude Code, an AI assistant. Please review it carefully before taking any action.
EOF
)"

Quality Standards

Commit message must:

  • •✅ Describe final state, not process
  • •✅ Use active voice
  • •✅ Be concise and direct
  • •✅ Follow simple writing style (no buzzwords)
  • •✅ Include Claude Code note
  • •✅ Only mention what's different from last commit

Commit message must NOT:

  • •❌ Describe process ("first tried X, then Y")
  • •❌ Use passive voice
  • •❌ Include corporate buzzwords
  • •❌ Be unnecessarily verbose
  • •❌ Mention intermediary steps that were reverted

Examples

Good Commit Messages

code
Add schema hash calculation for cache keys

Prevents stale cache when model structure changes.

> [!NOTE]
> This comment was generated by Claude Code, an AI assistant.
code
Replace manual color selection with random preset

> [!NOTE]
> This comment was generated by Claude Code, an AI assistant.

Bad Commit Messages

code
❌ First tried using reflection, but that didn't work, so switched to Sorbet introspection which works better
(Process archaeology - describes how you figured it out)

❌ The cache key calculation was updated to include schema information
(Passive voice)

❌ Leverage synergies to facilitate comprehensive cache invalidation strategy
(Corporate buzzwords)

❌ Add schema hash, update cache key format, refactor config loader, fix typo in README
(Mentions intermediary changes that should be separate commits or were reverted)

Anti-Patterns to AVOID

DO NOT:

  • •Write commit messages describing your debugging process
  • •Use passive voice ("was added", "has been updated")
  • •Include corporate buzzwords or jargon
  • •Mention changes that were added and then removed in same session
  • •Make commits without examining the actual changes
  • •Write vague messages like "update files" or "fix issues"

DO:

  • •Examine the actual diff before writing message
  • •Use active, direct language
  • •Focus on final state
  • •Be concise but clear
  • •Follow the style of recent commits in the repo
  • •Include body if explaining "why" adds value

Example Session

Starting state:

  • •Modified: bin/cache_helper.rb (added schema hash calculation)
  • •Modified: test/cache_helper_test.rb (added tests for schema hash)
  • •Untracked: None

Command actions:

  1. •Reads commit rules and writing style rules
  2. •Runs git status → sees 2 modified files
  3. •Runs git diff HEAD → sees schema hash code added
  4. •Runs git log -3 --online → sees recent commit style
  5. •Stages all changes: git add -A
  6. •Drafts message: "Add schema hash to cache keys"
  7. •Creates commit with proper format
  8. •Posts confirmation

Output:

code
✅ Commit created: a1b2c3d4 Add schema hash to cache keys

Success Criteria

  • •✅ Commit message follows all rules from 6_commit.md
  • •✅ Writing style matches 7_writing_style.md
  • •✅ Message describes what changed, not how
  • •✅ Active voice used throughout
  • •✅ No corporate buzzwords or jargon
  • •✅ Claude Code note included
  • •✅ Message is concise and direct