rootiest/ai-skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(git-publish-workflow): feat(git-publish-workflow): handle multi-branch repsitories

Browse Source 
Verify branching tree and select the proper PR base/target to reflect
the branching order.
This commit is contained in:
Rootiest
2026-07-27 21:09:20 -04:00
parent c3720f33a0
commit b3185381c5
1 changed files with 15 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/git-publish-workflow/SKILL.md
+15 -10
View File
@@ -1,7 +1,7 @@
---
name: git-publish-workflow
description: Automates branching, conventional commits, testing, and PR creation for uncommitted or staged work.
version: 1.1.0
description: Automates branching, conventional commits, testing, and PR creation for uncommitted or staged work. Handles both independent and stacked PRs.
version: 1.2.0
user-invocable: true
author: Rootiest
---
@@ -9,17 +9,22 @@ author: Rootiest
# Git Publish & PR Workflow
## **Objective**
To provide a hands-off, end-to-end automation for moving local changes into a formal Pull Request, ensuring code quality through automated and manual verification steps.
To provide a hands-off, end-to-end automation for moving local changes into a formal Pull Request, ensuring code quality through automated and manual verification steps, while intelligently routing Stacked PRs.
## **Execution Protocol**
### **Phase 1: Scope Determination**
Before execution, check the git index to determine the work boundary:
1. **Case A (Partial):** If staged changes exist, operate **ONLY** on staged changes.
2. **Case B (Full):** If no changes are staged, operate on **ALL** modified/untracked files.
### **Phase 1: Scope & Base Determination**
Before execution, check the local git state:
1. **Scope Check**: Determine the work boundary:
* **Case A (Partial):** If staged changes exist, operate **ONLY** on staged changes.
* **Case B (Full):** If no changes are staged, operate on **ALL** modified/untracked files.
2. **Base Branch Detection**: Identify the currently checked-out branch.
* **Independent PR**: If the current branch is `main` (or `master`), the new branch will be based on `main`. The PR target will be `main`.
* **Stacked PR**: If the current branch is a feature branch (e.g., `feat-a`), assume the new changes are dependent. The new branch will be created from the current branch. The PR target will be the current feature branch (NOT `main`).
* *Safety Check*: If creating a Stacked PR, output a brief terminal message stating: "Detected active feature branch. Stacking new PR on top of `[current-branch-name]`."
### **Phase 2: The "Safe-Commit" Sequence**
1. **Branching**: Generate a `kebab-case` branch name (e.g., `feat-auth-logic` or `fix-header-css`).
1. **Branching**: Generate a `kebab-case` branch name (e.g., `feat-auth-logic` or `fix-header-css`) based off the branch determined in Phase 1.
2. **Naming**: Use **Conventional Commits** for the message (e.g., `feat(ui): add logout button`).
3. **Verification**:
* Identify the project type (e.g., Rust/Cargo, Python/Poetry, Node/NPM).
@@ -27,8 +32,8 @@ Before execution, check the git index to determine the work boundary:
* **Abort Policy**: If verification fails, stop the sequence and report the error. Do not push.
### **Phase 3: Remote Integration**
1. **Push**: Upload the branch to `origin`.
2. **PR Creation**: Open a Pull Request targeting the default branch (usually `main` or `master`).
1. **Push**: Upload the new branch to `origin`.
2. **PR Creation**: Open a Pull Request targeting the base branch determined in Phase 1 (either `main` or the parent feature branch).
3. **Documentation**: Populate the PR description with:
* **Summary**: A high-level overview of "Why" and "What."
* **Manual Verification Checklist**: Provide a Markdown list (`- [ ]`) of 3-5 tactical steps for a human to verify the change in a live environment.