Add create-pr skill encoding the project PR protocol#812
Merged
Conversation
The skill walks the user through opening a pull request that follows the modmesh PR protocol: concise subject, clear global description, "Related to #xxx" / "For issue #xxx" wording (closing keywords like "fixes #xxx" are blocked by a case-insensitive guardrail), draft by default, and a mandatory global review-request comment when ready. Workflow steps: confirm scope, verify branch state, draft the title and body for user approval, then open the PR via gh pr create using quoted heredocs for title/body so subject text can contain backticks, $, ", or apostrophes without escaping. After creation the skill reminds the author to add inline annotations when the diff is more than one-liner-ish. For issue solvcon#811.
Update create-pr to ask for clear, short, human-readable prose in the PR body and to reserve bullet lists for cases where prose would genuinely be unreadable, such as long enumerations or benchmark matrices. For issue solvcon#811.
Make step 2 explicit about dirty working trees: switch to git status --porcelain, show staged, unstaged, and untracked files separately, and ask the user how to proceed before staging anything. Forbid git add -A and git add . without confirmation so that stray local files do not enter the PR. Abort when the branch has no commits ahead of master. Drop the absolute force-push ban. Force-pushing a private fork branch before the PR exists is normal practice, and the absolute rule blocks legitimate history cleanup during iteration. Pushing directly to master/main and using --no-verify are still banned. Expand the post-creation inline-annotations reminder. Instead of just telling the user to add annotations, recommend the points that help the reviewer most: non-obvious decisions, subtle logic, intentional-looking dead code, known limitations and test-coverage gaps, and tricky diffs that mix reformatting with substantive edits. For issue solvcon#811.
The protocol requires a global PR comment that asks the maintainer to review when the PR is ready. Previously the skill drafted that comment, asked for approval, and posted it via gh pr comment. That blurred the line between the skill helping with mechanics and the skill speaking for the author. After creation the skill now only reminds the user, in plain language, that opening the review-request comment is their job. The skill no longer drafts the comment text and no longer calls gh pr comment. For issue solvcon#811.
tigercosmos
commented
May 23, 2026
Collaborator
Author
tigercosmos
left a comment
tigercosmos
left a comment
There was a problem hiding this comment.
@yungyuc Please take a look. I would suggest merging it first and revise it later based on real usage.
|
|
||
| # Create Pull Request (modmesh) | ||
|
|
||
| Authoritative reference is issue solvcon/modmesh#811 and the "Pull Request |
Collaborator
Author
There was a problem hiding this comment.
We can also remove this statement. I chose to keep it for now.
Member
There was a problem hiding this comment.
Please remove this reference. After merging this PR, this file becomes the authoritative reference.
| skill drafts text, present it for the user's review and edits before | ||
| posting. | ||
|
|
||
| ## Workflow |
Collaborator
Author
There was a problem hiding this comment.
Workflow confirmed while opening this PR.
| contain the literal token `BODY` on its own line, swap the delimiter | ||
| to something unique (e.g. `BODY_EOF_811`). | ||
|
|
||
| 5. **After creation.** Report the PR URL back to the user. Then: |
Collaborator
Author
There was a problem hiding this comment.
My favor part.
yungyuc
requested changes
May 23, 2026
|
|
||
| # Create Pull Request (modmesh) | ||
|
|
||
| Authoritative reference is issue solvcon/modmesh#811 and the "Pull Request |
Member
There was a problem hiding this comment.
Please remove this reference. After merging this PR, this file becomes the authoritative reference.
Collaborator
Author
|
@yungyuc please take a look. Thanks! |
Collaborator
Author
|
I like the skill: |
yungyuc
approved these changes
May 23, 2026
Member
yungyuc
left a comment
yungyuc
left a comment
There was a problem hiding this comment.
LGTM. I'll merge once CI finishes.
Closed
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds a Claude Code skill at
.claude/skills/create-pr/SKILL.mdthat helps the author open a pull request following the modmesh PR protocol from issue #811. The skill walks through confirming scope, verifying branch state, drafting the subject and body for approval, checking title and body for banned closing keywords ("close", "fix", "resolve" forms followed by#), and callinggh pr createwith text loaded from quoted heredocs so a subject containing backticks,$,", or apostrophes does not need escaping.PRs default to draft. Opening as ready-for-review triggers a mandatory global review-request comment step, because the "ready for review" button alone is not quotable in follow-ups. After creation the skill reminds the author to add inline annotations when the diff is more than one-liner-ish, and refuses to append attribution trailers since this project treats PR text as human-authored.
The skill also requires that PR description paragraphs are written as single unbroken lines separated by blank lines, rather than hard-wrapped at 79/80 columns. The source-code line-length limit does not belong in PR text; GitHub reflows to the viewer's width, and mid-sentence breaks render as ragged prose. This PR description itself follows the rule.
This PR is opened via the new
create-prskill.For issue #811.