name: git-autopush description: > Automatically stages, commits, and pushes code changes to GitHub after every modification made via Claude Code. Use this skill ALWAYS after editing, creating, or deleting any file in a project that has a git repository. Triggers on: any file edit, code generation, refactoring, bug fix, dependency change, config update, or any other modification to the codebase. Never skip this — every change should be committed and pushed immediately.

Git Auto-Push Skill

After every code change, automatically:

1. Verify branch safety (NEVER push to main or staging directly)
2. Stage modified files
3. Generate a commit message based on the diff
4. Commit and push to the feature branch
5. Add changelog entry to docs/CHANGELOG.md

Workflow

Step 1 — Check git context and branch safety

git -C <project_root> status --short
git -C <project_root> branch --show-current

• If the directory is not a git repo → warn the user and skip.
• Get the current branch name and apply these rules:

BRANCH SAFETY RULES (MANDATORY):

If on main or staging, show this message and STOP:

⛔ Voce esta na branch `<branch>`. Push direto nao e permitido.

Para continuar, crie uma feature branch:
  git checkout staging && git pull
  git checkout -b feature/<nome-da-feature>

Depois, eu commito e faço push automaticamente.

Do NOT commit. Do NOT stash. Do NOT try to work around this. Wait for the user to switch branches.

Step 2 — Stage changes

git -C <project_root> add -A

Step 3 — Generate commit message

Run git diff --cached to see what changed, then write a commit message following this format:

<type>(<scope>): <short description>

- <bullet summarizing change 1>
- <bullet summarizing change 2>
...

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Types (Conventional Commits):

Rules for the message:

• Subject line: max 72 chars, imperative mood ("add", not "added")
• Scope: the affected module/folder/feature (optional but preferred)
• Bullets: only include if there are 2+ meaningful changes
• Never include "Claude made this change" or similar — write as if a human dev wrote it
• Always include Co-Authored-By as the last line

Examples:

feat(auth): add Google OAuth login flow
fix(api): handle null response from payment gateway
refactor(dashboard): extract chart logic into separate component
chore(deps): upgrade React to 18.3

Step 4 — Commit and push

git -C <project_root> commit -m "<generated message>"
git -C <project_root> push

If push fails due to no upstream set:

git -C <project_root> push --set-upstream origin <current_branch>

Step 5 — Add changelog entry

After a successful push, add an entry to docs/CHANGELOG.md documenting what was done.

Create the file if it doesn't exist with a # Changelog header.

Add the new entry at the TOP of the file (right after the # Changelog header), so the most recent changes appear first.

Format:

## YYYY-MM-DD | <commit message subject line>

**O que foi feito:**
- <bullet describing each meaningful change>

**Por que:**
- <the reason/motivation behind the change>

**Arquivos alterados:**
- `<file path>` - <brief description of what changed in this file>

**Impacto arquitetural:** <"Nenhum" OR brief description of structural impact>

---

Rules:

• Each commit generates ONE entry
• "Impacto arquitetural" is mandatory — forces reflection on structural changes
• For trivial commits (typo, style, formatting), use a minimal single-line entry: ## YYYY-MM-DD | style: fix typo — Sem impacto.
• Do NOT include the changelog file itself in the list of altered files
• After writing the entry, stage, commit (docs(changelog): update changelog), and push

Step 6 — Sync Obsidian vault

Execute the workflow described in agents/obsidian-sync-SKILL.md to update the Obsidian vault with the progress made in this commit. This step is mandatory — never skip it.

Step 7 — Suggest PR if ready

After push, check if a PR already exists for this branch:

gh pr list --head <current_branch> --state open

• If no PR exists and the feature seems complete, suggest:

  📌 Para enviar para staging, crie um PR:
    gh pr create --base staging --title "<commit subject>" --body "..."
  

• If PR already exists, just note it:

  🔗 PR existente: #<number>
  

• If the work is clearly in progress (partial feature), do NOT suggest PR yet.

Step 8 — Confirm to the user

After everything completes, show a brief confirmation:

✅ Committed and pushed to `<branch>`:
   <commit message subject line>
📋 Changelog updated
📓 Obsidian synced

If anything fails, show the error clearly and suggest a fix.

Edge Cases

• On main or staging: STOP. Do not commit. Instruct user to create feature branch. This is the #1 priority check.
• Untracked files only (no modifications): still stage and commit with chore: add <filenames>
• Nothing to commit: skip silently, no message needed
• Merge conflicts: do NOT attempt to resolve — warn the user and stop
• Detached HEAD: warn the user and skip the push (commit is still OK if they confirm)
• Large binary files: skip files >10MB from auto-commit and warn the user
• .gitignore: respect it — never force-add ignored files
• Push rejected (branch protection): This means you're on a protected branch. Show the branch safety message from Step 1.

Notes

• Always infer <project_root> from the file(s) being edited in the current task
• If multiple repos are involved in one task, commit and push each one separately
• Do not ask for confirmation before committing — just do it and report what happened
• The gh CLI is available for PR operations (installed and authenticated)