commit

name	commit
description	Build verification → Type check → Tests → Git commit workflow. Use when the user wants to commit changes with quality gates. Triggers: "コミット", "commit", "変更をコミットして", "push前の確認".

Commit Skill

Create a git commit with comprehensive pre-commit verification. Prevents buggy code from reaching git history.

Workflow

Execute these steps in order, stopping if any blocking step fails:

1. Build Verification (BLOCKING)

• Run the project's build command (e.g., npm run build)
• If build fails, STOP and fix errors immediately
• DO NOT proceed to commit if build is broken

2. Type Check (BLOCKING)

• Run npm run typecheck or npx tsc --noEmit
• If type errors exist, STOP and fix them immediately

3. Test Execution (NON-BLOCKING)

• Check if test scripts exist in package.json
• If tests exist, run them (e.g., npx vitest run)
• If tests fail, report but allow user to decide whether to proceed
• If no tests exist, skip silently

4. Git Status Review

Run in parallel:

git status
git diff --staged
git diff

• Show what will be committed
• Identify any untracked files that should be staged

5. Stage Changes

• Prefer staging specific files by name rather than git add -A
• Avoid staging: .env, credentials.*, large binaries
• If sensitive files are detected, warn and skip them

6. Create Commit

• Analyze the staged changes thoroughly
• Write a conventional commit message:
  • Format: <type>: <subject> (e.g., feat: add keyboard navigation)
  • Types: feat, fix, refactor, docs, test, style, chore
  • Subject: concise, focus on why not what
• Include co-author line
• Use heredoc for commit message formatting

7. Post-Commit Verification

• Run git status and git log -1 --oneline
• Verify commit succeeded, report hash and message

Important Rules

• NEVER skip build or type check — these are quality gates
• NEVER use --no-verify or bypass git hooks
• NEVER ask clarifying questions — make reasonable decisions and proceed
• If build or type check fails, fix immediately — do not defer to user