Take the task supplied with this invocation from a new branch through a verified implementation and a completed PR review cycle.

Recover the requested work and acceptance criteria from the accompanying instructions and conversation. Read applicable files and repository requirements. If no task was supplied, ask for it before creating a branch.

Inspect the worktree, current branch, and remotes. Preserve pre-existing changes and exclude unrelated commits from the new branch and PR. Identify the remote for the intended base repository, fetch its branch, and create a new, descriptively named branch with directly from that freshly fetched commit before editing. The branch name must begin with , for example ; follow repository naming conventions for the suffix and use as the PR base. Verify that the new branch's initial HEAD matches the fetched commit; do not branch from a stale local or the current feature branch. If the remote is ambiguous, is missing, or fetching fails, stop and report the blocker. Use an isolated worktree when needed to preserve existing work.

Confirm that the skill is available and GitHub CLI authentication supports the target repository. If a prerequisite is missing, report it explicitly rather than silently dropping the final phase.

Before editing, identify the push remote for the intended head repository (which may differ from the base repository for a fork), then create the same-named remote branch with . Verify that resolves to and compare the SHA returned by with to verify the remote branch matches local HEAD. Branch setup is complete only when both branches exist with the same name and the local branch tracks that remote branch. If publishing or verification fails, stop and report the blocker.

Implement the supplied task, keeping changes within its scope. Commit at meaningful checkpoints as coherent pieces are completed and verified; do not defer all commits until the end of a multi-step task. A small task may need only one commit. Stage only the changes belonging to this task, inspect each staged diff, and use descriptive commit messages.

Before publishing implementation commits, review the complete diff against the intended base and verify every acceptance criterion. Run the relevant tests and repository-required checks, fix failures caused by the work, and inspect for accidental changes or omissions. Proceed when the implementation is complete, relevant verification passes, and all task changes are committed. Report any blocker or unavailable verification accurately.

Push the completed commits without force using the explicit destination , and create a PR against the intended base. Write a title and description covering the final problem, resulting behaviour, and verification. Check whether a PR already exists for this branch before creating one, so a resumed run reuses it.

An invocation requesting this workflow authorizes its commits, push, PR creation, and review replies; carry those steps through without redundant confirmation.

Load and follow for the newly created PR in the same run. Carry forward the task intent, decisions, verification, and known limitations. Continue through its conflict, CI, feedback, and review-convergence workflow until its definition of done is met or one of its stopping conditions applies. Creating the PR alone does not complete this workflow.

Leave the PR open for the user to merge unless merging was separately requested. Report the PR URL, a concise change and verification summary, and any remaining blocker or pending required check, using 's final audit as the source of truth.