Orchestrate Complete Git Workflow with Multi-Agent System

Guarded Git Pull Request Workflow moves completed, reviewed implementation work from local changes to a verified pull request without bypassing repository policy or branch protection. Before any mutation it reads AGENTS.md, contribution guidance, and maintainer docs; inspects the current branch, worktree, remotes, and effective target-branch protection; and discovers the repository's own validation/commit/PR/merge/release commands - repository policy always wins over flags or user shorthand, and trunk-based development does not imply a direct push when the target is protected. If a repository defines a mandatory maintainer or guarded-merge skill, this workflow hands off to it instead of merging directly.

Use it for completed implementation work that needs review, testing, committing, pushing to a topic branch, and opening as a pull request - not when the repository mandates its own dedicated maintainer or release workflow instead. Required inputs are resolved from the request and repository rather than assumed: target branch (default to the repo's default), intended changed files versus excluded user work, required test/lint/security/build/doc checks, branch-naming and commit-message conventions, draft-versus-ready-for-review state, and required reviewers/labels/issue links/merge method - asking the user only when a missing choice would materially change the result.

The workflow runs six steps: capture the exact change (git status --short --branch, git diff --stat, confirming every file in scope, stopping if staged/dirty files can't be safely separated); review in parallel across correctness/regression, security/secrets/dependency, and test-coverage/policy-compliance lenses when subagents are authorized; validate and repair by running targeted checks then the full required pre-PR suite, fixing only in-scope source or policy defects without weakening gates or treating deterministic failures as flaky; prepare a topic branch off a freshly-fetched target (never mutating directly on a protected/default branch) with focused conventional commits; push and open the PR:

git push -u origin <topic-branch>
gh pr create --base <target-branch> --head <topic-branch> \
  --title "<conventional title>" --body-file <body-file>

with a PR body that truthfully states what changed and why, which tests actually ran, and any risk/rollback/breaking-change notes - never marking a pending check as completed; and finally verifying the remote result via gh pr view/gh pr checks, binding review evidence to the exact head SHA and discarding stale conclusions if the head or base changes.

Merging goes through the repository's own guarded merge path - required checks, merge queues, and exact-SHA attestations are never replaced with a raw merge API call - and after merge the workflow re-fetches the target to verify the resulting remote, CI, deployment, or release state. It stops only once the PR exists at the intended head, required checks are green (or have exactly one identified blocker), review evidence is current, and unrelated user work was preserved throughout.

Developers and coding agents pushing finished work through a policy-compliant PR process who need branch protection, required reviews, and repository-native merge commands respected end to end - explicitly forbidden from bypassing protection, force-pushing, or converting unresolved environment/infrastructure failures into unwarranted source changes.