|
| 1 | +--- |
| 2 | +description: Create a pull request with a release note style description, appropriate title, and labels based on the change type. |
| 3 | +--- |
| 4 | + |
| 5 | +# PR |
| 6 | + |
| 7 | +The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty). |
| 8 | + |
| 9 | +## User input |
| 10 | + |
| 11 | +$ARGUMENTS |
| 12 | + |
| 13 | +**Purpose**: Create or update a pull request with a release note style description and title, automatically applying the appropriate labels based on the change type specified. |
| 14 | + |
| 15 | +## Supported Change Types |
| 16 | + |
| 17 | +| Type | Icon | Labels | Description | |
| 18 | +|------|------|--------|-------------| |
| 19 | +| Major | 🌟 | `Major` | Breaking changes that affect compatibility | |
| 20 | +| Minor | 🚀 | `Minor` | New features or enhancements | |
| 21 | +| Patch | 🩹 | `Patch` | Small fixes or improvements | |
| 22 | +| Fix | 🪲 | `Fix`, `Patch` | Bugfixes | |
| 23 | +| Docs | 📖 | `Docs` | Documentation changes only | |
| 24 | + |
| 25 | +## Execution Steps |
| 26 | + |
| 27 | +1. **Detect repository mode**: |
| 28 | + - Run `git remote -v` to check configured remotes. |
| 29 | + - **If `upstream` remote exists**: Fork mode |
| 30 | + - Use `upstream` owner/repo for all GitHub operations (PRs, Issues, labels) |
| 31 | + - Use `origin` for all git operations (push, fetch) |
| 32 | + - **If only `origin` remote exists**: Origin mode |
| 33 | + - Use `origin` owner/repo for all operations (both git push and GitHub operations) |
| 34 | + - Parse the URLs to extract owner and repo name: `https://github.com/<owner>/<repository>.git`. |
| 35 | + - If in doubt, ask the user to clarify which repository to target. |
| 36 | + |
| 37 | +2. **Determine the change type**: |
| 38 | + 1. Parse the user input to identify the change type (Major, Minor, Patch, Fix, or Docs) |
| 39 | + 2. If nothing is provided, **analyze ALL changes in the branch** to infer the type: |
| 40 | + - Run `git diff origin/main...HEAD --name-only` to get all changed files in the branch |
| 41 | + - Read the diff content using `git diff origin/main...HEAD` to understand the nature of changes |
| 42 | + - Categorize based on ALL changes combined, not just recent commits: |
| 43 | + * **Docs**: ONLY if ALL changes are to documentation files (*.md, docs/, .github/prompts/, etc.) with no code/functionality changes |
| 44 | + * **Fix**: If changes specifically fix bugs without adding new features |
| 45 | + * **Patch**: Small fixes or improvements that do not add new features |
| 46 | + * **Minor**: New features or enhancements that do not break existing functionality |
| 47 | + * **Major**: Changes that break backward compatibility (e.g., removing public APIs, changing method signatures) |
| 48 | + - **Important**: If the branch contains BOTH code changes AND documentation changes, classify based on the code changes, not the documentation |
| 49 | + - **Important**: Check the entire branch diff, not just uncommitted changes or the last commit |
| 50 | + |
| 51 | +3. **Stage, commit, and push all changes**: |
| 52 | + - **ALWAYS run these commands before creating/updating the PR**: |
| 53 | + 1. `git add .` - Stage all changes (tracked and untracked files) |
| 54 | + 2. Check if there are staged changes with `git diff --cached --quiet` |
| 55 | + 3. If there are staged changes, commit with: `git commit -m "Update for PR"` |
| 56 | + 4. `git push origin <branch-name>` - Push to origin remote (even in fork mode) |
| 57 | + - This ensures the PR reflects all local changes |
| 58 | + - Get the current branch name for the push command |
| 59 | + |
| 60 | +4. **Retrieve linked issue information** (if available): |
| 61 | + - Attempt to find the GitHub issue number associated with the current branch |
| 62 | + - If found, retrieve the issue title from the **target repository** (upstream in fork mode, origin otherwise) |
| 63 | + - Use the issue title as the PR title (with appropriate icon prefix) |
| 64 | + - If no issue is found, ask the user to provide one of the following: |
| 65 | + - the number of the issue to link to the PR |
| 66 | + - if a new issue should be raised for this PR |
| 67 | + - Stop if the user cannot provide either of these. |
| 68 | + |
| 69 | +5. **Generate PR title**: |
| 70 | + - **If issue title retrieved**: Use format `<Icon> <Issue Title>` |
| 71 | + - Examples: |
| 72 | + - `🚀 [Feature]: Add support for custom module templates` |
| 73 | + - `🪲 [Fix]: Resolve null reference in parameter validation` |
| 74 | + - `📖 [Docs]: Update installation guide with prerequisites` |
| 75 | + |
| 76 | +6. **Generate release note style description**: |
| 77 | + - The PR description will be used automatically as the release note in an automated release |
| 78 | + - Use this exact structure (ordered list format): |
| 79 | + |
| 80 | + **1. Leading Paragraph (Summary)** |
| 81 | + - Write a concise paragraph describing **what changes for the user** of the solution |
| 82 | + - Focus on user-facing value and impact, not implementation details |
| 83 | + - Use present tense and active voice |
| 84 | + - Audience: Users of the solution (not developers) |
| 85 | + |
| 86 | + **2. Issue Links (Unordered List)** |
| 87 | + - Add one or more issue links as unordered list items |
| 88 | + - Format: `- Fixes #<issue-number>` |
| 89 | + - If multiple issues: `- Fixes #<issue-1>`, `- Fixes #<issue-2>` |
| 90 | + |
| 91 | + **3. Details (Sections with Headers)** |
| 92 | + - For each significant change, add a header (e.g., `## Configuration`, `## Breaking Changes`, `## Usage`) |
| 93 | + - Under each header, provide: |
| 94 | + * Details of what changed |
| 95 | + * What the user needs to change or do differently (if anything) |
| 96 | + * Examples or code snippets if helpful for understanding |
| 97 | + - Keep sections concise and user-focused |
| 98 | + - Avoid implementation details unless necessary for user understanding |
| 99 | + |
| 100 | + **Example Structure:** |
| 101 | + ````markdown |
| 102 | + The workflow now provides fine-grained control over repository linting behavior through simple configuration options. You can disable the linter entirely or customize which validations run by configuring super-linter environment variables directly in your settings file. |
| 103 | + |
| 104 | + - Fixes #218 |
| 105 | + |
| 106 | + ## Configure settings for repository linting |
| 107 | + |
| 108 | + You can now control the linter behavior via the `Linter` section in your `.settings.yml` file. This allows you to skip linting altogether or customize which validations are performed. |
| 109 | + |
| 110 | + Added `Linter.Skip` and `Linter.env` settings to control linter behavior. You can now disable the linter entirely or customize which validations run. |
| 111 | + |
| 112 | + To disable the linter: |
| 113 | + ```yaml |
| 114 | + Linter: |
| 115 | + Skip: true |
| 116 | + ``` |
| 117 | + |
| 118 | + To customize validations: |
| 119 | + ```yaml |
| 120 | + Linter: |
| 121 | + env: |
| 122 | + VALIDATE_JSCPD: false |
| 123 | + ``` |
| 124 | + |
| 125 | + ```` |
| 126 | + |
| 127 | +7. **Create or update the pull request**: |
| 128 | + - **Check if PR already exists** for this branch in the **target repository** (upstream in fork mode, origin otherwise) |
| 129 | + - **If PR exists**: Update the title, description, and labels |
| 130 | + - **If PR does not exist**: Create a new PR from your fork's branch to the target repository's default branch |
| 131 | + - In fork mode, the PR will be from `<fork-owner>:<branch>` to `<upstream-owner>:<default-branch>` |
| 132 | + - Set PR to target the default branch (main/master) of the target repository |
| 133 | + - Open as a **draft PR** (or keep as draft if updating) |
| 134 | + - **Use GitHub MCP tools** to perform these operations in the **target repository**: |
| 135 | + - Create PR (if not exists) - owner/repo should be target repository, use `mcp_github_github_create_pull_request` |
| 136 | + - Update PR (if exists) - owner/repo should be target repository, use `mcp_github_github_update_pull_request` |
| 137 | + - Add labels to PR - owner/repo should be target repository, use `mcp_github_github_add_labels_to_issue` (PRs are issues in GitHub API) |
| 138 | + |
| 139 | +8. **Apply labels to the PR**: |
| 140 | + - Add the **change type label** based on the type specified (Major, Minor, Patch, Fix, or Docs) |
| 141 | + - For Fix type, add both `Fix` and `Patch` labels |
| 142 | + - If currently in a feature workflow phase (e.g., Planning, Implementation), also apply that phase label |
| 143 | + - Use GitHub MCP to add labels in the **target repository** (upstream in fork mode, origin otherwise) |
| 144 | + |
| 145 | +9. **Confirm completion**: |
| 146 | + - Display the PR URL to the user |
| 147 | + - Summarize the PR title, type, and labels applied |
| 148 | + - If in fork mode, remind the user that the PR was created in the upstream repository |
| 149 | + |
| 150 | +## Example usage |
| 151 | + |
| 152 | +- `/PR` - Create a PR for the current changes |
| 153 | +- `/PR Minor` - Create a PR for a new feature |
| 154 | +- `/PR Fix` - Create a PR for a bugfix |
| 155 | +- `/PR Docs` - Create a PR for documentation changes |
| 156 | +- `/PR Major` - Create a PR for breaking changes |
| 157 | +- `/PR Patch` - Create a PR for small improvements |
| 158 | + |
| 159 | +## Notes |
| 160 | + |
| 161 | +- **This command always stages all changes (`git add .`), commits if needed, and pushes to origin before creating/updating the PR** |
| 162 | +- Changes are always pushed to `origin` remote |
| 163 | +- In fork mode, PRs and Issue operations are performed on the `upstream` repository |
| 164 | +- In origin mode, all operations use the `origin` repository |
| 165 | +- The PR is always created as a draft to allow for review before marking as ready |
| 166 | +- Labels can be manually adjusted after PR creation if needed |
| 167 | +- **The PR description uses a structured format designed for automated release notes**: |
| 168 | + 1. Leading paragraph (user-focused summary) |
| 169 | + 2. Issue links (unordered list) |
| 170 | + 3. Details (sections with headers explaining changes and user actions needed) |
0 commit comments