mirror of
https://github.com/CherryHQ/cherry-studio.git
synced 2026-07-05 21:50:46 +08:00
feat: Add agent skills (create-skill, gh-create-issue) and improve existing skill workflow (#13004)
<!-- Template from https://github.com/kubevirt/kubevirt/blob/main/.github/PULL_REQUEST_TEMPLATE.md?--> <!-- Thanks for sending a pull request! Here are some tips for you: 1. Consider creating this PR as draft: https://github.com/CherryHQ/cherry-studio/blob/main/CONTRIBUTING.md --> <!-- ⚠️ Important: Redux/IndexedDB Data-Changing Feature PRs Temporarily On Hold ⚠️ Please note: For our current development cycle, we are not accepting feature Pull Requests that introduce changes to Redux data models or IndexedDB schemas. While we value your contributions, PRs of this nature will be blocked without merge. We welcome all other contributions (bug fixes, perf enhancements, docs, etc.). Thank you! Once version 2.0.0 is released, we will resume reviewing feature PRs. --> ### What this PR does Before this PR: - No skill existed for creating new agent skills (multi-agent shared skills) - No skill existed for creating GitHub issues with templates - gh-create-pr skill had an incomplete workflow After this PR: - Added `create-skill` skill for scaffolding new skills following `.agents/skills/README.md` workflow - Added `gh-create-issue` skill for creating GitHub issues following repository's issue template format - Updated `prepare-release` workflow to use `gh-create-pr` skill instead of manual PR creation - Updated `gh-create-pr` skill with improved workflow: - Check and push branch to remote before creating PR - Determine base branch (support official repo and fork scenarios) - Create temp file first, then preview - Show temp file path in preview for user reference - Support skipping preview/confirmation when user explicitly indicates (e.g., automation workflows) ### Why we need it and why it was done in this way The following tradeoffs were made: - Created skills follow the existing skill structure and naming conventions - Skills support skipping preview/confirmation for automation workflows - Updated prepare-release workflow to use skills consistently - Temp file workflow allows users to edit content directly before confirmation The following alternatives were considered: - Manual PR/issue creation without skill automation Links to places where the discussion took place: <!-- optional: slack, other GH issue, mailinglist, ... --> N/A ### Breaking changes <!-- optional --> None ### Special notes for your reviewer <!-- optional --> N/A ### Checklist This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR. Approvers are expected to review this list. - [x] PR: The PR description is expressive enough and will help future contributors - [x] Code: [Write code that humans can understand](https://en.wikiquote.org/wiki/Martin_Fowler#code-for-humans) and [Keep it simple](https://en.wikipedia.org/wiki/KISS_principle) - [x] Refactor: You have [left the code cleaner than you found it (Boy Scout Rule)](https://learning.oreilly.com/library/view/97-things-every/9780596809515/ch08.html) - [x] Upgrade: Impact of this change on upgrade flows was considered and addressed if required - [x] Documentation: A [user-guide update](https://docs.cherry-ai.com) was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature. ### Release note <!-- Write your release note: 1. Enter your extended release note in the below block. If the PR requires additional action from users switching to the new release, include the string "action required". 2. If no release note is required, just write "NONE". --> ```release-note NONE ```
This commit is contained in:
Phantom
4
.agents/skills/.gitignore
vendored
4
.agents/skills/.gitignore
vendored
@@ -4,6 +4,10 @@
|
||||
!.gitignore
|
||||
!README*.md
|
||||
!public-skills.txt
|
||||
!create-skill/
|
||||
!create-skill/**
|
||||
!gh-create-issue/
|
||||
!gh-create-issue/**
|
||||
!gh-create-pr/
|
||||
!gh-create-pr/**
|
||||
!prepare-release/
|
||||
|
||||
111
.agents/skills/create-skill/SKILL.md
Normal file
111
.agents/skills/create-skill/SKILL.md
Normal file
@@ -0,0 +1,111 @@
|
||||
---
|
||||
name: create-skill
|
||||
description: Create a new skill in the current repository. Use when the user wants to create/add a new skill, or mentions creating a skill from scratch. This skill follows the workflow defined in .agents/skills/README.md and helps scaffold, validate, and sync new skills.
|
||||
---
|
||||
|
||||
# Create Skill
|
||||
|
||||
Create a new skill in `.agents/skills/<skill-name>/` following the workflow defined in `.agents/skills/README.md`.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Gather Intent
|
||||
|
||||
Before creating anything, ask the user:
|
||||
|
||||
1. **Skill name**: What should the skill be called? (lowercase, digits, hyphens only, e.g., `gh-create-pr`, `prepare-release`)
|
||||
2. **Description**: What should this skill do? Include specific trigger contexts (e.g., "Use when user asks to create PRs")
|
||||
3. **Is this a public skill?**: Should it be synced to `.claude/skills/` for shared use? (default: no, private only)
|
||||
4. **Test cases** (optional): Does the user want to set up evals for this skill?
|
||||
|
||||
If the user provides partial info (e.g., just a name), proceed with reasonable defaults and ask to confirm.
|
||||
|
||||
### Step 2: Read Guidelines
|
||||
|
||||
Always read `.agents/skills/README.md` before creating a new skill to ensure compliance with the current workflow.
|
||||
|
||||
### Step 3: Create Skill Structure
|
||||
|
||||
Create the following directory structure:
|
||||
|
||||
```
|
||||
.agents/skills/<skill-name>/
|
||||
└── SKILL.md
|
||||
```
|
||||
|
||||
**SKILL.md template:**
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: <skill-name>
|
||||
description: <description>
|
||||
---
|
||||
|
||||
# <Skill Name>
|
||||
|
||||
[Instructions for the skill]
|
||||
```
|
||||
|
||||
**Frontmatter fields:**
|
||||
- `name`: Skill identifier (lowercase, digits, hyphens)
|
||||
- `description`: When to trigger (what the skill does + specific contexts)
|
||||
|
||||
### Step 4: Sync (if public)
|
||||
|
||||
If the user wants a **public skill**, before validation:
|
||||
|
||||
1. Add the skill name to `.agents/skills/public-skills.txt` (one per line, no inline comments)
|
||||
2. Run sync:
|
||||
```bash
|
||||
pnpm skills:sync
|
||||
```
|
||||
|
||||
This copies the skill to `.claude/skills/<skill-name>/`.
|
||||
|
||||
**Note**: `pnpm skills:check` primarily validates public skills (those in `public-skills.txt`) and also verifies related governance files, so you must sync first before validating.
|
||||
|
||||
### Step 5: Validate
|
||||
|
||||
Run the validation command:
|
||||
|
||||
```bash
|
||||
pnpm skills:check
|
||||
```
|
||||
|
||||
If there are issues, fix them and re-run.
|
||||
|
||||
### Step 6: Summary
|
||||
|
||||
Present the user with:
|
||||
- Created files
|
||||
- Validation result
|
||||
- Next steps (how to use the skill)
|
||||
|
||||
## Naming Rules
|
||||
|
||||
- Use lowercase letters, digits, and hyphens only
|
||||
- Prefer short, action-oriented names (e.g., `gh-create-pr`)
|
||||
|
||||
## Public vs Private Skills
|
||||
|
||||
| Type | Location | Sync | Requires |
|
||||
|------|----------|------|----------|
|
||||
| Private | `.agents/skills/` | No | Just create the folder |
|
||||
| Public | Both | Yes | Add to `public-skills.txt` + run `pnpm skills:sync` |
|
||||
|
||||
## Commands Reference
|
||||
|
||||
```bash
|
||||
# Validate skill structure
|
||||
pnpm skills:check
|
||||
|
||||
# Sync public skills to Claude
|
||||
pnpm skills:sync
|
||||
```
|
||||
|
||||
## Constraints
|
||||
|
||||
- Never create skills outside `.agents/skills/<skill-name>/`
|
||||
- Always run `pnpm skills:check` before completing
|
||||
- Public skills require both adding to `public-skills.txt` AND running `pnpm skills:sync`
|
||||
- If the skill-creator skill is available, you may use it for advanced skill development (evals, iterations), but this skill handles the basic creation workflow.
|
||||
94
.agents/skills/gh-create-issue/SKILL.md
Normal file
94
.agents/skills/gh-create-issue/SKILL.md
Normal file
@@ -0,0 +1,94 @@
|
||||
---
|
||||
name: gh-create-issue
|
||||
description: Use when user wants to create a GitHub issue for the current repository. Must read and follow the repository's issue template format.
|
||||
---
|
||||
|
||||
# GitHub Create Issue
|
||||
|
||||
Use this skill when the user requests to create an issue. Must follow the repository's issue template format.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Determine Template Type
|
||||
|
||||
Analyze the user's request to determine the issue type:
|
||||
- If the user describes a problem, error, crash, or something not working -> Bug Report
|
||||
- If the user requests a new feature, enhancement, or additional support -> Feature Request
|
||||
- If the user is asking a question or needs help with something -> Questions & Discussion
|
||||
- Otherwise -> Others
|
||||
|
||||
**If unclear**, ask the user which template to use. Do not default to "Others" on your own.
|
||||
|
||||
### Step 2: Read the Selected Template
|
||||
|
||||
1. Read the corresponding template file from `.github/ISSUE_TEMPLATE/` directory.
|
||||
2. Identify required fields (`validations.required: true`), title prefix (`title`), and labels (`labels`, if present).
|
||||
|
||||
### Step 3: Collect Information
|
||||
|
||||
Based on the selected template, ask the user for required information only. Follow the template's required fields and option constraints (for example, Platform and Priority choices).
|
||||
|
||||
### Step 4: Build and Preview Issue Content
|
||||
|
||||
Create a temp file and write the issue content:
|
||||
- Use `issue_body_file="$(mktemp /tmp/gh-issue-body-XXXXXX).md"`
|
||||
- Use the exact title prefix from the selected template.
|
||||
- Fill content following the template body structure and section order.
|
||||
- Apply labels exactly as defined by the template.
|
||||
- Keep all labels when there are multiple labels.
|
||||
- If template has no labels, do not add custom labels.
|
||||
|
||||
Preview the temp file content. **Show the file path** (e.g., `/tmp/gh-issue-body-XXXXXX.md`) and ask for confirmation before creating. **Skip this step if the user explicitly indicates no preview/confirmation is needed** (for example, automation workflows).
|
||||
|
||||
### Step 5: Create Issue
|
||||
|
||||
Use `gh issue create` command to create the issue.
|
||||
|
||||
Use a unique temp file for the body:
|
||||
|
||||
```bash
|
||||
issue_body_file="$(mktemp /tmp/gh-issue-body-XXXXXX).md"
|
||||
cat > "$issue_body_file" <<'EOF'
|
||||
...issue body built from selected template...
|
||||
EOF
|
||||
```
|
||||
|
||||
Create the issue using values from the selected template:
|
||||
|
||||
```bash
|
||||
gh issue create --title "<title_with_template_prefix>" --body-file "$issue_body_file"
|
||||
```
|
||||
|
||||
If the selected template includes labels, append one `--label` per label:
|
||||
|
||||
```bash
|
||||
gh issue create --title "<title_with_template_prefix>" --body-file "$issue_body_file" --label "<label_1_from_template>" --label "<label_2_from_template>"
|
||||
```
|
||||
|
||||
If the selected template has no labels, do not pass `--label`.
|
||||
|
||||
You may use `--template` as a starting point (use the exact template name from the repository):
|
||||
|
||||
```bash
|
||||
gh issue create --template "<template_name>"
|
||||
```
|
||||
|
||||
Use the `--web` flag to open the creation page in browser when complex formatting is needed:
|
||||
|
||||
```bash
|
||||
gh issue create --web
|
||||
```
|
||||
|
||||
Clean up the temp file after creation:
|
||||
|
||||
```bash
|
||||
rm -f "$issue_body_file"
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
- Must read template files under `.github/ISSUE_TEMPLATE/` to ensure following the correct format.
|
||||
- Treat template files as the only source of truth. Do not hardcode title prefixes or labels in this skill.
|
||||
- Title must be clear and concise, avoid vague terms like "a suggestion" or "stuck".
|
||||
- Provide as much detail as possible to help developers understand and resolve the issue.
|
||||
- If user doesn't specify a template type, ask them to choose one first.
|
||||
@@ -9,14 +9,26 @@ description: Create or update GitHub pull requests using the repository-required
|
||||
|
||||
1. Read `.github/pull_request_template.md` before drafting the PR body.
|
||||
2. Collect PR context from the current branch (base/head, scope, linked issues, testing status, breaking changes, release note content).
|
||||
3. Draft the PR body using the template structure exactly:
|
||||
- Keep section order and headings.
|
||||
- Keep checkbox and code block formatting.
|
||||
- Fill every section; if not applicable, write `N/A` or `None`.
|
||||
4. Present the full Markdown PR body in chat for review before creating the PR.
|
||||
5. Ask for explicit confirmation to create the PR with that body.
|
||||
6. After confirmation, create the PR with `gh pr create --body-file` using a unique temp file path.
|
||||
7. Report the created PR URL and summarize title/base/head and any required follow-up.
|
||||
3. Check if the current branch has been pushed to remote. If not, push it first:
|
||||
- Default remote is `origin`, but ask the user if they want to use a different remote.
|
||||
```bash
|
||||
git push -u <remote> <head-branch>
|
||||
```
|
||||
4. Determine the base branch:
|
||||
- For official repo(CherryHQ/cherry-studio) as `origin`: default base is `main` from `origin`, but allow the user to explicitly indicate a base branch.
|
||||
- For fork repo as `origin`: check available remotes with `git remote -v`, default base may be `upstream/main` or another remote. Always assume that user wants to merge head to CherryHQ/cherry-studio/main, unless the user explicitly indicates a base branch.
|
||||
- Ask the user to confirm the base branch if it's not the default.
|
||||
5. Create a temp file and write the PR body:
|
||||
- Use `pr_body_file="$(mktemp /tmp/gh-pr-body-XXXXXX).md"`
|
||||
- Fill content using the template structure exactly (keep section order, headings, checkbox formatting).
|
||||
- If not applicable, write `N/A` or `None`.
|
||||
6. Preview the temp file content. **Show the file path** (e.g., `/tmp/gh-pr-body-XXXXXX.md`) and ask for explicit confirmation before creating. **Skip this step if the user explicitly indicates no preview/confirmation is needed** (for example, automation workflows).
|
||||
7. After confirmation, create the PR:
|
||||
```bash
|
||||
gh pr create --base <base> --head <head> --title "<title>" --body-file "$pr_body_file"
|
||||
```
|
||||
8. Clean up the temp file: `rm -f "$pr_body_file"`
|
||||
9. Report the created PR URL and summarize title/base/head and any required follow-up.
|
||||
|
||||
## Constraints
|
||||
|
||||
@@ -24,7 +36,7 @@ description: Create or update GitHub pull requests using the repository-required
|
||||
- Never rewrite the template format.
|
||||
- Keep content concise and specific to the current change set.
|
||||
- PR title and body must be written in English.
|
||||
- Never create the PR before showing the full final body to the user.
|
||||
- Never create the PR before showing the full final body to the user, unless they explicitly waive the preview or confirmation.
|
||||
- Never rely on command permission prompts as PR body preview.
|
||||
|
||||
## Command Pattern
|
||||
|
||||
@@ -2,3 +2,5 @@
|
||||
# One skill name per line.
|
||||
gh-create-pr
|
||||
prepare-release
|
||||
create-skill
|
||||
gh-create-issue
|
||||
|
||||
4
.claude/skills/.gitignore
vendored
4
.claude/skills/.gitignore
vendored
@@ -3,6 +3,10 @@
|
||||
*
|
||||
!.gitignore
|
||||
!README*.md
|
||||
!create-skill/
|
||||
!create-skill/**
|
||||
!gh-create-issue/
|
||||
!gh-create-issue/**
|
||||
!gh-create-pr/
|
||||
!gh-create-pr/**
|
||||
!prepare-release/
|
||||
|
||||
111
.claude/skills/create-skill/SKILL.md
Normal file
111
.claude/skills/create-skill/SKILL.md
Normal file
@@ -0,0 +1,111 @@
|
||||
---
|
||||
name: create-skill
|
||||
description: Create a new skill in the current repository. Use when the user wants to create/add a new skill, or mentions creating a skill from scratch. This skill follows the workflow defined in .agents/skills/README.md and helps scaffold, validate, and sync new skills.
|
||||
---
|
||||
|
||||
# Create Skill
|
||||
|
||||
Create a new skill in `.agents/skills/<skill-name>/` following the workflow defined in `.agents/skills/README.md`.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Gather Intent
|
||||
|
||||
Before creating anything, ask the user:
|
||||
|
||||
1. **Skill name**: What should the skill be called? (lowercase, digits, hyphens only, e.g., `gh-create-pr`, `prepare-release`)
|
||||
2. **Description**: What should this skill do? Include specific trigger contexts (e.g., "Use when user asks to create PRs")
|
||||
3. **Is this a public skill?**: Should it be synced to `.claude/skills/` for shared use? (default: no, private only)
|
||||
4. **Test cases** (optional): Does the user want to set up evals for this skill?
|
||||
|
||||
If the user provides partial info (e.g., just a name), proceed with reasonable defaults and ask to confirm.
|
||||
|
||||
### Step 2: Read Guidelines
|
||||
|
||||
Always read `.agents/skills/README.md` before creating a new skill to ensure compliance with the current workflow.
|
||||
|
||||
### Step 3: Create Skill Structure
|
||||
|
||||
Create the following directory structure:
|
||||
|
||||
```
|
||||
.agents/skills/<skill-name>/
|
||||
└── SKILL.md
|
||||
```
|
||||
|
||||
**SKILL.md template:**
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: <skill-name>
|
||||
description: <description>
|
||||
---
|
||||
|
||||
# <Skill Name>
|
||||
|
||||
[Instructions for the skill]
|
||||
```
|
||||
|
||||
**Frontmatter fields:**
|
||||
- `name`: Skill identifier (lowercase, digits, hyphens)
|
||||
- `description`: When to trigger (what the skill does + specific contexts)
|
||||
|
||||
### Step 4: Sync (if public)
|
||||
|
||||
If the user wants a **public skill**, before validation:
|
||||
|
||||
1. Add the skill name to `.agents/skills/public-skills.txt` (one per line, no inline comments)
|
||||
2. Run sync:
|
||||
```bash
|
||||
pnpm skills:sync
|
||||
```
|
||||
|
||||
This copies the skill to `.claude/skills/<skill-name>/`.
|
||||
|
||||
**Note**: `pnpm skills:check` primarily validates public skills (those in `public-skills.txt`) and also verifies related governance files, so you must sync first before validating.
|
||||
|
||||
### Step 5: Validate
|
||||
|
||||
Run the validation command:
|
||||
|
||||
```bash
|
||||
pnpm skills:check
|
||||
```
|
||||
|
||||
If there are issues, fix them and re-run.
|
||||
|
||||
### Step 6: Summary
|
||||
|
||||
Present the user with:
|
||||
- Created files
|
||||
- Validation result
|
||||
- Next steps (how to use the skill)
|
||||
|
||||
## Naming Rules
|
||||
|
||||
- Use lowercase letters, digits, and hyphens only
|
||||
- Prefer short, action-oriented names (e.g., `gh-create-pr`)
|
||||
|
||||
## Public vs Private Skills
|
||||
|
||||
| Type | Location | Sync | Requires |
|
||||
|------|----------|------|----------|
|
||||
| Private | `.agents/skills/` | No | Just create the folder |
|
||||
| Public | Both | Yes | Add to `public-skills.txt` + run `pnpm skills:sync` |
|
||||
|
||||
## Commands Reference
|
||||
|
||||
```bash
|
||||
# Validate skill structure
|
||||
pnpm skills:check
|
||||
|
||||
# Sync public skills to Claude
|
||||
pnpm skills:sync
|
||||
```
|
||||
|
||||
## Constraints
|
||||
|
||||
- Never create skills outside `.agents/skills/<skill-name>/`
|
||||
- Always run `pnpm skills:check` before completing
|
||||
- Public skills require both adding to `public-skills.txt` AND running `pnpm skills:sync`
|
||||
- If the skill-creator skill is available, you may use it for advanced skill development (evals, iterations), but this skill handles the basic creation workflow.
|
||||
94
.claude/skills/gh-create-issue/SKILL.md
Normal file
94
.claude/skills/gh-create-issue/SKILL.md
Normal file
@@ -0,0 +1,94 @@
|
||||
---
|
||||
name: gh-create-issue
|
||||
description: Use when user wants to create a GitHub issue for the current repository. Must read and follow the repository's issue template format.
|
||||
---
|
||||
|
||||
# GitHub Create Issue
|
||||
|
||||
Use this skill when the user requests to create an issue. Must follow the repository's issue template format.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Determine Template Type
|
||||
|
||||
Analyze the user's request to determine the issue type:
|
||||
- If the user describes a problem, error, crash, or something not working -> Bug Report
|
||||
- If the user requests a new feature, enhancement, or additional support -> Feature Request
|
||||
- If the user is asking a question or needs help with something -> Questions & Discussion
|
||||
- Otherwise -> Others
|
||||
|
||||
**If unclear**, ask the user which template to use. Do not default to "Others" on your own.
|
||||
|
||||
### Step 2: Read the Selected Template
|
||||
|
||||
1. Read the corresponding template file from `.github/ISSUE_TEMPLATE/` directory.
|
||||
2. Identify required fields (`validations.required: true`), title prefix (`title`), and labels (`labels`, if present).
|
||||
|
||||
### Step 3: Collect Information
|
||||
|
||||
Based on the selected template, ask the user for required information only. Follow the template's required fields and option constraints (for example, Platform and Priority choices).
|
||||
|
||||
### Step 4: Build and Preview Issue Content
|
||||
|
||||
Create a temp file and write the issue content:
|
||||
- Use `issue_body_file="$(mktemp /tmp/gh-issue-body-XXXXXX).md"`
|
||||
- Use the exact title prefix from the selected template.
|
||||
- Fill content following the template body structure and section order.
|
||||
- Apply labels exactly as defined by the template.
|
||||
- Keep all labels when there are multiple labels.
|
||||
- If template has no labels, do not add custom labels.
|
||||
|
||||
Preview the temp file content. **Show the file path** (e.g., `/tmp/gh-issue-body-XXXXXX.md`) and ask for confirmation before creating. **Skip this step if the user explicitly indicates no preview/confirmation is needed** (for example, automation workflows).
|
||||
|
||||
### Step 5: Create Issue
|
||||
|
||||
Use `gh issue create` command to create the issue.
|
||||
|
||||
Use a unique temp file for the body:
|
||||
|
||||
```bash
|
||||
issue_body_file="$(mktemp /tmp/gh-issue-body-XXXXXX).md"
|
||||
cat > "$issue_body_file" <<'EOF'
|
||||
...issue body built from selected template...
|
||||
EOF
|
||||
```
|
||||
|
||||
Create the issue using values from the selected template:
|
||||
|
||||
```bash
|
||||
gh issue create --title "<title_with_template_prefix>" --body-file "$issue_body_file"
|
||||
```
|
||||
|
||||
If the selected template includes labels, append one `--label` per label:
|
||||
|
||||
```bash
|
||||
gh issue create --title "<title_with_template_prefix>" --body-file "$issue_body_file" --label "<label_1_from_template>" --label "<label_2_from_template>"
|
||||
```
|
||||
|
||||
If the selected template has no labels, do not pass `--label`.
|
||||
|
||||
You may use `--template` as a starting point (use the exact template name from the repository):
|
||||
|
||||
```bash
|
||||
gh issue create --template "<template_name>"
|
||||
```
|
||||
|
||||
Use the `--web` flag to open the creation page in browser when complex formatting is needed:
|
||||
|
||||
```bash
|
||||
gh issue create --web
|
||||
```
|
||||
|
||||
Clean up the temp file after creation:
|
||||
|
||||
```bash
|
||||
rm -f "$issue_body_file"
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
- Must read template files under `.github/ISSUE_TEMPLATE/` to ensure following the correct format.
|
||||
- Treat template files as the only source of truth. Do not hardcode title prefixes or labels in this skill.
|
||||
- Title must be clear and concise, avoid vague terms like "a suggestion" or "stuck".
|
||||
- Provide as much detail as possible to help developers understand and resolve the issue.
|
||||
- If user doesn't specify a template type, ask them to choose one first.
|
||||
@@ -9,14 +9,26 @@ description: Create or update GitHub pull requests using the repository-required
|
||||
|
||||
1. Read `.github/pull_request_template.md` before drafting the PR body.
|
||||
2. Collect PR context from the current branch (base/head, scope, linked issues, testing status, breaking changes, release note content).
|
||||
3. Draft the PR body using the template structure exactly:
|
||||
- Keep section order and headings.
|
||||
- Keep checkbox and code block formatting.
|
||||
- Fill every section; if not applicable, write `N/A` or `None`.
|
||||
4. Present the full Markdown PR body in chat for review before creating the PR.
|
||||
5. Ask for explicit confirmation to create the PR with that body.
|
||||
6. After confirmation, create the PR with `gh pr create --body-file` using a unique temp file path.
|
||||
7. Report the created PR URL and summarize title/base/head and any required follow-up.
|
||||
3. Check if the current branch has been pushed to remote. If not, push it first:
|
||||
- Default remote is `origin`, but ask the user if they want to use a different remote.
|
||||
```bash
|
||||
git push -u <remote> <head-branch>
|
||||
```
|
||||
4. Determine the base branch:
|
||||
- For official repo(CherryHQ/cherry-studio) as `origin`: default base is `main` from `origin`, but allow the user to explicitly indicate a base branch.
|
||||
- For fork repo as `origin`: check available remotes with `git remote -v`, default base may be `upstream/main` or another remote. Always assume that user wants to merge head to CherryHQ/cherry-studio/main, unless the user explicitly indicates a base branch.
|
||||
- Ask the user to confirm the base branch if it's not the default.
|
||||
5. Create a temp file and write the PR body:
|
||||
- Use `pr_body_file="$(mktemp /tmp/gh-pr-body-XXXXXX).md"`
|
||||
- Fill content using the template structure exactly (keep section order, headings, checkbox formatting).
|
||||
- If not applicable, write `N/A` or `None`.
|
||||
6. Preview the temp file content. **Show the file path** (e.g., `/tmp/gh-pr-body-XXXXXX.md`) and ask for explicit confirmation before creating. **Skip this step if the user explicitly indicates no preview/confirmation is needed** (for example, automation workflows).
|
||||
7. After confirmation, create the PR:
|
||||
```bash
|
||||
gh pr create --base <base> --head <head> --title "<title>" --body-file "$pr_body_file"
|
||||
```
|
||||
8. Clean up the temp file: `rm -f "$pr_body_file"`
|
||||
9. Report the created PR URL and summarize title/base/head and any required follow-up.
|
||||
|
||||
## Constraints
|
||||
|
||||
@@ -24,7 +36,7 @@ description: Create or update GitHub pull requests using the repository-required
|
||||
- Never rewrite the template format.
|
||||
- Keep content concise and specific to the current change set.
|
||||
- PR title and body must be written in English.
|
||||
- Never create the PR before showing the full final body to the user.
|
||||
- Never create the PR before showing the full final body to the user, unless they explicitly waive the preview or confirmation.
|
||||
- Never rely on command permission prompts as PR body preview.
|
||||
|
||||
## Command Pattern
|
||||
|
||||
2
.github/workflows/prepare-release.yml
vendored
2
.github/workflows/prepare-release.yml
vendored
@@ -39,7 +39,7 @@ jobs:
|
||||
|
||||
Read the skill instructions from .agents/skills/prepare-release/SKILL.md and follow them exactly.
|
||||
|
||||
Since this is running in CI (non-interactive), skip all interactive confirmation steps. For PR creation, do NOT use the gh-create-pr skill; instead read .github/pull_request_template.md, fill every section, and run gh pr create --body-file directly.
|
||||
Since this is running in CI (non-interactive), skip all interactive confirmation steps.
|
||||
|
||||
Configure git before making commits:
|
||||
git config user.name "github-actions[bot]"
|
||||
|
||||
@@ -18,6 +18,11 @@ This file provides guidance to AI coding assistants when working with code in th
|
||||
When creating a Pull Request, you MUST use the `gh-create-pr` skill.
|
||||
If the skill is unavailable, directly read `.agents/skills/gh-create-pr/SKILL.md` and follow it manually.
|
||||
|
||||
## Issue Workflow
|
||||
|
||||
When creating an Issue, you MUST use the `gh-create-issue` skill.
|
||||
If the skill is unavailable, directly read `.agents/skills/gh-create-issue/SKILL.md` and follow it manually.
|
||||
|
||||
## Development Commands
|
||||
|
||||
- **Install**: `pnpm install` - Install all project dependencies
|
||||
|
||||
Reference in New Issue
Block a user