davila7--claude-code-templates
wehub-resource-sync
1 行
3.3 KiB
JSON
1 行
3.3 KiB
JSON
{"content": "---\nname: commit-smart\ndescription: Analyze staged/unstaged changes and create semantic conventional commits with context about WHY, not just WHAT. Auto-detects commit type and scope from the diff. Supports optional type/scope arguments. Usage - /commit-smart, /commit-smart fix, /commit-smart refactor api\n---\n\n# Smart Commit\n\nCreate meaningful conventional commits by analyzing your actual changes.\n\n## Workflow\n\n### Step 1: Assess the working tree\n\nRun these commands to understand the current state:\n\n```bash\ngit status\ngit diff --stat\ngit diff --cached --stat\n```\n\n### Step 2: Handle unstaged changes\n\nIf nothing is staged (`git diff --cached` is empty):\n\n1. Show the user what files have changed\n2. Suggest what to stage based on logical grouping (e.g., \"these 3 files are all related to the auth refactor\")\n3. Ask if they want to stage all, or select specific files\n4. Stage the approved files with `git add <files>`\n\nIf changes are already staged, proceed to analysis.\n\n### Step 3: Analyze the diff\n\nRead the full staged diff:\n\n```bash\ngit diff --cached\n```\n\nDetermine the commit type from the changes:\n\n| Signal | Type |\n|--------|------|\n| New files with new functionality | `feat` |\n| New test files or test additions | `test` |\n| Changes to existing logic fixing incorrect behavior | `fix` |\n| Structural changes without behavior change | `refactor` |\n| package.json, tsconfig, CI config changes | `chore` |\n| Build/bundler config changes | `build` |\n| README, docs, comments only | `docs` |\n| Formatting, whitespace, semicolons only | `style` |\n| Performance improvements | `perf` |\n\nDetermine the scope from the primary directory or module affected:\n- `src/api/` -> `api`\n- `src/components/auth/` -> `auth`\n- `tests/` -> `tests`\n- Root config files -> omit scope\n- Multiple unrelated areas -> omit scope\n\n### Step 4: Check for user overrides\n\nIf the user provided arguments via `$ARGUMENTS`:\n- Single word (e.g., `fix`) -> use as commit type\n- Two words (e.g., `refactor api`) -> use as type and scope\n- Otherwise -> use auto-detected values\n\n### Step 5: Compose the commit message\n\nFormat: `type(scope): imperative short description`\n\nRules:\n- Subject line max 72 characters\n- Use imperative mood (\"add\", \"fix\", \"refactor\", not \"added\", \"fixes\")\n- Don't end with a period\n- Body explains **WHY** this change was made, not what changed (the diff shows what)\n- If changes are trivial (typo fix, formatting), skip the body\n\nExample:\n```\nfeat(auth): add JWT refresh token rotation\n\nTokens were expiring mid-session for users with slow connections.\nRotating refresh tokens extends the session without compromising\nsecurity, since each refresh token can only be used once.\n```\n\n### Step 6: Confirm and commit\n\nShow the user the proposed commit message and ask for confirmation.\n\nIf confirmed, run:\n```bash\ngit commit -m \"<message>\"\n```\n\nThen verify with:\n```bash\ngit log --oneline -1\n```\n\nShow the committed hash and message.\n\n## Tips\n\n- Run after completing a logical unit of work, not after every file change\n- If the diff is too large for one commit, suggest splitting into multiple commits\n- For breaking changes, add `!` after the scope: `feat(api)!: change response format`\n- The body should answer \"if someone reads this commit in 6 months, will they understand WHY?\"\n"} |