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
Copy file name to clipboardExpand all lines: .claude/skills/create-java-pr/SKILL.md
+58-6Lines changed: 58 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,24 @@
1
1
---
2
2
name: create-java-pr
3
-
description: Create a pull request in sentry-java. Use when asked to "create pr", "prepare pr", "prep pr", "open pr", "ready for pr", "prepare for review", "finalize changes". Handles branch creation, code formatting, API dump, committing, pushing, PR creation, and changelog.
3
+
description: Create a pull request in sentry-java. Use when asked to "create pr", "prepare pr", "prep pr", "open pr", "ready for pr", "prepare for review", "finalize changes". Handles branch creation, code formatting, API dump, committing, pushing, PR creation, changelog, and stacked PRs.
4
4
---
5
5
6
6
# Create Pull Request (sentry-java)
7
7
8
8
Prepare local changes and create a pull request for the sentry-java repo.
9
9
10
+
**Required reading:** Before proceeding, read `.cursor/rules/pr.mdc` for the full PR and stacked PR workflow details. That file is the source of truth for PR conventions, stack comment format, branch naming, and merge strategy.
11
+
12
+
## Step 0: Determine PR Type
13
+
14
+
Ask the user (or infer from context) whether this is:
15
+
16
+
-**Standalone PR** — a regular PR targeting `main`. Follow Steps 1–6 as written.
17
+
-**First PR of a new stack** — ask for a topic name (e.g. "Global Attributes"). Create a collection branch from `main`, then branch the first PR off it. The first PR targets the collection branch.
18
+
-**Next PR in an existing stack** — identify the previous stack branch and topic. This PR targets the previous stack branch.
19
+
20
+
If the user mentions "stack", "stacked PR", or provides a topic name with a number (e.g. `[Topic 2]`), treat it as a stacked PR. See `.cursor/rules/pr.mdc` § "Stacked PRs" for full details.
Derive the branch name from the changes being made. Use `feat/`, `fix/`, `ref/`, etc. matching the commit type conventions.
23
35
36
+
**For stacked PRs:** For the first PR in a new stack, first create and push the collection branch (see `.cursor/rules/pr.mdc` § "Creating the Collection Branch"), then branch the PR off it. For subsequent PRs, branch off the previous stack branch. Use the naming conventions from `.cursor/rules/pr.mdc` § "Branch Naming".
37
+
38
+
**CRITICAL: Never merge, fast-forward, or push commits into the collection branch.** It stays at its initial position until the user merges stack PRs through GitHub. Updating it will auto-merge and destroy the entire PR stack.
39
+
24
40
## Step 2: Format Code and Regenerate API Files
25
41
26
42
```bash
@@ -92,13 +108,39 @@ Invoke the `sentry-skills:create-pr` skill to create a draft PR. When providing
92
108
93
109
Fill in each section based on the changes being PR'd. Check any checklist items that apply.
94
110
95
-
Then continue to Step 6.
111
+
**For stacked PRs:**
112
+
113
+
- Pass `--base <previous-stack-branch>` so the PR targets the previous branch (first PR in a stack targets the collection branch).
114
+
- Use the stacked PR title format: `<type>(<scope>): [<Topic> <N>] <Subject>` (see `.cursor/rules/pr.mdc` § "PR Title Naming").
115
+
- Include the stack list at the top of the PR body, before the `## :scroll: Description` section (see `.cursor/rules/pr.mdc` § "Stack List in PR Description" for the format).
116
+
- Add a merge method reminder at the very end of the PR body (see `.cursor/rules/pr.mdc` § "Stack List in PR Description" for the exact text). This only applies to stack PRs, not the collection branch PR.
117
+
118
+
Then continue to Step 5.5 (stacked PRs only) or Step 6.
119
+
120
+
## Step 5.5: Update Stack List on All PRs (stacked PRs only)
121
+
122
+
Skip this step for standalone PRs.
123
+
124
+
After creating the PR, update the PR description on **every other PR in the stack — including the collection branch PR** — so all PRs have the same up-to-date stack list. Follow the format and commands in `.cursor/rules/pr.mdc` § "Stack List in PR Description".
96
125
97
126
## Step 6: Update Changelog
98
127
99
-
After the PR is created, add an entry to `CHANGELOG.md` under the `## Unreleased` section.
128
+
First, determine whether a changelog entry is needed. **Skip this step** (and go straight to "No changelog needed" below) if the changes are not user-facing, for example:
129
+
130
+
- Test-only changes (new tests, test refactors, test fixtures)
131
+
- CI/CD or build configuration changes
132
+
- Documentation-only changes
133
+
- Code comments or formatting-only changes
134
+
- Internal refactors with no behavior change visible to SDK users
135
+
- Sample app changes
136
+
137
+
If unsure, ask the user.
138
+
139
+
### If changelog is needed
140
+
141
+
Add an entry to `CHANGELOG.md` under the `## Unreleased` section.
100
142
101
-
### Determine the subsection
143
+
####Determine the subsection
102
144
103
145
| Change Type | Subsection |
104
146
|---|---|
@@ -109,15 +151,15 @@ After the PR is created, add an entry to `CHANGELOG.md` under the `## Unreleased
109
151
110
152
Create the subsection under `## Unreleased` if it does not already exist.
Use the PR number returned by `sentry-skills:create-pr`. Match the style of existing entries — sentence case, ending with the PR link, no trailing period.
119
161
120
-
### Commit and push
162
+
####Commit and push
121
163
122
164
Stage `CHANGELOG.md`, commit with message `changelog`, and push:
123
165
@@ -126,3 +168,13 @@ git add CHANGELOG.md
126
168
git commit -m "changelog"
127
169
git push
128
170
```
171
+
172
+
### No changelog needed
173
+
174
+
If no changelog entry is needed, add `#skip-changelog` to the PR description to disable the changelog CI check:
175
+
176
+
```bash
177
+
gh pr view <PR_NUMBER> --json body --jq '.body'> /tmp/pr-body.md
- The first PR in the stack targets `main` as its base branch.
126
+
- A **collection branch** is created from `main` and targets `main`. It serves as the base for the entire stack.
127
+
- The first PR in the stack targets the collection branch (not `main`).
127
128
- Each subsequent PR targets the previous stack PR's branch as its base.
128
129
- Each PR contains only incremental changes on top of the previous one.
129
130
131
+
The collection branch exists so that individual stack PRs can be **merge-committed** (not squashed). PRs targeting `main` use squash merging, but that causes repeated merge conflicts when syncing the stack. Merge commits on non-`main` branches avoid this. The collection branch itself is squash-merged into `main` at the end.
132
+
130
133
### Branch Naming
131
134
132
-
Prefer a shared prefix for the feature, with descriptive suffixes per PR. The type prefix (`feat/`, `fix/`, etc.) may vary depending on the nature of each PR's changes:
135
+
Prefer a shared prefix for the feature, with descriptive suffixes per PR. The collection branch uses the shared prefix. The type prefix (`feat/`, `fix/`, etc.) may vary depending on the nature of each PR's changes:
133
136
134
137
```
135
-
feat/scope-attributes # PR 1
136
-
feat/scope-attributes-logger # PR 2
137
-
fix/attribute-type-detection # PR 3 (fix, different name — that's fine)
138
+
feat/scope-attributes # collection branch → targets main
2. Read the stack comment on that PR — it lists every PR in the stack.
162
-
3. If there is no stack comment yet, walk the chain in both directions:
165
+
2. Read the PR description — the stack list is at the top of the body.
166
+
3. If there is no stack list yet, walk the chain in both directions:
163
167
```bash
164
168
# Find the PR whose head branch is the current PR's base (go up)
165
169
gh pr list --head <baseRefName> --json number,title,baseRefName
166
170
167
171
# Find PRs whose base branch is the current PR's head (go down)
168
172
gh pr list --base <currentBranch> --json number,title,headRefName
169
173
```
170
-
Repeat until you reach `main` going up and find no more PRs going down.
174
+
Repeat until you reach the collection branch going up and find no more PRs going down.
175
+
176
+
### Creating the Collection Branch
177
+
178
+
Before the first stacked PR, create the collection branch with an empty commit (so GitHub allows opening a PR) and create the collection PR:
179
+
180
+
```bash
181
+
git checkout main
182
+
git checkout -b feat/<topic>
183
+
git commit --allow-empty -m "collection: <topic>"
184
+
git push -u origin HEAD
185
+
gh pr create --base main --draft --title "<type>(<scope>): <Topic>" --body "Collection PR for the <Topic> stack. Squash-merge this once all stack PRs are merged."
186
+
```
187
+
188
+
**CRITICAL: Do NOT manually update the collection branch.** Never merge, fast-forward, or push stack branch commits into the collection branch. The collection branch stays at its initial position (the empty commit on `main`) until the user merges individual stack PRs into it one by one through GitHub. If you fast-forward the collection branch to include stack commits, GitHub will auto-merge and delete all stack PR branches, destroying the entire stack.
171
189
172
190
### Creating a New Stacked PR
173
191
174
-
1. Start from the tip of the previous stack branch (or `main` for the first PR).
192
+
1. Start from the tip of the previous stack branch (or the collection branch for the first PR).
175
193
2. Create a new branch, make changes, format, commit, and push.
176
-
3. Create the PR with `--base <previous-branch>`:
194
+
3. Create the PR with `--base <previous-branch>` (the collection branch for the first PR):
4. Add the stack comment to the new PR and update it on all existing PRs in the stack (see below).
198
+
4. Add the stack list to the top of the new PR's description and update it on all existing PRs in the stack (see below).
181
199
182
-
### Stack Comment
200
+
### Stack List in PR Description
183
201
184
-
Every PR in the stack must have a comment listing all PRs in the stack. When a new PR is added, update the comment on **all** PRs in the stack.
202
+
Every PR in the stack — **including the collection branch PR** — must have a stack list **at the top of its description** (before the `## :scroll: Description` section). When a new PR is added, update the description on **all** PRs in the stack and on the collection branch PR.
185
203
186
204
Format:
187
205
@@ -191,35 +209,50 @@ Format:
191
209
- [#5118](https://github.com/getsentry/sentry-java/pull/5118) — Add scope-level attributes API
192
210
- [#5120](https://github.com/getsentry/sentry-java/pull/5120) — Wire scope attributes into LoggerApi and MetricsApi
193
211
- [#5121](https://github.com/getsentry/sentry-java/pull/5121) — Showcase scope attributes in Spring Boot 4 samples
212
+
213
+
---
194
214
```
195
215
196
-
No status column — GitHub already shows that.
216
+
No status column — GitHub already shows that. The `---` separates the stack list from the rest of the PR description.
217
+
218
+
**Merge method reminder:** On stack PRs (not the collection branch PR), add the following line at the very end of the PR description:
219
+
220
+
```markdown
221
+
> ⚠️ **Merge this PR using a merge commit** (not squash). Only the collection branch is squash-merged into main.
222
+
```
197
223
198
-
To add or update the stack comment on a PR:
224
+
This does not apply to standalone PRs or the collection branch PR.
225
+
226
+
To update the PR description, use `--body-file` to avoid shell quoting issues with special characters in the body:
### Merging Stacked PRs (done by the user, not the agent)
241
+
242
+
Individual stack PRs are merged in order from bottom to top (PR 1 first, then PR 2, etc.) using **merge commits** (not squash). After each merge, the next PR's base automatically becomes the merged branch's target. GitHub handles rebasing onto the new base.
212
243
213
-
Merge in order from bottom to top (PR 1 first, then PR 2, etc.). After each merge, the next PR's base automatically becomes the merged branch's target. GitHub handles rebasing onto the new base. Verify each PR's diff still looks correct after the previous one merges.
244
+
Once all stack PRs are merged into the collection branch, the collection PR is **squash-merged** into `main`. This gives `main` a clean single commit for the entire feature.
245
+
246
+
**Do not merge PRs.** Only the user merges PRs.
214
247
215
248
### Syncing the Stack
216
249
217
-
When a base PR changes (e.g. after addressing review feedback on PR 1), merge the changes forward through the stack:
250
+
When a base PR changes (e.g. after addressing review feedback on PR 1), merge the changes forward through the stack **between adjacent stack PR branches only**:
**Never merge into the collection branch.** Syncing only happens between stack PR branches. The collection branch is untouched until the user merges PRs through GitHub.
265
+
231
266
Prefer merge over rebase — it preserves commit history, doesn't invalidate existing review comments, and avoids the need for force-pushing. Only rebase if explicitly requested.
- Spring Boot `application.properties`: `sentry.shutdownTimeoutMillis`, `sentry.sessionFlushTimeoutMillis`
7
20
- Add scope-level attributes API ([#5118](https://github.com/getsentry/sentry-java/pull/5118)) via ([#5148](https://github.com/getsentry/sentry-java/pull/5148))
8
21
- Automatically include scope attributes in logs and metrics ([#5120](https://github.com/getsentry/sentry-java/pull/5120))
9
22
- New APIs are `Sentry.setAttribute`, `Sentry.setAttributes`, `Sentry.removeAttribute`
- The `ManifestMetaDataReader` now read the `DIST` ([#5107](https://github.com/getsentry/sentry-java/pull/5107))
49
+
- Add new experimental option to capture profiles for ANRs ([#4899](https://github.com/getsentry/sentry-java/pull/4899))
50
+
- This feature will capture a stack profile of the main thread when it gets unresponsive
51
+
- The profile gets attached to the ANR event on the next app start, providing a flamegraph of the ANR issue on the sentry issue details page
52
+
- Enable via `options.setAnrProfilingSampleRate(<sample-rate>)` or AndroidManifest.xml: `<meta-data android:name="io.sentry.anr.profiling.sample-rate" android:value="[0.0-1.0]" />`
53
+
- The sample rate controls the probability of collecting a profile for each detected foreground ANR (0.0 to 1.0, null to disable)
54
+
- Add `enableAnrFingerprinting` option to reduce ANR noise by assigning static fingerprints to ANR events with system-only stacktraces
55
+
- When enabled, ANRs whose stacktraces contain only system frames (e.g. `java.lang` or `android.os`) are grouped into a single issue instead of creating many separate issues
56
+
- Enable via `options.setEnableAnrFingerprinting(true)` or AndroidManifest.xml: `<meta-data android:name="io.sentry.anr.enable-fingerprinting" android:value="true" />`
36
57
37
58
### Features
38
59
@@ -174,7 +195,7 @@
174
195
- Discard envelopes on `4xx` and `5xx` response ([#4950](https://github.com/getsentry/sentry-java/pull/4950))
175
196
- This aims to not overwhelm Sentry after an outage or load shedding (including HTTP 429) where too many events are sent at once
176
197
177
-
### Feature
198
+
### Features
178
199
179
200
- Add a Tombstone integration that detects native crashes without relying on the NDK integration, but instead using `ApplicationExitInfo.REASON_CRASH_NATIVE` on Android 12+. ([#4933](https://github.com/getsentry/sentry-java/pull/4933))
180
201
- Currently exposed via options as an _internal_ API only.
0 commit comments