You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- If validation fails, halt and instruct user: "Invalid fork configuration in `.fork-info.json`. Please run `/specify` again with complete fork information: upstream owner, upstream repo."
127
-
- Use `upstream_owner/upstream_repo` for all GitHub operations
128
-
-**If not exists** (local mode - default):
129
-
- Use the current repository (origin) for all GitHub operations
130
-
-**Determine PR operation**:
131
-
- If PR already exists for this branch, UPDATE it (description, status, labels)
132
-
- If no PR exists, CREATE a new one
133
-
-**Target branch**: The PR must be against the default branch
134
-
-**PR status**: The PR must not be draft, it should be ready for review
135
-
-**Retrieve the issue title**: Get the title from the linked GitHub issue (created in `/specify`) from the target repository
136
-
-**Use the same title for the PR**: Verify the PR title matches the issue title exactly. If they differ, update the PR title to match the issue.
137
-
- If unable to retrieve the issue title, determine the PR type and icon based on the changes:
138
-
| Type of change | Icon | Label |
139
-
|-|-|-|
140
-
| Docs | 📖 | Docs |
141
-
| Fix | 🪲 | Fix, Patch |
142
-
| Security fix | ⚠️ | Fix |
143
-
| Patch | 🩹 | Patch |
144
-
| Feature | 🚀 | Minor |
145
-
| Breaking change | 🌟 | Major |
146
-
- Fallback PR title format (if issue title unavailable): `<Icon> [Type of change]: <Short description>`
147
-
-**REPLACE the entire PR description with release notes**:
148
-
***IMPORTANT**: Clear the existing PR description completely (including task list) and replace it with the release notes
149
-
* This ensures the PR description is ready to be used as GitHub Release notes when merged to main
150
-
***Opening summary** (1-2 paragraphs):
151
-
- Start with what was accomplished in user-focused language
152
-
- Write in past tense: "Added...", "Improved...", "Fixed..."
153
-
- Focus on the "why" - what problem does this solve or what capability does it enable?
154
-
- Mention the user impact - who benefits and how?
155
-
- At the end, add: "Fixes #<issue-number>"
156
-
***What's Changed** section:
157
-
- 3-5 bullet points highlighting key changes from the user's perspective
158
-
- Focus on capabilities, not implementation details
159
-
- Example: "✨ Added support for custom templates" not "Created new Template class"
160
-
***Usage** section (if applicable):
161
-
- Brief example showing how to use the new functionality
162
-
- Keep it minimal - just enough to get started
163
-
- Use code blocks for commands or code snippets
164
-
***Breaking Changes** section (if applicable):
165
-
- Clear warning about what breaks
166
-
- Migration guidance for users
167
-
- What they need to change in their code
168
-
***Technical Notes** section (optional, for maintainers):
169
-
- Brief implementation notes if relevant for reviewers
170
-
- Dependencies added or updated
171
-
- Architecture decisions
172
-
***Tone and style**:
173
-
- Professional and concise
174
-
- Avoid jargon and internal terminology
175
-
- Write for the end user, not just developers
176
-
- This description will be used in release notes
177
-
-**Apply appropriate label(s)** based on the type of change
178
-
-**Link the PR** to the associated issue
179
-
-**Update `.fork-info.json`** (if it exists) with the latest PR number (if not already present)
180
-
**GitHub Integration**: If GitHub tools or integrations are available (such as GitHub MCP Server or other GitHub integrations), use them to update the PR description in the target repository. If not available, provide this fallback command:
- If validation fails, halt and instruct user: "Invalid fork configuration in `.fork-info.json`. Please run `/specify` again with complete fork information: upstream owner, upstream repo."
127
+
- Use `upstream_owner/upstream_repo` for all GitHub operations
128
+
-**If not exists** (local mode - default):
129
+
- Use the current repository (origin) for all GitHub operations
130
+
-**Determine PR operation**:
131
+
- If PR already exists for this branch, UPDATE it (description, status, labels)
132
+
- If no PR exists, CREATE a new one
133
+
-**Target branch**: The PR must be against the default branch
134
+
-**PR status**: The PR must not be draft, it should be ready for review
135
+
-**Retrieve the issue title**: Get the title from the linked GitHub issue (created in `/specify`) from the target repository
136
+
-**Use the same title for the PR**: Verify the PR title matches the issue title exactly. If they differ, update the PR title to match the issue.
137
+
- If unable to retrieve the issue title, determine the PR type and icon based on the changes:
138
+
139
+
| Type of change | Icon | Label |
140
+
|-|-|-|
141
+
| Docs | 📖 | Docs |
142
+
| Fix | 🪲 | Fix, Patch |
143
+
| Security fix | ⚠️ | Fix |
144
+
| Patch | 🩹 | Patch |
145
+
| Feature | 🚀 | Minor |
146
+
| Breaking change | 🌟 | Major |
147
+
148
+
- Fallback PR title format (if issue title unavailable): `<Icon> [Type of change]: <Short description>`
149
+
-**REPLACE the entire PR description with release notes**:
150
+
-**IMPORTANT**: Clear the existing PR description completely (including task list) and replace it with the release notes
151
+
- This ensures the PR description is ready to be used as GitHub Release notes when merged to main
152
+
-**Opening summary** (1-2 paragraphs):
153
+
- Start with what was accomplished in user-focused language
154
+
- Write in past tense: "Added...", "Improved...", "Fixed..."
155
+
- Focus on the "why" - what problem does this solve or what capability does it enable?
156
+
- Mention the user impact - who benefits and how?
157
+
- At the end, add: "Fixes #<issue-number>"
158
+
-**What's Changed** section:
159
+
- 3-5 bullet points highlighting key changes from the user's perspective
160
+
- Focus on capabilities, not implementation details
161
+
- Example: "✨ Added support for custom templates" not "Created new Template class"
162
+
-**Usage** section (if applicable):
163
+
- Brief example showing how to use the new functionality
164
+
- Keep it minimal - just enough to get started
165
+
- Use code blocks for commands or code snippets
166
+
-**Breaking Changes** section (if applicable):
167
+
- Clear warning about what breaks
168
+
- Migration guidance for users
169
+
- What they need to change in their code
170
+
-**Technical Notes** section (optional, for maintainers):
171
+
- Brief implementation notes if relevant for reviewers
172
+
- Dependencies added or updated
173
+
- Architecture decisions
174
+
-**Tone and style**:
175
+
- Professional and concise
176
+
- Avoid jargon and internal terminology
177
+
- Write for the end user, not just developers
178
+
- This description will be used in release notes
179
+
-**Apply appropriate label(s)** based on the type of change
180
+
-**Link the PR** to the associated issue
181
+
-**Update `.fork-info.json`** (if it exists) with the latest PR number (if not already present)
182
+
**GitHub Integration**: If GitHub tools or integrations are available (such as GitHub MCP Server or other GitHub integrations), use them to update the PR description in the target repository. If not available, provide this fallback command:
Note: This command assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running `/tasks` first to regenerate the task list.
0 commit comments