git-flow-master

Solid

End-to-end Git operator for any branching strategy. Auto-detects the project's strategy (solo-main, main+integration, enterprise multi-branch, trunk-based, GitFlow, GitHub Flow, GitLab Flow, SDET integration-trunk for chained test-automation suites) from .git config, branches, and the `git_strategy:` block in `.agents/project.yaml`, then adapts every commit, branch, push, PR, conflict-fix, and chained-PR action to that strategy. Use this skill whenever the user wants to: create a branch (`crear branch`, `new feature branch`, `start work on UPEX-123`), commit changes (`commit this`, `commitear esto`, `make a commit`, `commit and push`), push code (`push`, `push to main`, `push to staging`, `subir cambios`), open a pull request (`create PR`, `open PR`, `abrir PR`, `crear pull request`, `gh pr create`), fix merge conflicts (`fix conflict`, `resolver conflicto`, `merge conflict`, `rebase conflict`, `push rejected`), plan stacked or chained PRs (`stack of PRs`, `chained PRs`, `split this PR`, `PR demasiado grande`

AI & Automation 21 stars 12 forks Updated 6 days ago MIT

Install

View on GitHub

Quality Score: 84/100

Stars 20%

Recency 20%

100

Frontmatter 20%

Documentation 15%

100

Issue Health 10%

License 10%

100

Description 5%

100

Skill Content

# Git Flow Master — One Skill for Branches, Commits, Pushes, PRs, and Conflicts This skill is the project's single entry point for everything that happens on the version-control layer: creating branches, writing commits, pushing safely, opening pull requests, resolving conflicts, and planning chained / stacked PRs when a change outgrows the review budget. It does not assume one branching model. The project may run on `main` only, on `main + staging`, on a multi-branch enterprise layout, or on any of the well-known flows (trunk-based, GitFlow, GitHub Flow, GitLab Flow). The skill **detects** which one is active and adapts every command accordingly. The detection is sticky: once resolved, the strategy is recorded in the `git_strategy:` block of `.agents/project.yaml` so future invocations skip the prompt. --- ## When to use Trigger on any of these intents — even without literal keywords: - "I want to start work on UPEX-123" → branch creation - "commit and push", "subir cambios", "push to main" → commit + push flow - "abrí un PR contra staging" → PR creation - "tengo conflictos al hacer pull" → conflict resolution - "este PR va a qued...

Details

Author: upex-galaxy
Repository: upex-galaxy/agentic-qa-boilerplate
Created: 4 months ago
Last Updated: 6 days ago
Language: HTML
License: MIT

Integrates with

GitHub · DevTools GitLab · DevTools Playwright · Testing

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Listed

github-flow

Complete GitHub workflow skill for clean, consistent branch-to-merge cycles. Use this skill whenever you need to: create a branch, make commits, push changes, open a pull request, merge a PR, or clean up after a merge. Also invoke proactively when the user says "commit this", "push my changes", "open a PR", "merge it", "clean up the branch", "I'm done with this feature", or any variation of git/GitHub operations. Agents are authorised to merge PRs — no human approval is required unless the skill explicitly flags a risk. This skill replaces ad-hoc git commands and ensures every change follows the same clean workflow.

0 Updated 5 days ago

talentedgeai

Code & Development Listed

git-workflow

Use when choosing a Git branching strategy or handling merge vs rebase, conflicts, stashing, undoing mistakes, and release tagging — complementing the commit/PR conventions in the git rules.

7 Updated 1 weeks ago

pekral

Code & Development Listed

git-workflow

Git workflow conventions and conflict/recovery procedures — Conventional Commits format, branching models (Git Flow, GitHub Flow, trunk-based), pull request structure and review checklists, merge-versus-rebase choice, cherry-pick, interactive rebase, and guarded use of history-rewriting or destructive commands. Covers the rebase inversion where --ours is the upstream and --theirs is the user's own work. Use when resolving a merge or rebase conflict, choosing or documenting a branching strategy, writing a commit message or PR description to a convention, deciding between merging and rebasing, undoing or reverting a commit, cleaning up history before a PR, or recovering work after a bad reset, rebase, or force-push. Not needed for routine single commands whose syntax is already known — git status, git add, git diff, git log, staging, a plain commit, or a straightforward push or pull.

7 Updated 4 weeks ago

pfangueiro