mirror of
https://github.com/QwenLM/qwen-code.git
synced 2026-04-28 03:30:40 +00:00
feat(commands): add custom QC commands for GitHub workflows
Add four new custom commands for Qwen Code CLI: - code-review: Review pull requests with detailed analysis - commit: Generate commit messages and push changes - create-issue: Draft and submit GitHub issues - create-pr: Create well-structured pull requests These commands provide structured workflows for common GitHub operations. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
This commit is contained in:
tanzhenxin
parent
991ae9febc
commit
d6c4350f71
4 changed files with 171 additions and 0 deletions
25
.qwen/commands/qc/code-review.md
Normal file
25
.qwen/commands/qc/code-review.md
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
---
|
||||
description: Code review a pull request
|
||||
---
|
||||
|
||||
You are an expert code reviewer. Follow these steps:
|
||||
|
||||
1. If no PR number is provided in the args, use Bash(\"gh pr list\") to show open PRs
|
||||
2. If a PR number is provided, use Bash(\"gh pr view <number>\") to get PR details
|
||||
3. Use Bash(\"gh pr diff <number>\") to get the diff
|
||||
4. Analyze the changes and provide a thorough code review that includes:
|
||||
- Overview of what the PR does
|
||||
- Analysis of code quality and style
|
||||
- Specific suggestions for improvements
|
||||
- Any potential issues or risks
|
||||
|
||||
Keep your review concise but thorough. Focus on:
|
||||
- Code correctness
|
||||
- Following project conventions
|
||||
- Performance implications
|
||||
- Test coverage
|
||||
- Security considerations
|
||||
|
||||
Format your review with clear sections and bullet points.
|
||||
|
||||
PR number: {{args}}
|
||||
70
.qwen/commands/qc/commit.md
Normal file
70
.qwen/commands/qc/commit.md
Normal file
|
|
@ -0,0 +1,70 @@
|
|||
---
|
||||
description: Commit staged changes with an AI-generated commit message and push
|
||||
---
|
||||
|
||||
# Commit and Push
|
||||
|
||||
## Overview
|
||||
Generate a clear, concise commit message based on staged changes, confirm with the user, then commit and push.
|
||||
|
||||
## Steps
|
||||
|
||||
### 1. Check repository status
|
||||
- Run `git status` to check:
|
||||
- Are there any staged changes?
|
||||
- Are there unstaged changes?
|
||||
- What is the current branch?
|
||||
|
||||
### 2. Handle unstaged changes
|
||||
- If there are unstaged changes, notify the user and list them
|
||||
- Do NOT add or commit unstaged changes
|
||||
- Proceed only with staged changes
|
||||
|
||||
### 3. Review staged changes
|
||||
- Run `git diff --staged` to see all staged changes
|
||||
- Analyze the changes in depth to understand:
|
||||
- What files were modified/added/deleted
|
||||
- The nature of the changes (feature, fix, refactor, docs, etc.)
|
||||
- The scope and impact of the changes
|
||||
|
||||
### 4. Handle branch logic
|
||||
- Get current branch name with `git branch --show-current`
|
||||
- **If current branch is `main` or `master`:**
|
||||
- Generate a proper branch name based on the changes
|
||||
- Create and switch to the new branch: `git checkout -b <branch-name>`
|
||||
- **If current branch is NOT main/master:**
|
||||
- Check if branch name matches the staged changes
|
||||
- If branch name doesn't match changes, ask user:
|
||||
- "Current branch `<branch>` doesn't seem to match these changes."
|
||||
- "Options: (1) Create and switch to a new branch, (2) Commit directly on current branch"
|
||||
- Wait for user decision
|
||||
|
||||
### 5. Generate commit message
|
||||
- Types: feat, fix, docs, style, refactor, test, chore
|
||||
- Guidelines:
|
||||
- Be clear and concise
|
||||
- Reference issues if mentioned in changes
|
||||
- Include scope in parentheses when applicable (e.g., `fix(insight):`, `feat(auth):`)
|
||||
- Add bullet points for detailed changes if it addes more value, otherwise do not use bullets
|
||||
- Include a footer explaining the purpose/impact of the changes
|
||||
|
||||
**Format:**
|
||||
```
|
||||
<type>(<scope>): <short description>
|
||||
- <detail point 1> (optional)
|
||||
- <detail point 2> (optional)
|
||||
- ...
|
||||
|
||||
This <explains the why/impact of the changes>.
|
||||
```
|
||||
|
||||
### 6. Present the result and confirm with user
|
||||
- Present the generated commit message
|
||||
- Show which branch will be used
|
||||
- Ask for confirmation: "Proceed with commit and push?"
|
||||
- Wait for user approval
|
||||
|
||||
### 7. Commit and push
|
||||
- After user confirms:
|
||||
- `git commit -m "<commit-message>"`
|
||||
- `git push -u origin <branch-name>` (use `-u` for new branches)
|
||||
42
.qwen/commands/qc/create-issue.md
Normal file
42
.qwen/commands/qc/create-issue.md
Normal file
|
|
@ -0,0 +1,42 @@
|
|||
---
|
||||
description: Draft and submit a GitHub issue based on a user-provided idea
|
||||
---
|
||||
|
||||
# Create Issue
|
||||
|
||||
## Overview
|
||||
Take the user's idea or bug description, investigate the codebase to understand the full context, draft a GitHub issue for review, and submit it once approved.
|
||||
|
||||
## Input
|
||||
The user provides a brief description of a feature request or bug report: {{args}}
|
||||
|
||||
## Steps
|
||||
|
||||
1. **Understand the request**
|
||||
- Read the user's description carefully
|
||||
- Determine whether this is a feature request or a bug report
|
||||
|
||||
2. **Investigate the codebase**
|
||||
- Search for relevant code, files, and existing behavior related to the request
|
||||
- Build a thorough understanding of how the current system works
|
||||
- Identify any related issues or prior art if mentioned
|
||||
|
||||
3. **Draft the issue**
|
||||
- Write a markdown file for the user to review
|
||||
- Use the appropriate template:
|
||||
- Feature request: follow @.github/ISSUE_TEMPLATE/feature_request.yml
|
||||
- Bug report: follow @.github/ISSUE_TEMPLATE/bug_report.yml
|
||||
- Write from the user's perspective, not as an implementation spec
|
||||
- Keep the language clear and concise, AVOID internal implementation details
|
||||
|
||||
4. **Review with user**
|
||||
- Present the draft file to the user
|
||||
- Iterate on feedback until the user is satisfied
|
||||
- Do NOT submit until the user explicitly asks to
|
||||
|
||||
5. **Submit the issue**
|
||||
- When the user confirms, create the issue using `gh issue create`
|
||||
- Apply the appropriate labels:
|
||||
- Feature request: `type/feature-request`, `status/needs-triage`
|
||||
- Bug report: `type/bug`, `status/needs-triage`
|
||||
- Report back the issue URL
|
||||
34
.qwen/commands/qc/create-pr.md
Normal file
34
.qwen/commands/qc/create-pr.md
Normal file
|
|
@ -0,0 +1,34 @@
|
|||
---
|
||||
description: Create a pull request based on staged code changes
|
||||
---
|
||||
|
||||
# Create PR
|
||||
|
||||
## Overview
|
||||
Create a well-structured pull request with proper description and title.
|
||||
|
||||
## Steps
|
||||
1. **Review staged changes**
|
||||
- Review all staged changes to understand what has been done
|
||||
- Do not touch unstaged changes
|
||||
|
||||
2. **Prepare branch**
|
||||
- Create a new branch with proper name if current branch is main
|
||||
- Ensure all changes are committed
|
||||
- Push branch to remote
|
||||
|
||||
3. **Write PR description**
|
||||
- Use PR Template below
|
||||
- Summarize changes clearly
|
||||
- Include context and motivation
|
||||
- List any breaking changes
|
||||
- Link related issues if provided, or use "No linked issues"
|
||||
- Add this line at the end of PR body: "🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)", with a line separator
|
||||
|
||||
4. **Set up PR**
|
||||
- Create PR title and body
|
||||
- Submit PR with gh command
|
||||
|
||||
## PR Template
|
||||
|
||||
@{.github/pull_request_template.md}
|
||||
Loading…
Add table
Add a link
Reference in a new issue