Skip to content

Commit ace732b

Browse files
committed
feat(github): add workflow automation prompts and git-commit skill
Introduce templates for automated issue, PR, and milestone management alongside a standardized git commit convention guide.
1 parent 462062f commit ace732b

5 files changed

Lines changed: 533 additions & 0 deletions

File tree

Lines changed: 103 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,103 @@
1+
# Create Issue From Branch Changes
2+
3+
Create or update a GitHub issue from the changes in the current branch compared to main.
4+
5+
## Requirements
6+
7+
1. Compare changes from origin/main..HEAD and infer the user-facing goal.
8+
2. Do not include implementation details (no file lists, refactor notes, internal mechanics).
9+
3. Ask before editing the issue:
10+
- Which label should be used?
11+
- Which milestone should be used?
12+
4. Defaults:
13+
- If label is not provided, use improvement.
14+
- If milestone is not provided, use the latest open milestone.
15+
5. The issue description must be well-formatted Markdown.
16+
6. Use this Markdown structure exactly (omit empty sections):
17+
- ## Summary
18+
- ## Goal
19+
- ## Success Criteria
20+
- ## References
21+
7. Keep language concise, goal-oriented, and user-facing.
22+
23+
## Operational Steps
24+
25+
1. Ensure branch comparison is up to date:
26+
27+
```bash
28+
git fetch origin main --quiet
29+
git log --oneline --no-merges origin/main..HEAD
30+
git diff --name-status origin/main..HEAD
31+
```
32+
33+
2. Ask:
34+
- Label? (default: improvement)
35+
- Milestone? (default: latest open milestone)
36+
37+
3. Resolve defaults:
38+
39+
```bash
40+
LABEL="${LABEL:-improvement}"
41+
42+
if [ -z "$MILESTONE" ]; then
43+
MILESTONE="$(gh api repos/{owner}/{repo}/milestones --paginate -f state=open --jq 'sort_by(.number) | last | .title')"
44+
fi
45+
```
46+
47+
4. Build a well-formatted Markdown body in a temp file:
48+
49+
```bash
50+
cat > /tmp/issue-body.md <<'EOF'
51+
## Summary
52+
<goal-focused summary>
53+
54+
## Goal
55+
<what outcome we want>
56+
57+
## Success Criteria
58+
- <criterion 1>
59+
- <criterion 2>
60+
61+
## References
62+
- <optional links>
63+
EOF
64+
```
65+
66+
5. Suggest a title in this style:
67+
- [IMPROVEMENT]: <goal-focused title>
68+
- Adapt prefix to selected label where appropriate (for example: [FEATURE]: ...).
69+
70+
6. Create or update issue:
71+
72+
Create:
73+
74+
```bash
75+
gh issue create \
76+
--title "<TITLE>" \
77+
--label "$LABEL" \
78+
--milestone "$MILESTONE" \
79+
--body-file /tmp/issue-body.md
80+
```
81+
82+
Update existing:
83+
84+
```bash
85+
gh issue edit <ISSUE_NUMBER> \
86+
--title "<TITLE>" \
87+
--add-label "$LABEL" \
88+
--milestone "$MILESTONE" \
89+
--body-file /tmp/issue-body.md
90+
```
91+
92+
7. Verify and report final state:
93+
94+
```bash
95+
gh issue view <ISSUE_NUMBER> --json number,title,url,labels,milestone,body
96+
```
97+
98+
Report:
99+
- Issue number and URL
100+
- Final title
101+
- Final label(s)
102+
- Final milestone
103+
- Confirmation that body is well-formatted Markdown and goal-focused
Lines changed: 113 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,113 @@
1+
# Create PR From Branch Changes
2+
3+
Create or update a GitHub pull request from the current branch into the fork's main branch with a well-formatted PR description.
4+
5+
## Requirements
6+
7+
1. Compare changes from origin/main..HEAD and infer the user-facing intent.
8+
2. Keep the PR description aligned with the actual branch changes.
9+
3. The PR description must be well-formatted Markdown.
10+
4. The PR must reference the issue it resolves using closing keywords (for example: Resolves #1234).
11+
5. If no issue number is provided, ask for it before creating or updating the PR.
12+
6. Keep language concise, outcome-focused, and reviewer-friendly.
13+
7. Do not include irrelevant implementation noise; summarize what matters for review.
14+
8. Whenever new commits are pushed that change scope, update the PR description so it stays in sync with current branch changes.
15+
16+
## PR Markdown Template
17+
18+
Use this structure (omit empty sections):
19+
- ## Summary
20+
- ## Why
21+
- ## Validation
22+
- ## Issue
23+
24+
Example:
25+
26+
```md
27+
## Summary
28+
- <high-level change 1>
29+
- <high-level change 2>
30+
31+
## Why
32+
- <problem or goal>
33+
34+
## Validation
35+
- <tests run>
36+
- <results>
37+
38+
## Issue
39+
Resolves #<issue-number>
40+
```
41+
42+
## Operational Steps
43+
44+
1. Ensure branch comparison is current:
45+
46+
```bash
47+
git fetch origin main --quiet
48+
git log --oneline --no-merges origin/main..HEAD
49+
git diff --name-status origin/main..HEAD
50+
```
51+
52+
2. Determine branch and existing PR state:
53+
54+
```bash
55+
BRANCH="$(git rev-parse --abbrev-ref HEAD)"
56+
GH_PAGER=cat GH_FORCE_TTY=0 gh pr list --head "$BRANCH" --json number,title,url,state
57+
```
58+
59+
3. Ask for required metadata if missing:
60+
- Target issue number to resolve
61+
- PR title override (optional)
62+
63+
4. Build or refresh PR body in a temp file:
64+
65+
```bash
66+
cat > /tmp/pr-body.md <<'EOF'
67+
## Summary
68+
- <high-level change 1>
69+
- <high-level change 2>
70+
71+
## Why
72+
- <problem or goal>
73+
74+
## Validation
75+
- <tests run>
76+
- <results>
77+
78+
## Issue
79+
Resolves #<issue-number>
80+
EOF
81+
```
82+
83+
5. Create PR if none exists:
84+
85+
```bash
86+
GH_PAGER=cat GH_FORCE_TTY=0 gh pr create \
87+
--base main \
88+
--head "$BRANCH" \
89+
--title "<PR title>" \
90+
--body-file /tmp/pr-body.md
91+
```
92+
93+
6. Update PR if one already exists, or after new commits change scope:
94+
95+
```bash
96+
GH_PAGER=cat GH_FORCE_TTY=0 gh pr edit <PR_NUMBER> \
97+
--title "<PR title>" \
98+
--body-file /tmp/pr-body.md
99+
```
100+
101+
7. Verify final PR state:
102+
103+
```bash
104+
GH_PAGER=cat GH_FORCE_TTY=0 gh pr view <PR_NUMBER> --json number,title,url,body
105+
```
106+
107+
## Completion Checklist
108+
109+
- PR exists and targets main
110+
- Description is well-formatted Markdown
111+
- Description matches current branch changes
112+
- Issue reference uses closing keyword (Resolves/Fixes/Closes #...)
113+
- PR body was refreshed after any scope-changing push
Lines changed: 96 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,96 @@
1+
# Prepare Release Milestone
2+
3+
Prepare release tracking on GitHub without creating a release.
4+
5+
## Requirements
6+
7+
1. Describe the release preparation workflow before taking action:
8+
- Confirm the destination milestone exists or create it.
9+
- Move the closed issues and closed pull requests from the source milestone to the destination milestone.
10+
- Verify that every moved issue and pull request has at least one allowed label.
11+
- Do not create a GitHub release.
12+
2. Ask the user for both:
13+
- Source milestone
14+
- Destination milestone
15+
3. Use only these allowed labels when validating moved items:
16+
- breaking change
17+
- bug
18+
- dependencies
19+
- documentation
20+
- feature
21+
- improvement
22+
- build
23+
4. Treat an item as invalid if:
24+
- It has no labels.
25+
- None of its labels are in the allowed list.
26+
5. Report any invalid items clearly and stop before any release creation step.
27+
6. Keep the response concise and operational.
28+
29+
## Operational Steps
30+
31+
1. Ask:
32+
- Source milestone?
33+
- Destination milestone?
34+
35+
2. Summarize the plan:
36+
- Check whether the destination milestone already exists.
37+
- Create the destination milestone if needed.
38+
- Find closed issues in the source milestone.
39+
- Find closed pull requests in the source milestone.
40+
- Move those closed items to the destination milestone.
41+
- Verify labels on all moved items using the allowed label list.
42+
- Do not create a release.
43+
44+
3. Resolve milestone state:
45+
46+
```bash
47+
gh api repos/{owner}/{repo}/milestones --paginate --jq '.[] | [.number,.title,.state] | @tsv'
48+
gh api repos/{owner}/{repo}/milestones -X POST -f title='<DESTINATION_MILESTONE>'
49+
```
50+
51+
4. Collect closed items from the source milestone:
52+
53+
```bash
54+
gh issue list --repo {owner}/{repo} --milestone '<SOURCE_MILESTONE>' --state closed --limit 200 --json number,title,labels
55+
gh pr list --repo {owner}/{repo} --state closed --search 'milestone:"<SOURCE_MILESTONE>"' --limit 200 --json number,title,labels,state
56+
```
57+
58+
5. Move closed issues and closed pull requests to the destination milestone:
59+
60+
```bash
61+
gh issue edit <ISSUE_NUMBER> --repo {owner}/{repo} --milestone '<DESTINATION_MILESTONE>'
62+
gh pr edit <PR_NUMBER> --repo {owner}/{repo} --milestone '<DESTINATION_MILESTONE>'
63+
```
64+
65+
6. Verify labels against this allowlist:
66+
67+
```text
68+
breaking change
69+
bug
70+
dependencies
71+
documentation
72+
feature
73+
improvement
74+
build
75+
```
76+
77+
Validation rules:
78+
- Each moved item must have at least one label.
79+
- At least one assigned label must match the allowlist exactly.
80+
- If any moved item fails validation, report the item number, title, and labels.
81+
82+
7. Verify final milestone state and report:
83+
84+
```bash
85+
gh issue list --repo {owner}/{repo} --milestone '<DESTINATION_MILESTONE>' --state closed --limit 200 --json number,title,labels
86+
gh pr list --repo {owner}/{repo} --state closed --search 'milestone:"<DESTINATION_MILESTONE>"' --limit 200 --json number,title,labels,state
87+
```
88+
89+
Report:
90+
- Source milestone
91+
- Destination milestone
92+
- Whether the destination milestone was created or already existed
93+
- Count of moved closed issues
94+
- Count of moved closed pull requests
95+
- Any moved items missing allowed labels
96+
- Confirmation that no GitHub release was created

0 commit comments

Comments
 (0)