@nt-ai-lab/opencode-skillz 0.3.10 → 0.3.11
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/commands/create-pr.md +201 -0
- package/package.json +1 -1
|
@@ -0,0 +1,201 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Create a draft pull request with semantic commits, source-of-truth references, and check monitoring
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Create a draft pull request for the current branch.
|
|
6
|
+
|
|
7
|
+
## Stop and ask the user if any of the following are true
|
|
8
|
+
|
|
9
|
+
- The source of truth is missing or unclear
|
|
10
|
+
- The ticket, plan, or design document cannot be found
|
|
11
|
+
- The acceptance criteria cannot be copied from the source material
|
|
12
|
+
- The branch contains unrelated changes that do not belong in the same pull request
|
|
13
|
+
- The base branch is unclear
|
|
14
|
+
- The change requires assumptions about user value, scope, or design intent
|
|
15
|
+
- An existing commit already on the branch does not comply with the required commit format and fixing it would require rewriting history
|
|
16
|
+
|
|
17
|
+
## Required context gathering
|
|
18
|
+
|
|
19
|
+
Before creating commits or a pull request:
|
|
20
|
+
|
|
21
|
+
1. Review the current git status
|
|
22
|
+
2. Review staged and unstaged diffs
|
|
23
|
+
3. Review the branch divergence from the base branch
|
|
24
|
+
4. Review every commit that will be included in the pull request
|
|
25
|
+
5. Review the source-of-truth materials for the change:
|
|
26
|
+
- ticket, such as JIRA
|
|
27
|
+
- plan
|
|
28
|
+
- design document
|
|
29
|
+
- any linked supporting document required to understand the change
|
|
30
|
+
|
|
31
|
+
Do not create the pull request until the change scope and source documents are understood.
|
|
32
|
+
|
|
33
|
+
## Local changes before pull request creation
|
|
34
|
+
|
|
35
|
+
The pull request must not be created with uncommitted local changes.
|
|
36
|
+
|
|
37
|
+
If local changes exist:
|
|
38
|
+
|
|
39
|
+
1. Group them into coherent commits
|
|
40
|
+
2. Create the required semantic commits
|
|
41
|
+
3. Verify the working tree is clean
|
|
42
|
+
|
|
43
|
+
Do not create the pull request until `git status` is clean.
|
|
44
|
+
|
|
45
|
+
## Commit rules
|
|
46
|
+
|
|
47
|
+
Every commit included in the pull request must use the full commit format defined below.
|
|
48
|
+
|
|
49
|
+
Use semantic commit types:
|
|
50
|
+
|
|
51
|
+
- `feat`
|
|
52
|
+
- `fix`
|
|
53
|
+
- `refactor`
|
|
54
|
+
- `perf`
|
|
55
|
+
- `docs`
|
|
56
|
+
- `test`
|
|
57
|
+
- `build`
|
|
58
|
+
- `ci`
|
|
59
|
+
- `release`
|
|
60
|
+
- `chore`
|
|
61
|
+
|
|
62
|
+
Rules:
|
|
63
|
+
|
|
64
|
+
- Never use `chore` when the change includes a version bump or release preparation
|
|
65
|
+
- Use `release` for version bumps or release preparation work
|
|
66
|
+
- Use the smallest accurate scope
|
|
67
|
+
- The commit subject must describe the user-facing change or the real engineering outcome
|
|
68
|
+
- The commit body must explain why the change exists, not list files changed
|
|
69
|
+
- The commit body must reference all relevant source-of-truth materials
|
|
70
|
+
- The acceptance criteria must be copied from the source material, not loosely rewritten
|
|
71
|
+
|
|
72
|
+
Commit subject format:
|
|
73
|
+
|
|
74
|
+
`<type>(<scope>): <short summary>`
|
|
75
|
+
|
|
76
|
+
Commit body format:
|
|
77
|
+
|
|
78
|
+
```text
|
|
79
|
+
<type>(<scope>): <short summary>
|
|
80
|
+
|
|
81
|
+
## Problem
|
|
82
|
+
|
|
83
|
+
Source of truth:
|
|
84
|
+
- Ticket: <ticket id or link>
|
|
85
|
+
- Plan: <link>
|
|
86
|
+
- Design: <link>
|
|
87
|
+
- Additional references: <link if relevant>
|
|
88
|
+
|
|
89
|
+
<Describe the actual user problem, business problem, or engineering risk being solved.
|
|
90
|
+
Explain the user value or operational value.>
|
|
91
|
+
|
|
92
|
+
## Solution
|
|
93
|
+
|
|
94
|
+
<Describe the chosen solution and why it solves the problem. Focus on outcome and approach, not file inventory.>
|
|
95
|
+
|
|
96
|
+
## Acceptance Criteria
|
|
97
|
+
|
|
98
|
+
Source: copied from <ticket or plan reference>
|
|
99
|
+
|
|
100
|
+
- <criterion 1>
|
|
101
|
+
- <criterion 2>
|
|
102
|
+
- <criterion 3>
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
## Pull request title
|
|
106
|
+
|
|
107
|
+
Use a clear title that matches the real change. Reuse the best semantic commit subject when that is the best title.
|
|
108
|
+
|
|
109
|
+
## Pull request description
|
|
110
|
+
|
|
111
|
+
The pull request description must contain these sections in this order:
|
|
112
|
+
|
|
113
|
+
- `## Problem`
|
|
114
|
+
- `## Solution`
|
|
115
|
+
- `## Acceptance Criteria`
|
|
116
|
+
- `## Architecture and software design`
|
|
117
|
+
|
|
118
|
+
### `## Problem`
|
|
119
|
+
|
|
120
|
+
Include:
|
|
121
|
+
|
|
122
|
+
- all relevant source-of-truth references
|
|
123
|
+
- the actual user problem, business problem, or operational problem
|
|
124
|
+
- the value of solving it
|
|
125
|
+
|
|
126
|
+
### `## Solution`
|
|
127
|
+
|
|
128
|
+
Include:
|
|
129
|
+
|
|
130
|
+
- the selected solution
|
|
131
|
+
- why this approach solves the problem
|
|
132
|
+
- important constraints or tradeoffs that matter to reviewers
|
|
133
|
+
|
|
134
|
+
### `## Acceptance Criteria`
|
|
135
|
+
|
|
136
|
+
Rules:
|
|
137
|
+
|
|
138
|
+
- copy the acceptance criteria from the source ticket or plan
|
|
139
|
+
- do not invent new criteria without stating that they are additional reviewer notes
|
|
140
|
+
- do not paraphrase loosely if exact wording exists in the source material
|
|
141
|
+
|
|
142
|
+
### `## Architecture and software design`
|
|
143
|
+
|
|
144
|
+
This section is free-form.
|
|
145
|
+
|
|
146
|
+
Include the architectural and design details that matter most for review, based on the current change. Use judgment instead of rigid structure.
|
|
147
|
+
|
|
148
|
+
Good topics to include when relevant:
|
|
149
|
+
|
|
150
|
+
- important new components that were added
|
|
151
|
+
- important existing components that were modified
|
|
152
|
+
- responsibility or boundary changes between components
|
|
153
|
+
- meaningful flow changes through the system
|
|
154
|
+
- changed persistence, messaging, API, or integration behavior
|
|
155
|
+
- new or changed dependencies
|
|
156
|
+
- contract changes between internal modules or external systems
|
|
157
|
+
- how the implemented design maps back to the approved design or plan
|
|
158
|
+
|
|
159
|
+
Avoid low-signal detail such as trivial renames, minor refactors, or file-by-file narration unless those details are central to the design review.
|
|
160
|
+
|
|
161
|
+
Write this section as a reviewer-focused design summary.
|
|
162
|
+
|
|
163
|
+
## GitHub command authentication
|
|
164
|
+
|
|
165
|
+
Before a GitHub command that needs authentication:
|
|
166
|
+
|
|
167
|
+
1. Run `gh auth token`
|
|
168
|
+
2. Use the returned token inline as `GITHUB_TOKEN=<token>` on the next GitHub command
|
|
169
|
+
|
|
170
|
+
## Execution steps
|
|
171
|
+
|
|
172
|
+
1. Confirm the branch is ready for a pull request
|
|
173
|
+
2. If local changes exist, stage the relevant changes and create the required semantic commits until the working tree is clean
|
|
174
|
+
3. Verify every commit included in the pull request complies with the required format
|
|
175
|
+
4. Push the branch if needed
|
|
176
|
+
5. Create a draft pull request with the required description format
|
|
177
|
+
6. Return the pull request URL
|
|
178
|
+
7. Wait for pull request checks to complete
|
|
179
|
+
8. Report the final status
|
|
180
|
+
|
|
181
|
+
Create the pull request as a draft.
|
|
182
|
+
|
|
183
|
+
## Check monitoring
|
|
184
|
+
|
|
185
|
+
After creating the draft pull request:
|
|
186
|
+
|
|
187
|
+
- wait for the pull request checks to finish
|
|
188
|
+
- do not report success before the checks complete
|
|
189
|
+
- if checks fail, report the failing checks and their status
|
|
190
|
+
- if checks pass, report that the draft pull request is ready for review
|
|
191
|
+
- do not merge unless the user explicitly asks for a merge
|
|
192
|
+
|
|
193
|
+
## Output
|
|
194
|
+
|
|
195
|
+
At the end, provide:
|
|
196
|
+
|
|
197
|
+
- the commit messages used for commits created during this command
|
|
198
|
+
- the pull request title
|
|
199
|
+
- the pull request URL
|
|
200
|
+
- the final check status
|
|
201
|
+
- any blockers that still require user action
|