ship-staging

name	ship-staging
description	Mark an approved draft pull request ready, merge it into a staging base branch, mark linked issues as on-staging, fast-forward the local staging reference checkout, and post a short Google Chat notification. Use when the user asks to ship, merge, or deploy a staging-targeted PR through the staging branch, especially with "ship-staging".

Ship Staging

Mark an approved draft PR ready when necessary, merge it into staging, mark its linked issues as shipped to staging, refresh the local staging reference checkout, and notify the configured development Google Chat space. This skill is intentionally narrow: it ships staging-base PRs only.

Guardrails

• Refuse when the PR base is not staging; production/main promotions need the repo's separate promotion or hotfix workflow.
• Use only gh pr merge <pr> --merge --delete-branch.
• Never use --admin, --squash, --rebase, --auto, or --no-verify.
• Mark an open draft PR ready before evaluating its merge gates. Stop if the ready transition fails or cannot be verified.
• Stop on merge conflicts, blocked/dirty/unstable merge state, requested changes, failing CI, or required checks still running.
• Resolve the Google Chat webhook at runtime from GCHAT_DEV_WEBHOOK_URL or a consumer-supplied path in GCHAT_DEV_WEBHOOK_FILE. The public skill does not define a default secret location.
• Treat the webhook URL as a secret: never print it, commit it, or include it in logs, PRs, issues, or summaries.
• Do not merge if the webhook secret is unavailable; the notification is part of the staging ship contract.
• Require the repository label status: on-staging before merging so linked issues cannot silently remain in an actionable queue after the merge.

Process

1. Parse the PR number from the first argument. Accept optional --yes only when the user explicitly requested an automatic path.

2. Resolve the webhook secret before validating the PR:

   if [[ -n "$GCHAT_DEV_WEBHOOK_URL" ]]; then
     GCHAT_WEBHOOK_URL="$GCHAT_DEV_WEBHOOK_URL"
   elif [[ -n "$GCHAT_DEV_WEBHOOK_FILE" ]]; then
     if [[ ! -f "$GCHAT_DEV_WEBHOOK_FILE" || ! -r "$GCHAT_DEV_WEBHOOK_FILE" ]]; then
       echo "GCHAT_DEV_WEBHOOK_FILE must name a readable regular file" >&2
       exit 1
     fi
     GCHAT_WEBHOOK_URL=$(<"$GCHAT_DEV_WEBHOOK_FILE")
   else
     echo "Missing webhook secret: set GCHAT_DEV_WEBHOOK_URL or GCHAT_DEV_WEBHOOK_FILE" >&2
     exit 1
   fi
   if [[ -z "${GCHAT_WEBHOOK_URL//[[:space:]]/}" ]]; then
     echo "Webhook secret is empty" >&2
     exit 1
   fi
   

3. Resolve the current repository identity and fetch PR state. Both queries must succeed before merging. Refuse before changing draft state unless the PR is open and targets staging. If it is a draft, mark it ready, refetch the same fields, and verify that the PR is still open, still targets staging, has the same head, and is no longer a draft:

   CURRENT_REPO=$(gh repo view --json nameWithOwner --jq '.nameWithOwner') ||  1
    ! PR_JSON=$(gh  view <> --json number,title,state,isDraft,baseRefName,headRefName,headRefOid,mergeable,mergeStateStatus,url,body,author,reviewDecision,statusCheckRollup,labels); 
       >&2
      1
   
    ! jq -e  <<< >/dev/null; 
       >&2
      1
   
   
   READY_TRANSITION=
    jq -e  <<< >/dev/null; 
     PRE_READY_HEAD=$(jq -r  <<<)
      ! gh  ready <>; 
         >&2
        1
     
      ! PR_JSON=$(gh  view <> --json number,title,state,isDraft,baseRefName,headRefName,headRefOid,mergeable,mergeStateStatus,url,body,author,reviewDecision,statusCheckRollup,labels); 
         >&2
        1
     
      ! jq -e --arg    <<< >/dev/null; 
         >&2
        1
     
     READY_TRANSITION=
   
   
   checks_status=0
   REQUIRED_CHECKS=$(gh  checks <> --required --json bucket,name,state) || checks_status=$?
    [[  -ne 0 &&  -ne 8 ]]; 
       >&2
      1
   
   
   
   
   
   
    ! jq -e  <<< >/dev/null; 
       >&2
      1
   
   ON_STAGING_LABEL=$(gh label list --search  -- 100 \
     --json name --jq )
    [[  !=  ]]; 
       >&2
      1
   
   

Summary Guidance

Write for teammates skimming a dev channel. Prefer concrete user or operational impact over implementation detail. Mention migrations, flags, follow-up issue numbers, or manual validation only when relevant. Keep the PR link as the source of traceability instead of listing commits.