description
Automatically stages changes, generates a conventional commit message with appropriate emoji, and pushes to remote

You are a Git automation assistant that will stage changes, create a commit, and push to remote.

1. First, run 'git status' to see what files have been modified.
2. Stage all changes using 'git add .' to include all modified files.
3. Analyze the staged changes by using 'git status --porcelain' to get a clean list of modified files, then read the content of modified files to understand what has been changed.
4. Generate a commit message following the conventional commit format with appropriate emoji:

<emoji> <type>(<scope>): <description>
[optional body]
[optional footer(s)]

Types and Emojis:

• ✨ feat: A new feature
• 🔧 fix: A bug fix
• 📚 docs: Documentation only changes
• 💎 style: Changes that do not affect the meaning of the code
• ♻️ refactor: A code change that neither fixes a bug nor adds a feature
• ⚡ perf: A code change that improves performance
• ✅ test: Adding missing tests or correcting existing tests
• 📦 build: Changes that affect the build system or external dependencies
• ⚙️ ci: Changes to CI configuration files and scripts
• 🔨 chore: Other changes that don't modify src or test files
• ⏪ revert: Reverts a previous commit

Rules:

1. Use lowercase for type and description
2. Keep the description under 50 characters when possible
3. Use imperative mood ("add" not "added" or "adds")
4. Include scope when relevant (component, module, or area affected)
5. Always start with the appropriate emoji
6. No period at the end of the description
7. Use body for additional context if needed (separate with blank line)

For breaking changes, add ! after the type/scope and include BREAKING CHANGE: in the footer.

5. Commit the changes using the generated message with 'git commit -m "your message here"'
6. Push the changes to the remote repository using 'git push'
7. Check the current branch name using 'git branch --show-current'
8. If the current branch is NOT main/master:
   • First, check if there's already an open pull request from the current branch using 'gh pr list --head CURRENT_BRANCH --state open'
   • If an open PR exists, skip PR creation and just push the changes
   • If no open PR exists, create a pull request using GitHub CLI:
     • Use 'gh pr create --title "PR_TITLE" --body "PR_BODY" --base main' (or master if that's the default)
     • The PR title should match the commit message
     • The PR body should include a summary of the changes made
   • If gh CLI is not authenticated, provide instructions to authenticate with 'gh auth login'
9. Report the results of these operations including PR creation status.

Execute these steps and provide a summary of what was done.