git-pr-workflow

Name: git-pr-workflow
Author: Romanescu11

447stars60forks

How to install git-pr-workflow?

romanescu11/hermes-skill-factory/git-pr-workflow

$npx -y skills add Romanescu11/hermes-skill-factory --skill git-pr-workflow

Installs into the current project.

Summary

End-to-end workflow for creating a clean, reviewed pull request from a feature branch.

Files · 1

View on GitHub

SKILL.md

1	# Git PR Workflow
2
3	A repeatable, disciplined workflow for turning work-in-progress code into a clean pull request ready for review. Covers branch hygiene, commit quality, and PR description best practices.
4
5	## When to Activate
6
7	Activate this skill when:
8	- You've finished a feature or fix and are ready to open a PR
9	- You need to prepare a branch for code review
10	- You want to ensure your PR passes CI before review
11
12	## Workflow
13
14	### Phase 1: Branch & Commit Hygiene
15
16	Clean up the branch before opening the PR.
17
18	Steps:
19	1. Run `git status` to confirm working tree is clean
20	2. Run `git log origin/main..HEAD --oneline` to review commits
21	3. Squash or reword any "WIP", "fix typo", or noise commits with `git rebase -i origin/main`
22	4. Ensure each commit has a clear imperative message: `Add user auth`, not `added stuff`
23	5. Run `git diff origin/main` for a final sanity check
24
25	Before moving on:
26	- [ ] No WIP commits remain
27	- [ ] All commits have clear messages
28	- [ ] No unintended files are staged
29
30	### Phase 2: CI Pre-flight
31
32	Run tests locally before pushing.
33
34	Steps:
35	1. Run the test suite: `pytest` / `npm test` / project-specific command
36	2. Run the linter: `ruff check .` / `eslint .` / equivalent
37	3. Fix any failures — do NOT push a red branch
38	4. Push the branch: `git push -u origin HEAD`
39
40	Before moving on:
41	- [ ] All tests pass locally
42	- [ ] Linter reports no errors
43
44	### Phase 3: PR Description
45
46	Open the PR with a description that makes reviewers' lives easy.
47
48	Steps:
49	1. Open the PR on GitHub / GitLab
50	2. Title: imperative mood, under 60 chars — `Add OAuth2 login flow`
51	3. Body: use this structure:
52	```
53	## What
54	[1-3 bullets: what changed]
55
56	## Why
57	[Context: issue link, ticket, or motivation]
58
59	## How to Test
60	[Checklist of manual test steps]
61
62	## Screenshots (if UI change)
63	```
64	4. Link to any related issues: `Closes #123`
65	5. Assign reviewers and labels
66
67	Before moving on:
68	- [ ] PR title follows convention
69	- [ ] Description has What / Why / How to Test
70	- [ ] Reviewers assigned
71
72	## Quality Checklist
73
74	- [ ] Branch is rebased on top of `main`
75	- [ ] No merge conflicts
76	- [ ] CI is green after push
77	- [ ] PR description complete
78	- [ ] Self-reviewed the diff one more time
79
80	## Examples
81
82	### Example 1: Feature PR
83
84	Working on a new login page. After finishing:
85	1. `git rebase -i origin/main` → squash 4 commits into 1: `Add OAuth2 login page`
86	2. `pytest` → all pass
87	3. `git push -u origin feature/oauth-login`
88	4. Open PR: title `Add OAuth2 login page`, link to issue #88
89	5. Assign 2 reviewers, add label `feature`
90
91	### Example 2: Bug Fix PR
92
93	Fixed a null pointer in the payment service:
94	1. Single commit already clean: `Fix null pointer in PaymentService.charge`
95	2. `npm test` → passes
96	3. `git push`, open PR titled `Fix null pointer in PaymentService`
97	4. Body explains the root cause and how to reproduce before the fix
98
99	## Anti-patterns
100
101	- ❌ Opening a PR from `main` directly
102	- ❌ Pushing without running tests first
103	- ❌ PR descriptions that just say "fixes bug"
104	- ❌ 47-commit PRs with no squashing
105	- ❌ Assigning reviewers before CI is green
106
107	## Integration
108
109	This skill works well with:
110	- `software-development/code-review` — for what reviewers will check
111	- `software-development/systematic-debugging` — if CI fails after push
112
113	---
114	_Generated by [Skill Factory](https://github.com/your-username/hermes-skill-factory) — example output_

People who liked this also viewed

6 picks

Type

paperclip-create-agentCreate new agents in Paperclip with governance-aware hiring. Use when you need to inspect adapter configuration options, compare existing agent configs, draft a new agent prompt/config, and submit a hSkillsJul 2026157k5
subagent-driven-developmentUse when executing implementation plans with independent tasks in the current sessionSkillsJul 2026154k259k
dispatching-parallel-agentsUse when facing 2+ independent tasks that can be worked on without shared state or sequential dependenciesSkillsJul 2026143k259k
browser-act-skill-forgeForges reusable Skill packages (SKILL.md + scripts) from website exploration via browser-act — no re-exploration later. Use when: user wants a reusable Skill for any website, needs to understand a sitSkillsJul 202685k4.6k
wizardGenerate an interactive bash wizard that walks a human through a manual procedure — third-party setup, a one-off migration, an A→B state transition — opening URLs, capturing values, confirming each stSkillsJul 202675k182k
wonda-cliUsing the Wonda CLI to generate images, videos, music, and audio from the terminal — plus LinkedIn, Reddit, and X/Twitter research and automationSkillsJul 202666k137

git-pr-workflow

447stars60forks

View on GitHub

How to install git-pr-workflow?

romanescu11/hermes-skill-factory/git-pr-workflow

$npx -y skills add Romanescu11/hermes-skill-factory --skill git-pr-workflow

Installs into the current project.

Summary

End-to-end workflow for creating a clean, reviewed pull request from a feature branch.

Files · 1

View on GitHub

SKILL.md

1	# Git PR Workflow
2
3	A repeatable, disciplined workflow for turning work-in-progress code into a clean pull request ready for review. Covers branch hygiene, commit quality, and PR description best practices.
4
5	## When to Activate
6
7	Activate this skill when:
8	- You've finished a feature or fix and are ready to open a PR
9	- You need to prepare a branch for code review
10	- You want to ensure your PR passes CI before review
11
12	## Workflow
13
14	### Phase 1: Branch & Commit Hygiene
15
16	Clean up the branch before opening the PR.
17
18	Steps:
19	1. Run `git status` to confirm working tree is clean
20	2. Run `git log origin/main..HEAD --oneline` to review commits
21	3. Squash or reword any "WIP", "fix typo", or noise commits with `git rebase -i origin/main`
22	4. Ensure each commit has a clear imperative message: `Add user auth`, not `added stuff`
23	5. Run `git diff origin/main` for a final sanity check
24
25	Before moving on:
26	- [ ] No WIP commits remain
27	- [ ] All commits have clear messages
28	- [ ] No unintended files are staged
29
30	### Phase 2: CI Pre-flight
31
32	Run tests locally before pushing.
33
34	Steps:
35	1. Run the test suite: `pytest` / `npm test` / project-specific command
36	2. Run the linter: `ruff check .` / `eslint .` / equivalent
37	3. Fix any failures — do NOT push a red branch
38	4. Push the branch: `git push -u origin HEAD`
39
40	Before moving on:
41	- [ ] All tests pass locally
42	- [ ] Linter reports no errors
43
44	### Phase 3: PR Description
45
46	Open the PR with a description that makes reviewers' lives easy.
47
48	Steps:
49	1. Open the PR on GitHub / GitLab
50	2. Title: imperative mood, under 60 chars — `Add OAuth2 login flow`
51	3. Body: use this structure:
52	```
53	## What
54	[1-3 bullets: what changed]
55
56	## Why
57	[Context: issue link, ticket, or motivation]
58
59	## How to Test
60	[Checklist of manual test steps]
61
62	## Screenshots (if UI change)
63	```
64	4. Link to any related issues: `Closes #123`
65	5. Assign reviewers and labels
66
67	Before moving on:
68	- [ ] PR title follows convention
69	- [ ] Description has What / Why / How to Test
70	- [ ] Reviewers assigned
71
72	## Quality Checklist
73
74	- [ ] Branch is rebased on top of `main`
75	- [ ] No merge conflicts
76	- [ ] CI is green after push
77	- [ ] PR description complete
78	- [ ] Self-reviewed the diff one more time
79
80	## Examples
81
82	### Example 1: Feature PR
83
84	Working on a new login page. After finishing:
85	1. `git rebase -i origin/main` → squash 4 commits into 1: `Add OAuth2 login page`
86	2. `pytest` → all pass
87	3. `git push -u origin feature/oauth-login`
88	4. Open PR: title `Add OAuth2 login page`, link to issue #88
89	5. Assign 2 reviewers, add label `feature`
90
91	### Example 2: Bug Fix PR
92
93	Fixed a null pointer in the payment service:
94	1. Single commit already clean: `Fix null pointer in PaymentService.charge`
95	2. `npm test` → passes
96	3. `git push`, open PR titled `Fix null pointer in PaymentService`
97	4. Body explains the root cause and how to reproduce before the fix
98
99	## Anti-patterns
100
101	- ❌ Opening a PR from `main` directly
102	- ❌ Pushing without running tests first
103	- ❌ PR descriptions that just say "fixes bug"
104	- ❌ 47-commit PRs with no squashing
105	- ❌ Assigning reviewers before CI is green
106
107	## Integration
108
109	This skill works well with:
110	- `software-development/code-review` — for what reviewers will check
111	- `software-development/systematic-debugging` — if CI fails after push
112
113	---
114	_Generated by [Skill Factory](https://github.com/your-username/hermes-skill-factory) — example output_

People who liked this also viewed

6 picks

Type