--- name: ck-git description: Git operations with conventional commits, security scanning, and auto-split logic. Use for staging, committing, pushing, creating PRs, merging branches. Embeds the git-manager agent role. --- # ck-git Execute git workflows with conventional commits, security scanning for secrets, and intelligent commit-splitting. Embeds the `git-manager` agent role. ## When to Use - Staging and committing code changes - Pushing to remote branches - Creating pull requests - Merging branches - When user says "commit", "push", or finishes a feature/fix ## Don't Use When - You need to review code before committing — use `ck-code-review` first - Conflict resolution requires understanding the codebase deeply — resolve manually first ## Arguments - `cm`: Stage files and create commits - `cp`: Stage files, create commits, and push - `pr`: Create Pull Request `[to-branch] [from-branch]` - `to-branch`: Target branch (default: main) - `from-branch`: Source branch (default: current branch) - `merge`: Merge `[to-branch] [from-branch]` ## Core Workflow ### Step 1: Stage + Analyze Stage all changes, then review the diff stat and changed file list. ### Step 2: Security Check Scan staged diff for secrets before committing. Look for patterns: `api_key`, `token`, `password`, `secret`, `credential`. **If secrets found:** STOP, warn user, suggest adding to `.gitignore`. ### Step 3: Split Decision **Split commits if:** - Different types mixed (feat + fix, code + docs) - Multiple scopes (auth + payments) - Config/deps + code mixed - More than 10 unrelated files **Single commit if:** - Same type/scope, 3 or fewer files, 50 or fewer lines **Note:** Search for related issues on GitHub and reference them in commit body. ### Step 4: Commit Use conventional commit format: `type(scope): description` **Types:** `feat`, `fix`, `perf`, `docs`, `chore`, `refactor`, `test`, `ci` **Note:** Only use `feat`, `fix`, or `perf` for files in `.claude` directory — do not use `docs` for those. ## Output Format ``` staged: N files (+X/-Y lines) security: passed commit: HASH type(scope): description pushed: yes/no ``` ## Error Handling | Error | Action | |-------|--------| | Secrets detected | Block commit, show files | | No changes | Exit cleanly | | Push rejected | Suggest `git pull --rebase` | | Merge conflicts | Suggest manual resolution | ## Reference Workflows - **Commit**: Stage → security scan → split decision → commit with conventional message - **Push**: Commit → push → handle rejections - **Pull Request**: Analyze remote diff → draft PR title + body → create via `gh pr create` - **Merge**: Switch to target → merge → push ## Safety Rules - Never force push to main/master - Never commit `.env`, credentials, or API keys - Always run security scan before commit - Use `gh` command for GitHub operations (PRs, issues, labels)