Git Workflow Skill

Use this skill to manage version control operations. This skill enforces a strict "User-Triggered Only" policy for commits and pushes.

Critical Rules

• NEVER AUTO-COMMIT: You must NEVER automatically commit or push changes without an explicit request or confirmation from the user.

• Lint Before Commit: Always run ./vendor/bin/sail bin pint --dirty before staging files.

• Conventional Commits: All commit messages must follow the Conventional Commits specification.

When to use this skill

• When the user asks to "commit", "push", "save changes to git", or "sync branches".

• When finishing a significant task, you may Propose a commit command, but do not execute it with SafeToAutoRun: true .

Workflow

1. Preparation

Always lint changed files first to ensure code style consistency.

./vendor/bin/sail bin pint --dirty

2. Staging

Stage the files relevant to the task. Avoid git add . if there are untracked files not related to the current task.

git add [files]

3. Committing

Construct a commit message following the pattern: <type>(<scope>): <description>

• Types: feat , fix , docs , style , refactor , perf , test , chore , build , ci .

• Scope: The module or component affected (e.g., auth , filament , api ).

• Description: Short, imperative description (max 50 chars recommended).

• Body (Optional): Detailed explanation, bullet points allowed.

Example: feat(auth): add 2fa support for tenants

4. Pushing

Only push if explicitly requested or if it's a sync operation.

git push origin [branch]

Protocol for Multi-Branch Sync (Develop -> Main)

If the user asks to "sync branches" or "deploy":

• Checkout develop .

• Pull latest develop .

• Checkout main .

• Pull latest main .

• Merge develop into main (git merge develop ).

• Push both branches.