Add create-pull-request skill for GitHub PR automation

[MoshiMoshiMochi]

What is the purpose of this pull request?

• Improve developer experience

Overview of changes:

Adds a create-pull-request skill that automates GitHub PR creation following project conventions, supporting fork-to-upstream workflows with comprehensive diff analysis and template-based PR drafting. This PR was generated using the create-pull-request skill.

Anything you'd like to highlight/discuss:

The skill provides step-by-step guidance through PR creation including prerequisites checking, context gathering, git best practices, and automated template filling. It handles upstream remote detection and provides options for standard, draft, or dry-run PR creation.

Testing instructions:

Run the skill with '/skill create-pull-request' and verify it guides through the PR creation process correctly. Test the dry-run option to preview PR creation without actually creating one.

Proposed commit message: (wrap lines at 72 characters)

Add create-pull-request skill for GitHub PR automation

This adds a comprehensive skill that automates GitHub pull request creation
following project conventions. The skill handles fork-to-upstream workflows,
performs deep diff analysis, and provides step-by-step guidance through the
entire PR creation process including prerequisites checking, context gathering,
and template-based PR drafting.

---

Checklist: ☑️

• Updated the documentation for feature additions and enhancements
• Added tests for bug fixes or features
• Linked all related issues
• No unrelated changes

---

Reviewer checklist:

Indicate the SEMVER impact of the PR:

• Major (when you make incompatible API changes)
• Minor (when you add functionality in a backward compatible manner)
• Patch (when you make backward compatible bug fixes)

At the end of the review, please label the PR with the appropriate label: r.Major, r.Minor, r.Patch.

Breaking change release note preparation (if applicable):

• To be included in the release note for any feature that is made obsolete/breaking

Give a brief explanation note about:

• what was the old feature that was made obsolete
• any replacement feature (if any), and
• how the author should modify his website to migrate from the old feature to the replacement feature (if possible).

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 71.83%. Comparing base (0f70952) to head (d14888b).
⚠️ Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2807      +/-   ##
==========================================
+ Coverage   71.76%   71.83%   +0.07%     
==========================================
  Files         134      134              
  Lines        7316     7331      +15     
  Branches     1614     1619       +5     
==========================================
+ Hits         5250     5266      +16     
+ Misses       2020     1937      -83     
- Partials       46      128      +82     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[MoshiMoshiMochi]

Whelp, this will remain a WIP I guess.😢

Some things I definitely need to keep looking into to refine this

Issue 1 : No idea why it deleted the other checkboxes under What is the purpose of this pull request?

• It seems to work pretty fine with understand that it needs to follow the PULL_REQUEST_TEMPLATE but for some reason this time it deleted the other checkboxes?
• This is the first time it has happened... all my dry runs seem to leave the other checkboxes unchecked. Frustrating that it happened now, but I guess better now than later. 😢

Issue 2: Not sure why it failed to recognize the Important tag under ### Create PR with gh CLI section

• These important tags seem to work pretty well most of the time in helping the agent understand what to do at each step,
• for example, when I've tested it, it always seems to prompt the user when there are uncommitted changes and never assumes which step to take.
• which is even more frustrating that it fails to realize the most important of the Important tags. 🫤
• In this case, I prompted it Run create-pull-request skill. It was suppose to ask me which option I would like to proceed with (Standard, Draft, Dry Run)
• But instead, it just defaulted to Standard.
• TLDR: It wasn't suppose to create this PR without asking me for explicit confirmation.

Issue 3: I haven't tested the Skill's ability effectively create a PR for more complex changes.

• As this branch only contains changes made pertaining to this specific Skill. I have been unable to test its capabilities of creating a detailed PR for larger changes that involve different packages.
• I've tried to hopefully improve this by providing more details on how it should review the differences. But overall, I think we won't really know how big/small of an issue this is until we test it out on a bigger PR.

Issue 4: It isn't the best at accurately identifying which checkboxes to tick under the Overview of Changes section. (But it does do pretty well at doing so for the final checklist)

• It seems to get confuse and struggles to understand the difference between a Feature addition or enhancement and Improve developer experience.
• I've tried a lot of attempts at trying to be more and more specific to combat this, but for the most part, it still struggles to classify the changes I made in this branch as developer experience usually still classifying it as Feature addition...
• I think this is mainly because I have it use the commit messages and branch names during the information gathering stage, so its probably seeing my branch name feat/experiment-create-pr-skill and just defaulting to Feature addition... for the most part.
• So I guess this probably could be avoided if we were more explicit in our commit messages/branch naming,
• But hey, on the bright side, it got it right this time! 🎊 🥳
• Overall not the biggest issue I guess since we can just manually change easily.

But its not all doom and gloom because 🌞:

• This PR took a total of 1m 52s to run (so it doesn't take too long, but then again there aren't many changes for this PR)
• For small PRs like this it seems to do the job pretty fine thus far, specifically in understanding the purpose of the changes made and writing a detailed enough PR.
• Overall, hopefully this will be an effective tool in helping us summarize our changes made so that we can focus more of our time on explaining the details that it misses out on.

[MoshiMoshiMochi]

Oh and here are just a few of the other dry run attempts I made for reference.

Early Attempt

This was one of my first attempts of using the skill. There are a multitude of issues with this namely

• Incorrect classification of purpose of PR
• Incorrect classification of final checklist

But through more explicit instructions, it seems to be better able to identify these checkboxes. Mainly documentation as I had it start to only check this if files within docs/ were updated/added

---

What is the purpose of this pull request?

• Documentation update
• Bug fix
• Feature addition or enhancement
• Code maintenance
• DevOps
• Improve developer experience
• Others, please explain:

Overview of changes:

Add a new GitHub skill for creating pull requests that follows MarkBind project conventions and supports fork-to-upstream workflows.

Anything you'd like to highlight/discuss:

This skill was adapted from Cline's original create-pull-request skill with modifications to support fork-to-upstream workflows and automated upstream remote detection. The skill provides comprehensive guidance for PR creation including prerequisite checks, context gathering, git best practices, and template-based PR generation.

Testing instructions:

Test the skill by running it on a feature branch with changes. Verify that it correctly:

• Detects gh CLI installation and authentication
• Identifies upstream remotes and base branches
• Analyzes commits and diffs
• Generates PR descriptions following the MarkBind template
• Handles common error scenarios

Proposed commit message: (wrap lines at 72 characters)

Add create-pull-request GitHub skill

Add a comprehensive GitHub skill for creating pull requests that follows
MarkBind project conventions. The skill supports fork-to-upstream workflows,
automated upstream remote detection, and template-based PR generation.
Adapted from Cline's original skill with MarkBind-specific modifications.

---

Checklist: ☑️

• Updated the documentation for feature additions and enhancements
• Added tests for bug fixes or features
• Linked all related issues
• No unrelated changes

---

Reviewer checklist:

Indicate the SEMVER impact of the PR:

• Major (when you make incompatible API changes)
• Minor (when you add functionality in a backward compatible manner)
• Patch (when you make backward compatible bug fixes)

At the end of the review, please label the PR with the appropriate label: r.Major, r.Minor, r.Patch.

Breaking change release note preparation (if applicable):

• To be included in the release note for any feature that is made obsolete/breaking

Give a brief explanation note about:

• what was the old feature that was made obsolete
• any replacement feature (if any), and
• how the author should modify his website to migrate from the old feature to the replacement feature (if possible).

---

After a lot more explicit instructions

Issues with this PR:

• Incorrectly classifies purpose of PR
• Converted bolded What is the purpose of this pull request into a level 2 header
• Not the best testing instructions

What is the purpose of this pull request?

• Documentation update
• Bug fix
• Feature addition or enhancement
• Code maintenance
• DevOps
• Improve developer experience
• Others, please explain:

Overview of changes:

Add a comprehensive skill for creating GitHub pull requests following project conventions and best practices. This skill automates the PR creation process with proper template formatting and fork-to-upstream workflow support. This PR was generated using the create-pull-request skill.

Anything you'd like to highlight/discuss:

The skill includes detailed prerequisite checks, context gathering, PR template analysis, and proper commit message generation following SE-Education standards. It supports dry-run mode for previewing PRs before creation and includes comprehensive error handling for common scenarios.

Testing instructions:

Run "gh pr create" with the --dry-run flag to verify the PR content before actual creation.

Proposed commit message: (wrap lines at 72 characters)

Add create-pull-request skill for automated PR creation

---

Checklist: ☑️

• Updated the documentation for feature additions and enhancements
• Added tests for bug fixes or features
• Linked all related issues
• No unrelated changes

---

Reviewer checklist:

Indicate the SEMVER impact of the PR:

• Major (when you make incompatible API changes)
• Minor (when you add functionality in a backward compatible manner)
• Patch (when you make backward compatible bug fixes)

At the end of the review, please label the PR with the appropriate label: r.Major, r.Minor, r.Patch.

Breaking change release note preparation (if applicable):

• To be included in the release note for any feature that is made obsolete/breaking

Give a brief explanation note about:

• what was the old feature that was made obsolete
• any replacement feature (if any), and
• how the author should migrate from the old feature to the replacement feature (if possible).

---

[MoshiMoshiMochi]

@gerteck @Harjun751 @yihao03

Lemme know what yall think the worth of this skill would be and if yall have any other suggestions to improve this skill.

Probably can delete this PR once we're done discussing about if we wanna move forward with this proposed skill.

[yihao03]

hi @MoshiMoshiMochi i think this is certainly a great idea and would save a lot of time when working on this repo. I just have a few concerns

1. would this slowly evolve into a AI talking to AI kind of collaboration? where would the human touch go
2. PR descriptions sometimes go beyond simply documenting the changes, but also rationales of the changes, the technical decisions made for the changes, where does this fit in the bigger picture e.g. long term planning, linking to issues on github that might be relevant etc. while arguably these could all be supplied to the AI agents as context in one form or another, it would pretty much takes as much of even more effort than writing these ourselves.

Based on these reasonings, I thought that AI is best used for documenting changes and doing repetitive stuff, but the bulk of writing pr could still be done ourselves

[Harjun751]

Actually seems pretty sick.

I'm wondering if we can tune it abit further to drop the AI buzzwords (e.g. comprehensive skill) - maybe add some prompt input for it to keep concise/neutral?

As for @yihao03's concerns, I agree to an extent. I can see this being useful if we just limit it to overview of changes - that section is pretty mechanical. Writing out rationale, etc can come in the "anything you'd like to highlight" section which should be human-written IMO.

Though if it takes about 2 minutes to generate a simple overview of changes, I'm more inclined to believe we should simply write it out ourselves.

Cool experiment, though.

[MoshiMoshiMochi]

Hi guys, thanks for the quick replies. I do see and share the concerns you guys have mentioned too, especially if we were to use this skill purely to facilitate the full creation of the PR.

However, I think the purpose of this skill isn't to fully replace the human touch when writing a PR. Rather, its purpose would be a tool assisting the creation for PRs. Imo, if its able to accurately identify and capture parts which we already intended to write (especially in the anything you'd liketo discuss section), then we can just focus our attention on touching up and also including the more important details and rationale that it fails to capture.

But then again, as I've only tested with the changes made in this branch, I don't really know how it will perform for a branch with notably more complex changes.

ps: The reason I've left this and the other example PRs fully AI generated was to accurately show its current capabilities (and lack there of). By no means is this a replacement for the human touch of the PRs, rather a tool to assist the creation of PRs which we can then work on top of to hopefully save us time in the future.