How do I install the Create Pr skill?

Run npx skillmds@latest add ng-zorro/create-pr in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Create Pr safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Create Pr?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Create Pr free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Create Pr?

ng-zorro (@ng-zorro) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Create Pr by ng-zorro — Agent Skill

Name: Create Pr
Author: ng-zorro

File contents

NG-ZORRO Pull Request

Prepare a PR from the whole branch delta, not only the working tree or most recent commit. Inspect the current branch, remotes, its probable base, git log <base>..HEAD, and git diff <base>...HEAD. Use a user-specified base when present; otherwise infer it from repository state and flag uncertainty. master is the normal contribution target, while release and maintenance PRs must follow the project release workflow.

Target repository

Open contribution PRs against NG-ZORRO/ng-zorro-antd; use master unless the user specifies another target. Resolve the PR destination independently of local remote names, which are not part of the workflow contract. Compare against the target repository's base branch, inspect that repository for an existing matching PR, and identify the owner and branch for the cross-repository head.

When presenting a PR proposal, state the target repository and base branch alongside the head in <owner>:<branch> form. After confirmation, re-check all three values before pushing and creating the PR.

Read and fill .github/PULL_REQUEST_TEMPLATE.md rather than inventing a body structure. Preserve its sections, remove instructional comments, and check only items supported by the branch contents and validation actually performed.

Draft:

an English title that summarizes the branch's principal user-visible change and follows the repository's commit-message convention;
the PR type matching the main outcome;
current and new behavior, including the linked issue when known;
an accurate breaking-change decision and migration information when applicable; and
other information that helps review, such as focused validation or screenshots for visible changes.

Treat site-only, documentation-only, test-only, CI, and internal maintenance changes as such; do not manufacture user-facing behavior or release notes for them. For a release PR, defer to version-release.

Present the proposed target repository, base branch, head, title, body, and any assumptions for user confirmation before pushing a branch or calling gh pr create. Then create the PR only with the confirmed content.

---name: create-prdescription: Prepare or create an NG-ZORRO pull request using the repository template. Use when asked to open, draft, summarize, or create a PR for branch changes.---# NG-ZORRO Pull RequestPrepare a PR from the whole branch delta, not only the working tree or most recent commit. Inspect the current branch, remotes, its probable base, `git log <base>..HEAD`, and `git diff <base>...HEAD`. Use a user-specified base when present; otherwise infer it from repository state and flag uncertainty. `master` is the normal contribution target, while release and maintenance PRs must follow the project release workflow.## Target repositoryOpen contribution PRs against `NG-ZORRO/ng-zorro-antd`; use `master` unless the user specifies another target. Resolve the PR destination independently of local remote names, which are not part of the workflow contract. Compare against the target repository's base branch, inspect that repository for an existing matching PR, and identify the owner and branch for the cross-repository head.When presenting a PR proposal, state the target repository and base branch alongside the head in `<owner>:<branch>` form. After confirmation, re-check all three values before pushing and creating the PR.Read and fill [`.github/PULL_REQUEST_TEMPLATE.md`](../../../.github/PULL_REQUEST_TEMPLATE.md) rather than inventing a body structure. Preserve its sections, remove instructional comments, and check only items supported by the branch contents and validation actually performed.Draft:- an English title that summarizes the branch's principal user-visible change and follows the repository's commit-message convention;- the PR type matching the main outcome;- current and new behavior, including the linked issue when known;- an accurate breaking-change decision and migration information when applicable; and- other information that helps review, such as focused validation or screenshots for visible changes.Treat site-only, documentation-only, test-only, CI, and internal maintenance changes as such; do not manufacture user-facing behavior or release notes for them. For a release PR, defer to `version-release`.Present the proposed target repository, base branch, head, title, body, and any assumptions for user confirmation before pushing a branch or calling `gh pr create`. Then create the PR only with the confirmed content.

Frequently asked questions

Create Pr