SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsantdv-next-cli-create-pr

antdv-next-cli-create-pr

General & other

View repository

Updated 10-15 19:57

About this skill

Antdv Next CLI PR Creation Guidelines

Objectives

1. Generate the PR based on all changes in the current branch relative to the base branch, not just the last commit.

2. Prefer the repository's own PR template; when no template currently exists, use the Summary / Testing structure agreed upon in this skill.

3. The PR body uses English by default; Chinese may be used when the user explicitly requests it. The PR title always uses English and follows the naming format agreed upon in this document.

4. Before actually executing gh pr create , you must first give base、title、body to the user for confirmation; only after confirmation can the PR be created.

Basic Rules

1. Trigger by intent, not by phrase

As long as it can be determined that the user is requesting the creation of a PR, or preparing to create a PR, this skill should be used.

Do not restrict the trigger to fixed wording. Even if the user's expression is very short, very colloquial, or the request is incomplete, as long as they are not merely discussing the concept of a PR, you should enter this skill's workflow.

2. The body structure is subject to the repository's conventions

The current repository does not have .github/PULL_REQUEST_TEMPLATE*. Use by default:

  • ## Summary
  • ## Testing

If the repository later adds a PR template, you must first read and use the template; do not change section names on your own or delete the main structure.

3. The body defaults to English, but the title is fixed in English

Existing PR bodies are mainly in English, so the body uses English by default. When the user explicitly requests Chinese, a Chinese body may be used.

Regardless of which language the body uses:

  • PR title must be in English
  • PR title must conform to the Conventional Commits format
  • The title subject must start with a lowercase character, to pass .github/workflows/validate-pr-title.yml

4. Analyze the branch first, then write the PR

Before creating a PR, you must first look at:

  • the current branch name
  • the base branch
  • the list of commits in the current branch relative to the base branch
  • base...HEAD the full diff of

Do not write the PR based only on uncommitted changes in the working tree, and do not write the PR based only on the most recent commit.

5. Give a draft first, then create the PR

Regardless of whether the user says "just create the PR for me directly," you must first complete the following steps:

  1. generate a base、title、body draft
  2. clearly tell the user: this is the PR content to be submitted
  3. let the user confirm whether to continue creating, or modify it first
  4. Only after the user explicitly confirms can you actually execute gh pr create

If the user asks midway to modify the title, type, test description, target branch, etc., you should first update the draft and confirm again.

6. The title and body must have a clear division of labor

  • PR title: summarize the most important change in this branch in one English sentence
  • PR body: explain the main results, key approach, related issues, and actual verification results

The body is not a file-by-file ledger. Summarize "why it was changed" and "what impact it has on developers/users after the change."

7. Do not force writing when information is insufficient

If the following content is missing and cannot be reliably inferred from the branch changes:

  • base branch
  • related issue
  • nature of the change
  • testing or verification method

You may first give a draft and keep the parts that cannot be confirmed as items to be supplemented; if the user requests to create the PR directly, you must also first explain the missing items and wait for confirmation.

Execution Steps

1. Check the repository and PR environment

It is recommended to first confirm:

git status --short
git branch --show-current
git remote -v
gh auth status

If gh is unavailable, not logged in, the current directory is not a git repository, or the current branch is not suitable for submitting a PR, first explain the problem and do not continue fabricating results.

2. Determine the base branch

Do not use maindirectly without analysis. Determine in the following order:

  1. The user explicitly specified base branch -> use it directly
  2. If the current branch has usable "source clues", infer preferentially based on real Git information:
    • git branch -vv Check tracking / upstream
    • git reflog show <current-branch> Check whether it can be seen which branch it was checked out from
    • If necessary, combine with git merge-base HEAD <candidate-branch> to compare the fork point
  3. If it can be determined fairly reliably that "the current branch was branched off from a certain branch", preferentially use that branch as the base
  4. If it cannot be inferred reliably, fall back to the remote default branch or the repository default branch

It is recommended to check:

git branch --show-current
git branch -vv
git reflog show --date=local $(git branch --show-current)
git remote show origin

Note:

  • tracking / upstream can only serve as a clue and is not necessarily the absolutely correct "parent branch"
  • reflog If already cleaned up, results may not be obtainable
  • If the inference result is not certain enough, clearly mark it as an "inferred value" in the draft

Explanation for new feature branches

New feature PRs in this repository are usually also submitted to main. Only when the user explicitly requests a stacked PR, or Git history can reliably prove that the current branch is based on another feature branch, use a base other than main ; do not change the base on your own just because the type is feat .

3. Collect all changes on this branch

At minimum, check:

git log --oneline <base>..HEAD
git diff --stat <base>...HEAD
git diff <base>...HEAD

If necessary, also check:

git diff --name-only <base>...HEAD

When summarizing, cover all commits on the branch that will enter the PR, not just the last change.

4. Determine the body structure and language

First check whether there is .github/PULL_REQUEST_TEMPLATE*：

  • Exists: read and use the repository template
  • Does not exist: use the Summary / Testing structure

The body uses English by default; use Chinese only when the user explicitly requests Chinese.

5. Determine the PR type

It must be determined based on the "main result" of the entire branch, and should not be disturbed by a single file or commit.

Prioritize determining:

  1. Newly added capabilities usable by CLI, Agent, MCP, or integrators -> feat
  2. Fixing incorrect behavior -> fix
  3. Only modifying documentation or skills -> docs
  4. Mainly modifying build or packaging configuration -> build
  5. Mainly modifying workflow / CI -> ci
  6. Mainly modifying tests -> test
  7. Code cleanup with no external behavior changes -> refactor
  8. Performance optimization -> perf
  9. Dependencies or internal maintenance -> chore
  10. Version release -> release

For example:

  • Add MCP tool -> feat(mcp)
  • Fix changelog version parsing -> fix(changelog)
  • Update agent skill description -> docs(skills)
  • Adjust tsdown packaging configuration -> build(config)
  • Modify PR validation workflow -> ci

6. Summarize the core information of the PR

At minimum, organize:

  • Main result: what problem this branch solves or what capability it adds
  • Related Issues: when there is a reliable association, fill in the issue link or Closes #xxxx / Fixes #xxxx
  • Summary: summarize user impact, key approach, and important constraints
  • Testing: List only the commands actually executed and passed this time
  • Compatibility: Explain whether there are changes to CLI arguments, output format, configuration, MCP API, or packaging artifacts

7. Handle Testing

Choose verification based on the scope of changes:

  • All PRs:pnpm lint
  • Modify src/** or test/**：pnpm build and pnpm test
  • Involving CLI execution, MCP, setup, packaging, or cross-module integration: consider pnpm test:all
  • General supplementary checks:git diff --check

Write only commands that were actually executed and passed. If not executed, write Not run (reason); if failed, truthfully state the failed command, do not write it as passed.

8. Generate the PR title

Title requirements:

  • Generate according to the "Writing requirements -> Title" below
  • Cover the main goal of the entire branch
  • Do not copy a single commit message
  • type Must be consistent with the judgment in step 5

9. Produce the PR body draft according to the convention

When there is no repository template, use:

## Summary

- <主要结果或用户影响>
- <关键方案或重要约束>

## Testing

- `<实际通过的命令>`

When filling in, follow:

  • Summary usually uses 2 to 4 bullet points
  • Testing lists only actual results
  • When there is a reliable related issue, add Closes #xxxx、Fixes #xxxx or a link
  • When command output or interaction changes are involved, remind to add necessary terminal output, screenshots, or examples
  • When there are breaking changes, migration requirements, or public behavior changes, state them clearly
  • When information is not yet confirmed, mark it explicitly; do not pretend to be certain

10. First get user confirmation

The output must include at least:

  • Base branch
  • PR title
  • PR body
  • Tests actually executed and their results
  • Points that need user supplementation or confirmation

Clearly ask the user whether to:

  • Create the PR directly
  • Modify first and then create

Before explicit confirmation, do not execute gh pr create。

11. Create the PR

Execute only after explicit user confirmation.

Check again before execution:

git status --short
git branch -vv
git remote -v
gh repo view --json nameWithOwner,defaultBranchRef

Requirements:

  1. Confirm that the current branch's tracking remote and remote branch are correct
  2. Confirm that the PR's target repository is antdv-next/cli, do not rely on gh default inference
  3. If the tracking remote is missing, unclear, or not the expected fork, confirm with the user first; do not push by default
  4. Only push the current branch when the push target remote is clear and correct
  5. Use the confirmed title and body to execute gh pr create
  6. Use this only when the user explicitly requests a Draft PR: --draft
  7. When a PR with the same head/base already exists, return the existing PR; do not create a duplicate

If a push is needed, prefer using explicit remote and branch names:

git push -u <remote> HEAD

When the body is long, write it to a safe temporary file and use:

gh pr create \
  --repo antdv-next/cli \
  --base <base> \
  --head <owner>:<branch> \
  --title "<title>" \
  --body-file <body-file>

For same-repository branches, you can pass only <branch>; for fork branches, use <owner>:<branch>. After successful creation, return the PR link.

Writing requirements

Title

  • Must be in English
  • By default first determine type, then decide whether scope
  • Prefer to use type: subject or type(scope): subject
  • Prioritize writing the result, not the process
  • Avoid update, fix issues, misc changes such empty phrases
  • If the branch contains multiple types of small changes, distill a higher-level summary

Commonly used type Reference:

  • feat: New capability
  • fix: Bug fix
  • docs: Documentation or skill
  • refactor: Refactor
  • test: Test changes
  • build: Build or packaging
  • ci: CI or workflow
  • chore: Miscellaneous maintenance
  • perf: Performance optimization
  • release: Version release

scope Usage rules:

  • Add it only when the changes are concentrated within a single feature boundary, such as refactor(changelog): ...
  • Common scopes include cli、mcp、changelog、version、bug、setup、skills、package
  • If there is no obvious focused object, do not force in scope
  • Do not mechanically stuff directory names into scope

Summary

  • First write the problem this branch solves or the capability it adds
  • Then write the key approach and important constraints
  • If CLI parameters, output format, configuration, MCP API, or packaging artifact changes are involved, point out the externally perceivable differences
  • Do not write a file-by-file laundry list

Testing

  • List only the commands actually executed and passed this time
  • If not run, write Not run (reason)
  • If failed, explain truthfully; do not falsify passing results
  • Refer to pnpm lint、pnpm build、pnpm test、pnpm test:all and git diff --check

Reference

For more type judgment, baseline branch suggestions, confirmation wording, and title examples, see references/template-notes-and-examples.md。