Commit

Commit

Purpose

Create standardized, semantic git commits using the Conventional Commits specification. Analyze the actual diff to determine appropriate type, scope, and message. Enforces project-specific rules: no AI attribution, no ticket references, no emojis.

Quick Reference

• Creates: Git commit with conventional message
• Requires: Staged or unstaged changes

Conventional Commit Format

<type>(<scope>): <subject>

<optional body - 1-2 sentences or omit>

Commit Types

Project Rules (MUST VERIFY)

• Title <= 50 characters
• Title is SPECIFIC (avoid vague: "improve", "enhance", "update")
• NO AI attribution (see policy below)
• NO ticket references in body (no "Fixes #123")
• NO emojis in commit message
• Body: 1-2 sentences max, or omit if title is clear
• Focus on WORK done, not file operations

AI Attribution Policy

STRICTLY FORBIDDEN - Never include ANY of the following in commit messages:

• Co-Authored-By: Claude, Co-Authored-By: GPT, or any AI name
• Any AI-related emojis
• "Generated by", "Created with", or similar phrases
• Any reference to AI tools (Claude, ChatGPT, Copilot, etc.)

Commits must appear as human-authored work. This is a strict project requirement.

Workflow

0. Branch Validation (REQUIRED)

BRANCH=$(git branch --show-current)
if [ "$BRANCH" = "main" ] || [ "$BRANCH" = "master" ]; then
  echo "ERROR: Cannot commit directly to $BRANCH"
  echo "Create a feature branch: git checkout -b <branch-name>"
fi

1. Analyze Changes

git status --porcelain
git diff --staged
git diff

2. Stage Files (if needed)

If nothing is staged, ask user what to stage. Never commit secrets (.env, credentials, private keys).

3. Generate Commit Message

Analyze the diff to determine:

• Type: What kind of change is this?
• Scope: What area is affected? (workflows, scripts, ci, runner, config)
• Description: One-line summary (present tense, imperative mood)

4. User Review

ALWAYS confirm before committing:

1. Show the generated commit message
2. Ask: "Commit with this message? (y/n)"
3. If yes: proceed
4. If no: ask "Any changes I should make?" and revise

5. Execute Commit

git commit -m "<type>(<scope>): <description>"

Examples

Good:

ci(workflows): add dispatch handler for e2e trigger

feat(scripts): add runner provisioning with docker setup

Installs Go, Docker Compose, and Actions runner agent.

fix(runner): correct genvm binary download path

Bad:

• chore(config): update configuration (vague - what update?)
• ci(workflows): improve workflow (vague - how?)
• docs(plans): add implementation plan (focus on file, not work)

Git Safety Protocol

• NEVER commit directly to main/master - always use a feature branch
• NEVER update git config
• NEVER run destructive commands (--force, hard reset) without explicit request
• NEVER skip hooks (--no-verify) unless user asks
• NEVER force push to main/master
• If commit fails due to hooks, fix the issue and create NEW commit (don't amend)

Automation

See skill.yaml for patterns and procedure. See sharp-edges.yaml for common pitfalls.