SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsgithub-pr-issue

github-pr-issue

General & other

View repository

Updated 10-15 20:34

About this skill

GitHub CLI Skill（Issue/PR）

PR Review

  • First look at the PR overview, then pull the review / comment / thread details to ensure you are not relying on a single source.
  • When necessary, you can view the code of the corresponding local branch; before viewing, first git fetchto ensure the branch is in the latest remote state.
  • When the user asks to organize PR review comments, arrange them by severity from high to low, with numeric numbering, so the user can reply easily.
  • Display at most 10 items each time; if there are more, indicate at the end "N items remaining undisplayed".

Create Issue (non-interactive)

  1. Title and description style are the same as for PRs, and the content should remain concise and clear.
  2. Create in a non-interactive way, avoiding entering an editor or relying on manual input.
  3. After successful creation, output the complete Issue URL.

Create PR

The following title and description conventions are the default recommended format; if they conflict with existing constraints from the team/repository/platform, the existing constraints take precedence. If there are explicit requirements (such as requiring Chinese), follow them first.

  1. Confirm git status is clean,git push to the remote.
  2. Title style: English, following semantic commit conventions (such as feat(scope): short summary), concise and describing the core purpose; even if the title is required to be in Chinese, the semantic prefix must still be in English.
  3. Description style: English, short sentences and bullet points, prioritizing helping readers who do not look at the code quickly understand the motivation, changes, and verification method. Focus on what/why/testing, and avoid a running account and excessive implementation details. If the context is insufficient to clarify the goal or constraints, proactively confirm with the developer before writing. When proprietary terms, function names, method names, class names, API names, or configuration keys are involved, wrap them in inline code (backticks) to improve readability and accuracy.
  4. Default body format:
    • ## Why: 1-2 short sentences explaining why this change is being made, focusing on the problem background or goal.
    • ## What: 1-3 items describing the main changes, focusing on changes at the functional or behavioral level, without listing trivial implementation details.
    • ## Testing: Explain the verification method, commands, or scenarios; if untested, note the reason.
  5. Optional body blocks: add only when truly necessary.
    • ## Risks: Compatibility impact, potential risks, rollback considerations.
    • ## Notes: Points reviewers need to pay special attention to, or follow-up plans.
  6. Use non-interactive commands to create the PR, avoiding entering an interactive editing process; add parameters such as base and draft as needed.
  7. When modifying a PR, reuse the same non-interactive approach as when creating it, avoiding manual editing.
  8. After successful creation, output the complete PR URL.

Update Issue/PR title or description (prerequisite)

Before updating the title/description of an Issue or PR, you must first read the current title/body (the content about to be modified), and then make the modification.