high-risk-pr-workflow

Manages Git branch and pull-request workflows for high-risk code changes requiring review and labeling.

Updated Jul 2, 2025
One-click install
npx skills add https://github.com/junechen7414/SpringBoot --skill high-risk-pr-workflow
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: high-risk-pr-workflow
Source: https://github.com/junechen7414/SpringBoot/tree/main/.bob/skills/high-risk-pr-workflow
Command: npx skills add https://github.com/junechen7414/SpringBoot --skill high-risk-pr-workflow

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill provides a controlled branch-and-pull-request process for high-risk changes that should not be pushed directly to main, reducing the chance of breaking CI, databases, or production workflows.

Core Features & Use Cases

  • Branch Creation: Starts work on a dedicated branch with clear naming conventions for features, fixes, hotfixes, refactors, docs, tests, configs, and chores.
  • PR Workflow: Guides commit formatting, pushing, opening a pull request, and applying the right labels for review and tracking.
  • Cleanup and Release Awareness: Includes post-merge branch cleanup and warns about CI side effects such as image publishing, downstream E2E triggers, and Swagger regeneration.
  • Use Case: Use this when changing CI workflows, database migrations, large refactors, or any user-requested change that must be reviewed before landing.

Quick Start

Use the high-risk PR workflow to create a feature branch, make your changes, open a pull request, add the appropriate labels, and clean up the branch after merge.

Frequently Asked Questions about high-risk-pr-workflow

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I safely manage a pull request workflow for high-risk code changes like database migrations?▼

To safely manage pull requests for high-risk changes like database migrations, use a dedicated branch-and-PR workflow with conventional commits, proper label assignment, and post-merge cleanup to prevent breaking production.

When should I use a branch-based PR workflow instead of pushing directly to main?▼

You should use a branch-based PR workflow instead of pushing to main for CI workflow edits, database migrations, large refactors, and any user-requested changes that require review before landing to avoid breaking production.

How do I apply conventional commits and labels when opening a GitHub pull request?▼

When opening a GitHub pull request, apply conventional commit formatting to your changes and assign appropriate labels for review tracking to ensure clear branch lifecycle management and post-merge cleanup.

What is the best way to handle CI workflow edits without breaking downstream pipelines?▼

The best way to handle CI workflow edits without breaking downstream pipelines is to isolate changes in a dedicated branch, open a pull request for review, and monitor for CI side effects like image publishing or Swagger regeneration.

Does branch lifecycle management include post-merge cleanup for feature and hotfix branches?▼

Yes, branch lifecycle management includes post-merge cleanup for feature, fix, hotfix, refactor, docs, test, config, and chore branches to safely ship high-risk changes through the pull request workflow.

Why does editing CI workflows require a dedicated branch and pull request?▼

Editing CI workflows requires a dedicated branch and pull request because these are high-risk changes that can trigger side effects like image publishing, downstream E2E triggers, and Swagger regeneration, requiring review before landing.