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.