release-pr-gates
Promote releases through GitHub pull requests between develop, staging, and master/main branches, including branch discovery, target selection, PR creation, and waiting for required quality gates. Use when the user asks to release, promote develop, open a release PR, push to staging, promote staging to production, or wait for GitHub checks to go green.
What this skill does
# Release PR Gates Promote code through protected branches with GitHub pull requests and wait for quality gates before reporting the release as ready. ## Contract Inputs: - Repository root with git remote - Source branch and target branch, or permission to auto-detect release branches - Optional existing PR number Outputs: - PR URL or existing PR reused - Source/target branch summary - Quality gate status - Failing check summary when gates fail Creates/Modifies: - May create a GitHub release PR - May create a local PR body file - Does not merge unless explicitly confirmed External Side Effects: - Reads and writes GitHub pull request state - Watches GitHub checks - Reads GitHub Actions logs for failures Confirmation Required: - Before creating a PR unless the user explicitly asked to open a release PR - Before marking a PR ready when repository convention is unclear - Before merging into `master` or `main` - Before rerunning workflows Delegates To: - `gh-fix-ci` when checks fail - `changelog-generator` when a release body needs commit summaries - `deploy` after release gates pass and provider deployment is needed ## Use Case Use this skill for release promotion flows such as: - `develop` -> `staging` -> `master` - `develop` -> `staging` -> `main` - `develop` -> `master` when no `staging` branch exists - `develop` -> `main` when no `staging` branch exists Always discover the repository's real branches before choosing the PR target. ## Preconditions 1. Verify GitHub CLI and auth: ```bash gh --version gh auth status -h github.com ``` 2. Verify clean release context: ```bash git status -sb git remote -v git fetch --all --prune ``` 3. Identify the repository and default branch: ```bash gh repo view --json nameWithOwner,defaultBranchRef ``` 4. List release branches on the remote: ```bash git branch -r --list 'origin/develop' 'origin/staging' 'origin/master' 'origin/main' ``` Stop and explain the blocker if `develop` does not exist. This release flow starts from `develop` by default. ## Branch Target Rules Choose the PR base in this order: 1. If the user explicitly names a base branch, use it after confirming it exists on the remote. 2. If `origin/staging` exists, open the release PR from `develop` to `staging`. 3. If `origin/staging` does not exist, open the release PR from `develop` to `master` when `origin/master` exists. 4. If `origin/master` does not exist, open the release PR from `develop` to `main` when `origin/main` exists. 5. If none of these targets exist, stop and report the available remote branches. For a second production promotion after staging has gone green, use: - `staging` -> `master` when `master` exists - `staging` -> `main` when `master` does not exist and `main` exists Require explicit user confirmation before merging into `master` or `main`. ## Release PR Workflow 1. Run local quality gates before opening or updating the release PR. Format, lint, and type-check are mandatory because they mirror GitHub Actions and are cheap to run locally: ```bash bun run format || npm run format || npx biome check --write . bun run lint || npm run lint || bunx turbo lint bun run typecheck || bun run type-check || npm run typecheck || npm run type-check || npx tsc --noEmit ``` Fix failures before pushing. Do not open a release PR with known local format, lint, or type errors. 2. Inspect branch divergence: ```bash git log --oneline origin/<base>..origin/<head> git diff --stat origin/<base>...origin/<head> ``` 3. Check for an existing open PR: ```bash gh pr list --head <head> --base <base> --state open --json number,title,url,headRefName,baseRefName ``` 4. If no open PR exists, create one: ```bash gh pr create --head <head> --base <base> --title "Release: <head> to <base>" --body-file <body-file> ``` The PR body should include: - Source and target branches - Commit summary from `<base>..<head>` - Local checks already run, if any - Release risk notes or migrations, if visible from commits 5. If an open PR already exists, reuse it. Do not create duplicates. 6. Mark the PR ready for review only if the user requested a non-draft PR or the repository release convention requires ready PRs. ## Waiting for Quality Gates After creating or finding the PR, wait for GitHub checks: ```bash gh pr checks <number> --watch ``` If `--watch` is not available or fails, poll checks: ```bash gh pr checks <number> ``` Quality gate outcomes: - `pass`: report the PR is green and ready for review or merge. - `fail`: fetch the failing workflow logs and summarize root cause. - `pending`: keep waiting unless the user asks for a status-only update. - `skipping` or no checks: report exactly what GitHub shows; do not call it green unless required checks are passing or absent by repository policy. For failed GitHub Actions runs, inspect logs: ```bash gh run view <run-id> --log ``` Do not rerun workflows unless the user asks. ## Merge Policy - Do not merge production PRs without explicit confirmation. - Do not bypass failing required checks. - If staging exists, prefer a staged rollout: `develop` -> `staging`, then `staging` -> production after gates are green. - If staging does not exist, use the direct `develop` -> production PR and make the missing staging branch explicit in the final status. ## Final Status Report: - Repository - PR URL - Source and target branches - Whether this was a staged or direct production release - Quality gate state - Any failing check names and root cause summary - Whether user confirmation is needed to merge
Related in General
modeling-omnistudio-epc-catalog
IncludedSalesforce Industries CME EPC product-modeling skill for Product2-based catalog creation. Use when creating EPC products, configuring product attributes, building offer bundles with Product Child Items, or reviewing EPC DataPack JSON metadata for product catalog changes. TRIGGER when: user creates or updates Product2 EPC records, AttributeAssignment payloads, AttributeMetadata/AttributeDefaultValues, Offer bundles, or ProductChildItem relationships. DO NOT TRIGGER when: designing OmniScripts/FlexCards/Integration Procedures (use building-omnistudio-omniscript, building-omnistudio-flexcard, or building-omnistudio-integration-procedure), implementing Apex business logic (use generating-apex), or troubleshooting deployment pipelines (use deploying-metadata).
relationship-science-coach
IncludedUse this skill for direct, practical adult relationship coaching: couples conflict, repair, trust, marriage, dating, flirting, attachment patterns, emotional connection, sex, desire differences, eroticism, kink negotiation, affection, love languages, breakups, and long-term passion. Draw on Gottman, EFT and Hold Me Tight, attachment science, modern sex research, Perel, Nagoski, Kerner, Schnarch, Love and Stosny, and flexible love-language tools. Be concrete and low-hedge. Redirect only for imminent danger, abuse, coercive control, minors, non-consent, self-harm, stalking, or medical/legal/psychiatric decisions.
building-sf-integrations
IncludedSalesforce integration architecture and runtime plumbing with 120-point scoring. Use this skill to set up Named Credentials, External Credentials, External Services, REST/SOAP callout patterns, Platform Events, and Change Data Capture. TRIGGER when: user sets up Named Credentials, External Services, REST/SOAP callouts, Platform Events, CDC, or touches .namedCredential-meta.xml files. DO NOT TRIGGER when: Connected App/OAuth config (use configuring-connected-apps), Apex-only logic (use generating-apex), or data import/export (use handling-sf-data).
venue-templates
IncludedAccess comprehensive LaTeX templates, formatting requirements, and submission guidelines for major scientific publication venues (Nature, Science, PLOS, IEEE, ACM), academic conferences (NeurIPS, ICML, CVPR, CHI), research posters, and grant proposals (NSF, NIH, DOE, DARPA). This skill should be used when preparing manuscripts for journal submission, conference papers, research posters, or grant proposals and need venue-specific formatting requirements and templates.
let-fate-decide
IncludedDraws the 12 Houses of the Zodiac Tarot spread to inject entropy into planning when prompts are vague, ambiguous, or casually delegated. Interprets the spread to guide next steps. Use when the user says 'let fate decide', 'YOLO', 'whatever', 'idk', or other nonchalant phrases, makes Yu-Gi-Oh references, or when you are about to arbitrarily pick between multiple reasonable approaches. Prefer over ask-questions-if-underspecified when the user's tone is casual or playful rather than precision-seeking.
net-ops
IncludedCross-platform network troubleshooting (Windows, macOS, Linux) via local or remote shell. Use for: DNS broken, can't resolve hostnames, nslookup/dig works but apps fail, NRPT, WFP, scutil, /etc/resolver, systemd-resolved, /etc/resolv.conf, NetworkManager, VPN DNS leak residue (ProtonVPN/Mullvad/WireGuard/AnyConnect), AV/firewall blocking DNS or DoH, Tailscale DNS interaction, intermittent connectivity, remote diagnostics over SSH.