hasna/skill-scancommitpush

Scan, Commit & Push

Scan the entire repository for changes, group them into logical commits, write high-quality commit messages, and push to GitHub. This skill does NOT create a pull request.

Step 1: Pre-flight Checks

1. Verify git repo: Run git rev-parse --git-dir. If not a git repo, stop and inform the user.

2. Check for merge conflicts: Run git diff --name-only --diff-filter=U. If any files listed, stop: "There are unresolved merge conflicts in: [list]. Please resolve them before committing."

3. Check current branch: Run git branch --show-current. Note the branch name. If detached HEAD, warn the user and ask whether to proceed.

4. Check remote: Run git remote -v. If no remote configured, stop: "No git remote configured. Add one before pushing."

5. Check upstream: Run git rev-parse --abbrev-ref @{upstream} 2>/dev/null. If no upstream, you'll need git push -u origin <branch> later.

Step 2: Scan All Changes

1. Run git status (never use -uall flag). Note staged changes, unstaged modifications, and untracked files.

2. Run git diff --stat for unstaged modification summary.

3. Run git diff --cached --stat for staged change summary.

4. If NO changes exist (nothing staged, unstaged, or untracked): "Working tree is clean. Nothing to commit." Stop.

5. Detect sensitive files and EXCLUDE from commits:

   • .env, .env.* (environment files)
   • *.pem, *.key, *.p12 (private keys)
   • credentials.json, service-account*.json
   • .secrets/, secrets/
   • Files containing API keys or tokens

   Warn: "Found potentially sensitive files that will NOT be committed: [list]. Add them to .gitignore if needed."

Step 3: Group Changes into Logical Commits

Do NOT create one giant commit. Analyze changes and group them into logical, atomic commits.

Grouping Rules (in priority order)

1. By feature/functionality: Changes implementing a single feature or fixing a single bug go together.

   • Files that import or reference each other
   • Files in the same directory working toward the same goal
   • Test files paired with the code they test

2. By type of change:

   • Configuration changes (package.json, tsconfig, eslint) → own commit
   • Documentation changes (README, CHANGELOG) → own commit
   • Dependency updates (lockfiles + package.json) → one commit
   • Refactoring (rename, restructure without behavior change) → separate from features
   • Test additions paired with the code they test → together

3. By scope/area: Changes in unrelated parts of the codebase → separate commits.

4. Single-file changes: A lone modified file unrelated to others → own commit.

Decision Process

For each changed file ask:

• What is the purpose of this change? (feature, fix, refactor, docs, config, test)
• Which other files does this change relate to?
• Would this change make sense on its own?

When in doubt, split into smaller commits. Small atomic commits are always better than large unfocused ones.

Special Cases

• Lockfiles (package-lock.json, bun.lockb, yarn.lock, pnpm-lock.yaml): Always group with corresponding package.json change
• Generated files: Group with the source change that produced them, or skip if they belong in .gitignore
• Already staged changes: Respect the user's intent — commit staged files as one group, then handle remaining changes separately
• Untracked files: New source files → commit. Build artifacts, logs, editor configs → suggest .gitignore

Step 4: Create Commits

For each logical group, commit in dependency order (foundational changes first):

1. Stage files: git add <file1> <file2> ... — use specific paths, NEVER git add . or git add -A.

2. Write commit message:

   <type>: <concise summary in imperative mood>
   
   <optional body explaining WHY, not WHAT>
   
   Co-Authored-By: Claude <[email protected]>
   

   | Type | When | |------|------| | feat | New feature or capability | | fix | Bug fix | | refactor | Code restructuring, no behavior change | | docs | Documentation only | | test | Adding or updating tests | | chore | Config, dependencies, build, CI | | style | Formatting, whitespace, linting | | perf | Performance improvement |

   Rules:

   • Subject line max 72 chars, imperative mood ("Add feature" not "Added")
   • No period at end of subject
   • Be specific: "fix: resolve null pointer in user auth" not "fix: fix bug"

3. Create commit using HEREDOC:

   git commit -m "$(cat <<'EOF'
   <type>: <summary>
   
   <optional body>
   
   Co-Authored-By: Claude <[email protected]>
   EOF
   )"
   

4. Verify: git log --oneline -1 to confirm.

5. Repeat for each group.

Step 5: Push to Remote

1. If no upstream: git push -u origin <branch>. Otherwise: git push.

2. Handle failures:

   • Rejected (non-fast-forward): "Push rejected — remote has new commits. You may need to pull and rebase first." Do NOT force-push.
   • Auth failure: "Check your Git credentials."
   • No permission: "You may not have push access to this repository."

3. NEVER force push unless the user explicitly requests it.

Step 6: Summary

Committed and pushed to <branch>:

1. <hash> <type>: <summary> (N files)
2. <hash> <type>: <summary> (N files)
...

Total: X commits, Y files changed
Remote: origin/<branch>

Edge Cases

| Situation | Action | |-----------|--------| | No changes | "Working tree is clean. Nothing to commit." Stop. | | Only staged changes | Commit staged as-is, push | | Only untracked files | Evaluate each, stage appropriate ones, commit, push | | Hundreds of files | Still group logically, create more commits | | Binary files | Include in commit, note in summary | | Submodule changes | Commit pointer update separately | | Pre-commit hook fails | Report failure, do NOT use --no-verify. Fix the issue, create NEW commit. | | Branch behind remote | Warn, suggest pull/rebase | | Detached HEAD | Warn, ask before proceeding | | Empty commit would result | Skip that group, no --allow-empty |

Safety Rules

• NEVER git add . or git add -A — always stage specific files
• NEVER --no-verify to skip hooks
• NEVER force push without explicit user request
• NEVER commit .env files or secrets
• NEVER amend existing commits unless user explicitly asks
• NEVER rebase or modify published history
• If pre-commit hook fails, fix the issue and create a NEW commit