imvanzen/commit-series-on-branch
.cursor/skills/commit-series-on-branch/SKILL.md
Creates a logical series of commits from current changes; never commits to main; ensures or uses a working/feature branch so changes stay isolated and reviewable via PR. Use when the user wants to split changes into multiple commits, "commit my work", "create commits from changes", or to prepare changes for PR on a branch.
data-ai
Updated Apr 16, 2026
$ install --global
skillsauthnpx skillsauth add imvanzen/strava-kudosik commit-series-on-branchInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 16, 2026, 9:30 PM4.4s1 file scanned
SKILL.md
- name:
- commit-series-on-branch
- description:
- Creates a logical series of commits from current changes; never commits to main; ensures or uses a working/feature branch so changes stay isolated and reviewable via PR. Use when the user wants to split changes into multiple commits, "commit my work", "create commits from changes", or to prepare changes for PR on a branch.
Commit Series on Branch
Creates multiple conventional commits from current work. Never commits to main. Always operates on a working/feature branch so changes stay isolated and go through review/PR.
When to apply
- User wants to "commit my changes", "split into commits", "create a series of commits", or "prepare commits for PR".
- User asks to turn current work into logical commits on a branch.
Invariants
- Never commit on main (or repo default branch). If current branch is main/master/default, do not run
git commit. Use the create-branch skill to create/checkout a feature branch first, or tell the user to switch branch. - Commit message format and validation follow commit-messages and .cursor/rules/commit-messages.mdc. Validate with
echo "<subject_line>" | pnpm exec commitlint. - Do not push in this skill unless the user explicitly asks; pushing is separate (e.g. github-push-branch).
Procedure
1. Ensure we are on a working branch
- Run
git branch --show-currentand resolve repo default (e.g.git remote show originor assumemain). - If current branch is the repo default (main/master): stop. Do not commit. Either:
- Use the create-branch skill to create and checkout a feature branch from current state (and tell the user that commits will be made on that branch), or
- Tell the user: "You are on main. Create or checkout a feature branch first so we can commit there."
- Only proceed with committing when current branch is not the repo default.
2. Inspect changes
- Run
git statusandgit diff(andgit diff --stagedif needed). - Identify all modified/added/deleted files and group them by logical change (e.g. one commit per: docs, feat, fix, test, refactor, style, build).
3. Plan the series of commits
- Order commits by dependency (e.g. refactor before feat, tests with the code they cover).
- One logical change per commit. Prefer more, smaller commits over one big commit when changes clearly separate (e.g. "docs" + "feat" + "test").
- Assign a type and optional scope per commit from the commit-messages rules (feat, fix, docs, test, refactor, chore, etc.).
4. Create each commit
For each group:
- Stage:
git add <paths>for that group only. - Message: Compose subject (and body if needed) per commit-messages:
type(scope): subject, imperative, lowercase, ≤100 chars, no trailing period. - Validate:
echo "<subject_line>" | pnpm exec commitlint. If it fails, fix the message and re-check. - Commit:
git commit -m "<subject>" [-m "<body>"](or-F -with a message file if multi-line). - Repeat for the next group until all planned changes are committed.
5. Confirm
- Report: branch name, number of commits created, and short subject of each.
- Remind that changes are only local until they push and open a PR.
Branch check (mandatory)
Before any git commit:
current=$(git branch --show-current)
# If current == main | master | <repo default> → do NOT commit. Create/checkout feature branch first.
Grouping heuristics
- Same type, same area: One commit (e.g. "fix(checkout): correct gift card total").
- Different types: Separate commits (e.g.
docs: ..., thenfeat(checkout): ..., thentest(checkout): ...). - Unrelated files: Prefer separate commits by app/domain (e.g. backend vs checkout).
- Single coherent change across files: One commit with one scope.
When in doubt, prefer one logical unit per commit; do not over-split (e.g. one commit per file) unless the user asks for that.
Constraints
- Do not commit on main/master/repo default. Always work on a feature branch.
- Every commit message must pass the project commitlint and lefthook rules (see commit-messages skill).
- Do not add Cursor (or any agent) as co-author.
- Do not push unless the user explicitly asks.
- Do not invent ticket IDs; use only from context or ask.
Error handling
- On main: Abort committing; use create-branch or ask user to switch.
- Commitlint fails: Adjust message (type, scope, length, imperative, no period) and retry.
- Nothing to commit (empty stage): Skip that group and continue with the next, or report that the group has no changes.
- Merge conflicts / dirty state: Report; do not commit until user resolves.
Summary
- Branch: If on main → create/checkout feature branch (create-branch skill) or stop.
- Plan: Group changes into logical commits; assign type/scope per commit-messages.
- Commit: For each group: stage → message → validate with commitlint → commit.
- Report: List branch and commit subjects; do not push unless asked.
Related Skills
imvanzen/technical-context-discovery
development
VerifiedTrustedCommunity
Discover and establish technical context before implementing any feature. Prioritize project instructions, existing codebase patterns, and external documentation in that order. Use for any task requiring understanding of project conventions, coding standards, architecture patterns, and established practices before writing code.
SKILL.mdUpdated Apr 16, 2026
imvanzen/task-analysis
development
VerifiedTrustedCommunity
Analyse task description, performs gap analysis, expand the context for the task, analyse the current state of the system in the context of the task, helps build PRD, creates a context for the task, gathers information about the task from different sources.
SKILL.mdUpdated Apr 16, 2026
imvanzen/maintenance
testing
VerifiedTrustedCommunity
Resolves dependency audit (security) issues and updates outdated packages with prioritization by breaking-change risk and security/value. Prefer security fixes and non-breaking updates; defer or flag major upgrades. Use when the user asks to fix audit, update packages, resolve vulnerabilities, or run maintenance.
SKILL.mdUpdated Apr 16, 2026
imvanzen/implementation-gap-analysis
testing
VerifiedTrustedCommunity
Implementation gap analysis. Verify what has to be implemented. Verify what was implemented. Compare plan to current state.
SKILL.mdUpdated Apr 16, 2026