Create a semantic commit to accomodate user request.

Soft Validation

If any of these checks fail, check with the user before proceeding.

• WARN_ON_DEFAULTBRANCH: ![$(git branch --show-current) = $(gh repo view --json defaultBranchRef --jq .defaultBranchRef.name)] && echo 1 || echo 0 should equal 0

• WARN_MERGECONFLICTS: !git ls-files -u | wc -l should equal 0

• WARN_INVALIDBRANCHNAME: !git branch --show-current should match ^(feat|fix|docs|style|refactor|perf|test|chore)/[a-z0-9-]+$ (if not on default branch)

Hard Validation

If any of these checks fail, fix the issue before proceeding. or Exit if human intervention is required.

• on default branch, but it needs to be fastforwarded from remote.

• uncommitted merge conflicts detected. Please resolve them before committing.

Setup

• Ensure git is installed and configured with user name and email.

Execution Process

• Analyse

• Prepare

• Commit

• Sync

1. Analyse Changes

Assess current state:

git status --porcelain git diff --stat git diff --cached --stat

• Identify all modified, added, and deleted files

• Check for any staged changes already in place

• Note any untracked files that should be included

Analyze changes by file:

git diff git diff --cached

• Review the actual content of each change

• Understand what each modification accomplishes

• Identify related changes that belong together

2. Prepare Changes

• Group changes into logical commits:

• Each commit should represent ONE logical change (feature, fix, refactor, etc.)

• Related files should be committed together

• Avoid mixing unrelated changes in a single commit

• Order commits logically (dependencies first, then dependents)

3. Commit Changes

• Create atomic commits: For each logical group: git add <specific-files> git commit -m "<type>: <brief description>"

4. Push Process

• determine default branch with the gh cli tool

• fast forward the default branch from remote: ie: git fetch origin master:master

• rebase the current branch onto the default branch: ie: git rebase master

• push the current branch to remote: ie: git push origin HEAD --force-with-lease

Guidance: Commit Message Writing

Use the skills_superpowers_writing_git_commits skill to guide you in writing great commit messages and body content following the Conventional Commits specification.

Otherwise:

• Use conventional commit prefixes:

• feat:

• New feature, functionality.

• fix:

• Bug fix or refactoring.

• docs:

• Documentation changes

• style:

• Formatting, whitespace (no code change)

• test:

• Adding or updating tests

• chore:

• Maintenance tasks, dependencies, config

• Commit Message format:

• 1st line: <type>(scope): <subject>

• Blank line

• Body: Detailed explanation of what and why (wrap at 72 chars)

• Keep subject line under 72 characters

• Use imperative mood ("add" not "added")

• Be specific but concise

• No period at the end of subject line

Examples:

• feat: add user authentication endpoint

• fix(config): resolve null pointer in config parser

• feat(scope): extract validation logic to separate module

• docs(apiv2): update API documentation for v2 endpoints

• chore: update dependencies to latest versions

Content Guidelines

• Use direct, factual commit messages

• Avoid vague messages ("fix bug", "update code", "misc changes")

• No emojis unless project convention requires them

• Focus on WHAT changed and WHY (briefly)

• Group related changes even if in different files