github-pr-workflow

Name: github-pr-workflow
Author: AlexAI-MCP

132stars24forks

How to install github-pr-workflow?

alexai-mcp/hermes-ccc/github-pr-workflow

$npx -y skills add AlexAI-MCP/hermes-CCC --skill github-pr-workflow

Installs into the current project.

Summary

Run a disciplined GitHub pull request workflow from branch creation through merge. Use when opening a PR, updating a PR after review, preparing review-ready diffs, managing draft versus ready states, or landing changes with clear validation and risk notes.

Files · 1

View on GitHub

SKILL.md

1	# GitHub PR Workflow
2
3	## Purpose
4
5	- Keep pull requests reviewable and easy to merge safely.
6	- Separate implementation from presentation and merge hygiene.
7	- Make reviewer intent clear through titles, descriptions, and test plans.
8	- Reduce merge friction by handling updates systematically.
9	- Preserve traceability between issue, code, and validation.
10
11	## Activation Signals
12
13	- Use this skill when opening a new branch for changes.
14	- Use this skill when preparing a PR for review.
15	- Use this skill when updating a PR after feedback.
16	- Use this skill when turning a draft into a merge-ready PR.
17	- Use this skill when planning labels, reviewers, and merge strategy.
18
19	## Core Workflow
20
21	1. Start from the correct base branch.
22	2. Keep the branch scope tight.
23	3. Make coherent commits.
24	4. Validate before opening the PR.
25	5. Open a draft PR if the implementation is not review-ready.
26	6. Write a useful PR title and description.
27	7. Address review comments with focused follow-up commits.
28	8. Re-validate before merge.
29	9. Merge with the right strategy.
30
31	## Branch Rules
32
33	- Branch from the intended base, not a stale local branch.
34	- Name the branch after the work, not the date.
35	- Keep unrelated changes out of the branch.
36	- Avoid force-push unless the team allows it and history cleanup is worth it.
37
38	## Commit Rules
39
40	- One logical change per commit when practical.
41	- Use commit messages that explain intent, not just files touched.
42	- Avoid mixing refactor and bug fix unless inseparable.
43	- Keep WIP commits local when possible.
44
45	## Pre-PR Validation
46
47	- run targeted tests
48	- run lint if relevant
49	- check formatting if the repo enforces it
50	- read the diff yourself before asking others to do it
51	- note any unverified areas explicitly
52
53	## PR Title Rules
54
55	- Lead with the user-visible or system-visible change.
56	- Keep it specific.
57	- Avoid "misc fixes".
58	- Prefer imperative summaries such as "Fix auth redirect loop during token refresh".
59
60	## PR Description Template
61
62	```markdown
63	## Summary
64	- ...
65
66	## Why
67	- ...
68
69	## Testing
70	- `pytest tests/test_auth.py::test_login_redirect_does_not_loop_when_session_is_hydrated -vv`
71
72	## Risks
73	- ...
74	```
75
76	## Draft Versus Ready
77
78	- Open as draft when the implementation is incomplete.
79	- Open as draft when feedback on direction is needed before polishing.
80	- Convert to ready only after validation and self-review.
81	- Do not ask for full review while the branch still contains known broken paths.
82
83	## Review Update Procedure
84
85	1. Group comments by theme.
86	2. Resolve the highest-risk comments first.
87	3. Make focused follow-up commits.
88	4. Reply with what changed and where.
89	5. Re-run the relevant validation.
90	6. Avoid "fixed" with no evidence.
91
92	## Merge Strategy
93
94	- Use merge commit when preserving branch history matters.
95	- Use squash when the branch contains several noisy intermediate commits.
96	- Use rebase when the repository prefers linear history and the branch is clean.
97	- Follow repo policy when it is explicit.
98
99	## Useful Commands
100
101	```bash
102	git checkout -b fix-auth-redirect-loop
103	git status --short
104	git diff --stat
105	gh pr create --draft --title "Fix auth redirect loop during token refresh" --body-file PR_BODY.md
106	gh pr view --web
107	```
108
109	## Reviewer Experience Rules
110
111	- Keep the diff small enough to review in one sitting.
112	- Explain why the change exists.
113	- State how you validated it.
114	- Admit unknowns.
115	- Link related issues or incidents.
116
117	## Anti-Patterns
118
119	- giant PRs with mixed concerns
120	- vague PR titles
121	- empty descriptions
122	- no testing notes
123	- force-pushing away reviewer context without warning
124	- mixing comment resolution with unrelated cleanup
125
126	## Output Contract
127
128	When reporting PR progress, include:
129
130	- branch name
131	- PR state: draft or ready
132	- summary of changes
133	- validation performed
134	- remaining risks or blockers
135
136	## Example Status Block
137
138	```markdown
139	PR workflow status:
140	- Branch: fix-auth-redirect-loop
141	- State: draft
142	- Summary: auth middleware now waits for hydrated session token before redirecting
143	- Validation: targeted auth regression test passed
144	- Remaining blocker: reviewer input needed on fallback behavior during refresh timeout
145	```
146
147	## Decision Rules
148
149	- If the diff is large, split before asking for review when possible.
150	- If the PR changes behavior, tests should usually change too.
151	- If validation is partial, state the gap explicitly.
152	- If the branch drifted from base, rebase or merge base before final review.
153
154	## Recovery Moves
155
156	- If review comments are scattered, create a comment-response

People who liked this also viewed

6 picks

Type

github-pr-workflow

132stars24forks

View on GitHub

How to install github-pr-workflow?

alexai-mcp/hermes-ccc/github-pr-workflow

$npx -y skills add AlexAI-MCP/hermes-CCC --skill github-pr-workflow

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# GitHub PR Workflow
2
3	## Purpose
4
5	- Keep pull requests reviewable and easy to merge safely.
6	- Separate implementation from presentation and merge hygiene.
7	- Make reviewer intent clear through titles, descriptions, and test plans.
8	- Reduce merge friction by handling updates systematically.
9	- Preserve traceability between issue, code, and validation.
10
11	## Activation Signals
12
13	- Use this skill when opening a new branch for changes.
14	- Use this skill when preparing a PR for review.
15	- Use this skill when updating a PR after feedback.
16	- Use this skill when turning a draft into a merge-ready PR.
17	- Use this skill when planning labels, reviewers, and merge strategy.
18
19	## Core Workflow
20
21	1. Start from the correct base branch.
22	2. Keep the branch scope tight.
23	3. Make coherent commits.
24	4. Validate before opening the PR.
25	5. Open a draft PR if the implementation is not review-ready.
26	6. Write a useful PR title and description.
27	7. Address review comments with focused follow-up commits.
28	8. Re-validate before merge.
29	9. Merge with the right strategy.
30
31	## Branch Rules
32
33	- Branch from the intended base, not a stale local branch.
34	- Name the branch after the work, not the date.
35	- Keep unrelated changes out of the branch.
36	- Avoid force-push unless the team allows it and history cleanup is worth it.
37
38	## Commit Rules
39
40	- One logical change per commit when practical.
41	- Use commit messages that explain intent, not just files touched.
42	- Avoid mixing refactor and bug fix unless inseparable.
43	- Keep WIP commits local when possible.
44
45	## Pre-PR Validation
46
47	- run targeted tests
48	- run lint if relevant
49	- check formatting if the repo enforces it
50	- read the diff yourself before asking others to do it
51	- note any unverified areas explicitly
52
53	## PR Title Rules
54
55	- Lead with the user-visible or system-visible change.
56	- Keep it specific.
57	- Avoid "misc fixes".
58	- Prefer imperative summaries such as "Fix auth redirect loop during token refresh".
59
60	## PR Description Template
61
62	```markdown
63	## Summary
64	- ...
65
66	## Why
67	- ...
68
69	## Testing
70	- `pytest tests/test_auth.py::test_login_redirect_does_not_loop_when_session_is_hydrated -vv`
71
72	## Risks
73	- ...
74	```
75
76	## Draft Versus Ready
77
78	- Open as draft when the implementation is incomplete.
79	- Open as draft when feedback on direction is needed before polishing.
80	- Convert to ready only after validation and self-review.
81	- Do not ask for full review while the branch still contains known broken paths.
82
83	## Review Update Procedure
84
85	1. Group comments by theme.
86	2. Resolve the highest-risk comments first.
87	3. Make focused follow-up commits.
88	4. Reply with what changed and where.
89	5. Re-run the relevant validation.
90	6. Avoid "fixed" with no evidence.
91
92	## Merge Strategy
93
94	- Use merge commit when preserving branch history matters.
95	- Use squash when the branch contains several noisy intermediate commits.
96	- Use rebase when the repository prefers linear history and the branch is clean.
97	- Follow repo policy when it is explicit.
98
99	## Useful Commands
100
101	```bash
102	git checkout -b fix-auth-redirect-loop
103	git status --short
104	git diff --stat
105	gh pr create --draft --title "Fix auth redirect loop during token refresh" --body-file PR_BODY.md
106	gh pr view --web
107	```
108
109	## Reviewer Experience Rules
110
111	- Keep the diff small enough to review in one sitting.
112	- Explain why the change exists.
113	- State how you validated it.
114	- Admit unknowns.
115	- Link related issues or incidents.
116
117	## Anti-Patterns
118
119	- giant PRs with mixed concerns
120	- vague PR titles
121	- empty descriptions
122	- no testing notes
123	- force-pushing away reviewer context without warning
124	- mixing comment resolution with unrelated cleanup
125
126	## Output Contract
127
128	When reporting PR progress, include:
129
130	- branch name
131	- PR state: draft or ready
132	- summary of changes
133	- validation performed
134	- remaining risks or blockers
135
136	## Example Status Block
137
138	```markdown
139	PR workflow status:
140	- Branch: fix-auth-redirect-loop
141	- State: draft
142	- Summary: auth middleware now waits for hydrated session token before redirecting
143	- Validation: targeted auth regression test passed
144	- Remaining blocker: reviewer input needed on fallback behavior during refresh timeout
145	```
146
147	## Decision Rules
148
149	- If the diff is large, split before asking for review when possible.
150	- If the PR changes behavior, tests should usually change too.
151	- If validation is partial, state the gap explicitly.
152	- If the branch drifted from base, rebase or merge base before final review.
153
154	## Recovery Moves
155
156	- If review comments are scattered, create a comment-response

People who liked this also viewed

6 picks

Type