@sentry/junior-github 0.49.0 → 0.50.0
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/package.json
CHANGED
|
@@ -6,90 +6,172 @@ allowed-tools: bash
|
|
|
6
6
|
|
|
7
7
|
# GitHub Code Operations
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
Use `gh` and `git` for repository checkout, source investigation, code changes, commits, and pull requests.
|
|
10
10
|
|
|
11
|
-
##
|
|
11
|
+
## References
|
|
12
12
|
|
|
13
|
-
|
|
|
14
|
-
|
|
|
15
|
-
|
|
|
16
|
-
|
|
|
13
|
+
| Need | Load |
|
|
14
|
+
| ---- | ---- |
|
|
15
|
+
| Command syntax, permissions, config | [references/api-surface.md](references/api-surface.md) |
|
|
16
|
+
| Failed commands, auth errors | [references/troubleshooting-workarounds.md](references/troubleshooting-workarounds.md) |
|
|
17
|
+
|
|
18
|
+
## Core rules
|
|
19
|
+
|
|
20
|
+
- Resolve the target repo: explicit request wins, then `github.repo` config. Run `jr-rpc config get github.repo` standalone — never chain with `cd`, pipes, `gh`, or `git`.
|
|
21
|
+
- Keep `--repo owner/repo` explicit on all `gh` commands; use `git -C PATH` for local repos.
|
|
22
|
+
- Do not treat this skill's files or `/skills/...` as target repository source.
|
|
23
|
+
- Read repo-local instructions (`AGENTS.md`, `.github/AGENTS.md`, nested equivalents) before editing. When repo, task-specific, and skill instructions conflict, follow the narrower rule.
|
|
24
|
+
- Do not overwrite or revert unrelated user changes.
|
|
25
|
+
- Do not guess architecture, upstream intent, or feedback validity without reading the relevant code, comments, or failing output.
|
|
26
|
+
- Do not claim checks ran unless they did. Do not declare a fix complete without running the chosen check or stating why no credible check was available.
|
|
27
|
+
- Stop on: missing repo access, ambiguous target, destructive op without confirmation, or unresolved auth failure.
|
|
17
28
|
|
|
18
29
|
## Workflow
|
|
19
30
|
|
|
20
|
-
### 1. Resolve
|
|
31
|
+
### 1. Resolve target and state
|
|
21
32
|
|
|
22
|
-
|
|
23
|
-
- Resolve repository from the requested action: explicit target wins; otherwise use `<configuration>` `github.repo`. If absent, run standalone `jr-rpc config get github.repo`.
|
|
24
|
-
- Preserve non-target GitHub references when they materially support the work.
|
|
25
|
-
- Run `jr-rpc config get github.repo` as its own bash command. Do not combine it with `cd`, `&&`, pipes, or any `gh` or `git` command.
|
|
26
|
-
- After resolving a configured repo, pass it explicitly to the next `gh` command with `--repo owner/repo`; do not rely on implicit GitHub CLI repository discovery.
|
|
27
|
-
- Resolve the pull request number for operations targeting an existing PR.
|
|
28
|
-
- Keep `--repo owner/repo` explicit on `gh` commands so the command itself targets the intended repository, not a stale default.
|
|
33
|
+
Identify `owner/repo`, local checkout path, default branch, and current branch.
|
|
29
34
|
|
|
30
|
-
|
|
35
|
+
For edit operations, also check:
|
|
31
36
|
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
37
|
+
- current branch and uncommitted changes
|
|
38
|
+
- package manager, build tool, monorepo structure
|
|
39
|
+
- relevant test/lint/typecheck commands
|
|
40
|
+
- repo-local instructions that override this skill
|
|
36
41
|
|
|
37
|
-
|
|
42
|
+
Choose a validation path before editing:
|
|
38
43
|
|
|
39
|
-
|
|
44
|
+
- changed-file or package-scoped checks before broad suites
|
|
45
|
+
- targeted tests before full runs
|
|
46
|
+
- repo-native scripts, fixtures, playgrounds, or smoke checks before one-off scaffolding
|
|
40
47
|
|
|
41
|
-
-
|
|
42
|
-
- Use exact command forms from [references/api-surface.md](references/api-surface.md).
|
|
43
|
-
- After cloning, check for `AGENTS.md` in the repo root (and `.github/AGENTS.md`) before making edits. Treat discovered instructions as hard constraints.
|
|
44
|
-
- Report the local directory and whether the clone is shallow or full.
|
|
48
|
+
For risky, user-visible, or long-running changes, capture a baseline before editing. If the baseline already fails, record it as pre-existing.
|
|
45
49
|
|
|
46
|
-
|
|
50
|
+
Prefer existing local checkouts over cloning. Default to shallow clones.
|
|
47
51
|
|
|
48
|
-
###
|
|
52
|
+
### 2. Investigate before editing
|
|
49
53
|
|
|
50
|
-
|
|
51
|
-
- If the current workspace already contains the target repository, inspect local files directly before cloning.
|
|
52
|
-
- Do not treat this skill's `SKILL.md`, bundled references, or `/vercel/sandbox/skills/...` as target repository source code. If no checkout of the target repo is present, inspect the configured GitHub repository by cloning it shallowly or reading files through `gh` before answering.
|
|
53
|
-
- Prefer the narrowest deterministic evidence: local file search, exact file reads, targeted clone inspection, existing issues/PRs, tests.
|
|
54
|
-
- Cite repository evidence in the reply: file paths, symbols, issue/PR numbers, or commit references when known.
|
|
55
|
-
- If evidence is incomplete, say what is unknown instead of guessing.
|
|
54
|
+
Before changing code, establish:
|
|
56
55
|
|
|
57
|
-
|
|
56
|
+
- where the behavior lives
|
|
57
|
+
- what the current vs. requested behavior is
|
|
58
|
+
- root cause or gap the change addresses
|
|
59
|
+
- what smallest check can prove the result
|
|
60
|
+
|
|
61
|
+
Rules:
|
|
62
|
+
|
|
63
|
+
- Prefer narrow evidence: file reads, grep, tests, existing issues/PRs, command output.
|
|
64
|
+
- Read referenced issues, PRs, specs, policies, designs, or incidents when the task points to them.
|
|
65
|
+
- For product copy, docs, design, or UI work, inspect the real product/project context before inventing wording or layout.
|
|
66
|
+
- Before editing a bug, know the failure shape: what breaks, where, and under what condition.
|
|
67
|
+
- After a failed fix attempt or strong correction, stop patching symptoms — re-read the evidence and restate the root cause before editing again.
|
|
68
|
+
- If the task is investigation-only, answer from evidence without editing.
|
|
69
|
+
|
|
70
|
+
### 3. Edit safely
|
|
71
|
+
|
|
72
|
+
- Smallest coherent change that satisfies the request.
|
|
73
|
+
- Follow repo-local style, patterns, and API boundaries.
|
|
74
|
+
- Keep interfaces, exports, config, and public surfaces no broader than the requirement needs.
|
|
75
|
+
- When the change touches related call sites or representations, remove duplication or split logic introduced by the change before finalizing.
|
|
76
|
+
- No drive-by refactors or speculative cleanup.
|
|
77
|
+
- Do not optimize only for passing tests; solve the requested behavior.
|
|
78
|
+
- After meaningful edits, run the smallest relevant repo-real check.
|
|
79
|
+
- On check failure, inspect root cause before patching again.
|
|
80
|
+
|
|
81
|
+
For multi-step or risky work, keep a compact checklist of intent, touched files, verification state, next step, and blockers.
|
|
82
|
+
|
|
83
|
+
For non-obvious architecture, security-sensitive, concurrency, or repeated-failure work, pause after investigation with evidence, risks, and a proposed plan before pushing ahead.
|
|
84
|
+
|
|
85
|
+
### 4. Verify before packaging
|
|
86
|
+
|
|
87
|
+
Before committing and creating a PR for code, config, or docs-as-code changes:
|
|
88
|
+
|
|
89
|
+
- Run the chosen validation path. Separate pre-existing failures from regressions.
|
|
90
|
+
- For docs or instruction-only changes, do a content consistency review instead of claiming automated validation.
|
|
91
|
+
- If no credible check exists, say so explicitly.
|
|
92
|
+
|
|
93
|
+
### 5. Commit
|
|
94
|
+
|
|
95
|
+
Default format when the repo does not specify otherwise:
|
|
96
|
+
|
|
97
|
+
```
|
|
98
|
+
<type>(<scope>): <Subject>
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
Types: `feat`, `fix`, `ref`, `docs`, `test`, `build`, `ci`, `chore`. Imperative present tense, no trailing period, no agent/tool branding. Keep lines under 100 characters.
|
|
58
102
|
|
|
59
|
-
|
|
103
|
+
Body only when it helps reviewers understand _why_.
|
|
60
104
|
|
|
61
|
-
|
|
62
|
-
- When inspecting PR comments or feedback, query both conversation comments (`--json comments`) and review comments (`gh api .../pulls/{number}/comments` and `.../reviews`). Bot review feedback lives in the review comments API, not conversation comments.
|
|
63
|
-
- Return canonical PR URL, PR number when available, target repository, and the fields the user asked to inspect.
|
|
64
|
-
- If the PR cannot be resolved, report the exact not-found or auth failure and stop.
|
|
105
|
+
Footer order: `Fixes`/`Refs` lines, then `Co-authored-by` trailers.
|
|
65
106
|
|
|
107
|
+
#### On-behalf-of commits
|
|
108
|
+
|
|
109
|
+
If the commit is authored by a bot and a human requested the work, add a trailer:
|
|
110
|
+
|
|
111
|
+
```
|
|
112
|
+
Co-authored-by: Full Name <email>
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
Resolve name and email from evidence — requester context, Slack profile (`slackUserLookup`), GitHub profile, or repo commit history. If email cannot be confirmed, use `Full Name <noreply>` and note the gap in the PR body.
|
|
116
|
+
|
|
117
|
+
### 6. Create or update PR
|
|
118
|
+
|
|
119
|
+
Before creating:
|
|
120
|
+
|
|
121
|
+
1. Changes committed on a non-default branch.
|
|
122
|
+
2. Push the branch explicitly: `git push -u origin BRANCH`.
|
|
123
|
+
3. Create with explicit targeting: `gh pr create --repo owner/repo --head BRANCH ...`.
|
|
124
|
+
|
|
125
|
+
Defaults:
|
|
126
|
+
|
|
127
|
+
- Draft PRs unless the user or repo says otherwise.
|
|
128
|
+
- Reuse an existing PR for the branch; only open a new one when explicitly asked or the work is materially distinct.
|
|
129
|
+
- After new commits, re-evaluate title and body against the current diff.
|
|
130
|
+
|
|
131
|
+
**Title:** `<type>(<scope>): <Subject>` — same rules as commits, no agent branding.
|
|
132
|
+
|
|
133
|
+
**Body:**
|
|
134
|
+
|
|
135
|
+
- Reviewer-facing prose, not diff narration.
|
|
136
|
+
- What changed and why; what was verified; what remains unverified or risky.
|
|
137
|
+
- Issue references when relevant.
|
|
138
|
+
- No checkbox boilerplate, no PII or customer data in public repos.
|
|
139
|
+
|
|
140
|
+
**Footers** (in order):
|
|
141
|
+
|
|
142
|
+
1. Issue references (`Fixes #N`, `Refs SENTRY-N`), if any.
|
|
143
|
+
2. `Action taken on behalf of Full Name.` — when on-behalf-of.
|
|
144
|
+
3. Session link — when `gen_ai.conversation.id` is available:
|
|
145
|
+
|
|
146
|
+
```
|
|
66
147
|
---
|
|
148
|
+
[View Session in Sentry](https://sentry.sentry.io/traces/?project=4510944073809921&query=gen_ai.conversation.id%3A%22<url-encoded conversation id>%22)
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
**Assignment:** resolve GitHub handles from evidence (`gh api search/users`, org membership, repo history) before assigning reviewers or the requester. Skip assignment when the handle cannot be confirmed.
|
|
152
|
+
|
|
153
|
+
### 7. Report result
|
|
154
|
+
|
|
155
|
+
Return: repo, branch, PR URL/number (when applicable), checks run with results, pre-existing failures if any, checks not run and why.
|
|
67
156
|
|
|
68
|
-
|
|
157
|
+
On failure, report the exact command and error. Do not claim success from partial state.
|
|
69
158
|
|
|
70
|
-
|
|
159
|
+
Before finishing, reconcile any plan or checklist stated earlier — mark items as done, blocked, or cancelled.
|
|
71
160
|
|
|
72
|
-
|
|
73
|
-
- For PR creation, resolve the base branch (explicit user request wins; otherwise repository default).
|
|
74
|
-
- Resolve the head branch from the current checkout or user request.
|
|
75
|
-
- If the head branch may not exist on the remote yet, push it explicitly before PR creation.
|
|
161
|
+
## Operation-specific notes
|
|
76
162
|
|
|
77
|
-
|
|
163
|
+
**Clone** — shallow by default; deepen only when history is needed. Read repo instructions after cloning, before editing.
|
|
78
164
|
|
|
79
|
-
|
|
80
|
-
- If `git push` returns 401/403 or another auth/permission error, verify the command is targeting the right repository and retry once. If it still fails, report the exact command failure and the GitHub App installation/permission remediation.
|
|
81
|
-
- Treat `gh pr merge` as a contents mutation and keep repository context explicit.
|
|
165
|
+
**Source investigation** — use local files first, otherwise clone shallowly or use `gh`. Cite evidence: file paths, symbols, PRs, issues, command output.
|
|
82
166
|
|
|
83
|
-
|
|
167
|
+
**PR inspection** — read-only `gh pr` and `gh api` commands. Query both conversation comments (`--json comments`) and review comments (`gh api .../pulls/{n}/comments` and `.../reviews`).
|
|
84
168
|
|
|
85
|
-
|
|
86
|
-
- If PR creation fails after explicit push + explicit repo scoping, report the exact auth or validation failure and stop.
|
|
169
|
+
**PR mutation** — push before create. Retry once on auth failure after verifying repo targeting. Treat merge, close-with-delete, and force-push as confirmation-required. No admin mutations.
|
|
87
170
|
|
|
88
171
|
## Guardrails
|
|
89
172
|
|
|
90
|
-
-
|
|
91
|
-
-
|
|
92
|
-
-
|
|
93
|
-
-
|
|
94
|
-
-
|
|
95
|
-
- Do not execute repository admin mutations.
|
|
173
|
+
- Default shallow clones; deepen only when needed.
|
|
174
|
+
- Confirm before destructive merges or force operations.
|
|
175
|
+
- Answer source questions from repo evidence, not product framing or memory.
|
|
176
|
+
- GitHub App auth is host-managed; do not ask users to reconnect accounts.
|
|
177
|
+
- Stop and return concrete remediation on missing access or permissions.
|
|
@@ -26,8 +26,14 @@ Treat explicit repo flags as command-targeting safety rails, not as a credential
|
|
|
26
26
|
| Clone repository (default shallow) | `gh repo clone owner/repo [DIRECTORY] -- --depth=1` |
|
|
27
27
|
| Deepen shallow clone | `git -C DIRECTORY fetch --depth=N origin` |
|
|
28
28
|
| Convert shallow clone to full | `git -C DIRECTORY fetch --unshallow` |
|
|
29
|
+
| Check branch | `git -C DIRECTORY branch --show-current` |
|
|
30
|
+
| Check worktree state | `git -C DIRECTORY status --short --branch` |
|
|
31
|
+
| View commit log against base | `git -C DIRECTORY log BASE..HEAD --oneline` |
|
|
32
|
+
| Diff against base | `git -C DIRECTORY diff BASE...HEAD` |
|
|
33
|
+
| Create branch | `git -C DIRECTORY checkout -b BRANCH` |
|
|
34
|
+
| Stage and commit | `git -C DIRECTORY add -A && git -C DIRECTORY commit -m "message"` |
|
|
29
35
|
| Push branch before PR creation | `git -C DIRECTORY push -u origin BRANCH` |
|
|
30
|
-
| Create pull request
|
|
36
|
+
| Create pull request (draft) | `gh pr create --draft --repo owner/repo --head BRANCH --base BASE --title "..." --body-file PATH` |
|
|
31
37
|
| Update pull request | `gh pr edit NUMBER --repo owner/repo [--title "..."] [--body-file PATH]` |
|
|
32
38
|
| Close pull request | `gh pr close NUMBER --repo owner/repo` |
|
|
33
39
|
| Merge pull request | `gh pr merge NUMBER --repo owner/repo [--merge \| --squash \| --rebase]` |
|