pr-lifecycle

name	pr-lifecycle
description	Manages the full PR lifecycle: creation, Copilot comment handling, CI remediation, and user-approved merge
argument-hint	branch=015-feature-branch
input	{"properties":{"branch":{"type":"string","description":"Feature branch to create PR for"},"title":{"type":"string","description":"PR title (optional, defaults to branch name)"}},"required":["branch"]}

PR Lifecycle Skill

Manage the branch-to-merged workflow for a shipment or feature branch. This skill creates or updates the pull request, responds to review feedback, keeps CI healthy, and stops at the user merge gate unless the user explicitly approves the merge.

Purpose

Use this skill when implementation work is ready to move through pull request execution. It centralizes the PR control loop so higher-level agents can treat review, CI follow-up, and merge approval as one bounded workflow.

Inputs

• ${input:branch}: (Required) Branch name to ship
• ${input:title}: (Optional) PR title override. When omitted, derive the title from the branch name or prepared PR description

Workflow

Step 1: Prepare the branch

1. Confirm the branch exists locally and is ready to push.
2. Gather or generate the PR title and body before calling GitHub tooling.
3. Push the branch if it is not already available on the remote.

Step 2: Create or update the pull request

1. Use the GitHub CLI, such as gh pr create or gh pr edit, to create or refresh the pull request.
2. Capture the PR URL, branch, and base branch as the active shipment context.
3. Reuse an existing PR when the branch already has one instead of creating duplicates.

Step 3: Handle Copilot and review feedback

1. Monitor PR review comments, especially Copilot review comments.
2. Apply bounded fixes directly when they are clearly actionable.
3. Re-run the relevant validation after each fix cycle.
4. Keep the PR description and review context aligned with the latest branch state.

Step 4: Handle CI failures

1. If CI fails, invoke the fix-ci skill with the active PR or branch context.
2. Let fix-ci own the remediation loop for failing checks and unresolved review comments.
3. Return to PR monitoring once CI and review status are clean again.

Step 5: Merge approval gate

1. When the PR is reviewable and checks are green, present the status to the user.
2. Wait for explicit user approval before any merge action.
3. Never auto-merge and never treat silence as approval.
4. If the user does not approve merge, leave the PR open and report the ready state.
5. Branch retention (NON-NEGOTIABLE): Do NOT checkout main or delete the feature branch while the merge gate is open. The branch is the active working context for any follow-up CI or review fixes.

Step 6: Post-merge cleanup

After a user-approved merge:

1. Report the merge result and resulting default-branch state.
2. If the caller requires post-merge closure work, recommend creating a post-merge/{feature_slug} branch from updated main rather than pushing closure commits directly to the default branch.
3. Delete the feature branch only when that cleanup is explicitly requested or already part of the chosen PR flow. Do NOT delete automatically.
4. Summarize any follow-up items, release notes, or residual risks that remain after merge.

Completion Criteria

The skill is complete only when one of these outcomes is explicit:

• the PR is open and ready, waiting on user merge approval
• the PR feedback and CI loop is blocked with a clear reason
• the PR was merged after explicit user approval