Orchestrate a comprehensive git workflow from code review through PR creation, leveraging specialized agents for quality assurance, testing, and deployment readiness. This workflow implements modern g
Move completed changes from local review to a verified pull request without bypassing repository policy or branch protection.
When to Use
Use for completed implementation work that must be reviewed, tested, committed, pushed to a topic branch, and opened as a pull request. Use the repository's dedicated maintainer or release workflow instead when one is mandatory.
Policy Gate
Before mutation:
Read AGENTS.md, contribution guidance, maintainer docs, and relevant nested instructions.
Inspect the current branch, worktree, remotes, upstream, and effective target-branch protection.
Discover repository-native validation, commit, PR, merge, and release commands.
Preserve unrelated dirty and staged files.
Repository policy wins over flags and user shorthand. Trunk-based development does not imply a direct push: when the target is protected, use a short-lived branch and pull request. If a repository defines a mandatory maintainer skill or guarded merge command, hand off merge and release actions to it. In agentic-awesome-skills, use antigravity-maintainer-batch-release and npm run merge:batch.
Inputs
Resolve these from the request and repository:
target branch, defaulting to the repository default branch;
intended changed files and excluded user work;
required test, lint, security, build, and documentation checks;
branch naming and commit-message conventions;
draft or ready-for-review PR state;
required reviewers, labels, issue links, and merge method.
Ask only when a missing choice changes the result materially.
Confirm every file in scope. Stop if staged or dirty files cannot be separated safely.
2. Review in parallel
When subagents are available and authorized, assign independent bounded passes for:
correctness and regression risk;
security, secrets, permissions, and dependency risk;
test coverage and repository-policy compliance.
Give each reviewer the raw diff and repository instructions. Keep the main agent responsible for deduplication, severity, edits, and final verification.
3. Validate and repair
Run the repository's targeted checks, then its required pre-PR suite. If a check fails:
identify whether the cause is source, policy, environment, or infrastructure;
fix only source or policy defects in scope;
rerun the targeted failure;
rerun the complete required suite.
Do not weaken gates, hide skipped tests, or treat deterministic failures as flaky.
4. Prepare the branch and commit
Fetch the target before committing. If currently on a protected/default branch, create a topic branch before mutation.
Stage only intended paths and create focused conventional commits according to repository policy. Rebase or update the topic branch when strict required checks demand the latest target; never force a shared branch without explicit authorization.
Bind review evidence to the current full head SHA. If the head or base changes, discard stale conclusions and rerun affected checks.
Use the repository's guarded merge path. Do not replace required checks, merge queues, exact-SHA attestations, or maintainer commands with a raw merge API. After merge, fetch the target and verify the requested remote, CI, deployment, or release state.
Stop Condition
Finish when the PR exists at the intended head, required checks are green or have one exact blocker, review evidence is current, unrelated user work is preserved, and any requested guarded merge or deployment is verified.
Limitations
This workflow cannot bypass branch protection, required reviews, repository permissions, or missing credentials.
It does not authorize destructive cleanup, force pushes, merges, deployments, or releases beyond the user's request and repository policy.
Keep unresolved environment or infrastructure failures explicit; do not convert them into source changes without evidence.