github-code

name	github-code
description	Clone repositories, inspect source, edit code, and manage pull requests with GitHub CLI. Use for repo implementation questions, cloning/editing, PR inspection/mutation, and PR auth-order questions. For PR auth order, answer that `git push` needs GitHub remote write access before `gh pr create`. Prefer this skill for repository and code tasks even when the repo concerns Sentry products.
allowed-tools	bash

GitHub Code Operations

Use gh and git for repository checkout, source investigation, code changes, commits, and pull requests.

References

Need	Load
Command syntax, permissions, config	references/api-surface.md
Failed commands, auth errors	references/troubleshooting-workarounds.md

Core rules

• 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.
• Keep --repo owner/repo explicit on all gh commands; use git -C PATH for local repos.
• Do not treat this skill's files or /skills/... as target repository source.
• 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.
• Do not overwrite or revert unrelated user changes.
• Do not guess architecture, upstream intent, or feedback validity without reading the relevant code, comments, or failing output.
• 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.
• Stop on: missing repo access, ambiguous target, destructive op without confirmation, or unresolved auth failure.

Workflow

1. Resolve target and state

Identify owner/repo, local checkout path, default branch, and current branch.

For edit operations, also check:

• current branch and uncommitted changes
• package manager, build tool, monorepo structure
• relevant test/lint/typecheck commands
• repo-local instructions that override this skill

Choose a validation path before editing:

• changed-file or package-scoped checks before broad suites
• targeted tests before full runs
• repo-native scripts, fixtures, playgrounds, or smoke checks before one-off scaffolding

For risky, user-visible, or long-running changes, capture a baseline before editing. If the baseline already fails, record it as pre-existing.

Prefer existing local checkouts over cloning. Default to shallow clones.

2. Investigate before editing

Before changing code, establish:

• where the behavior lives
• what the current vs. requested behavior is
• root cause or gap the change addresses
• what smallest check can prove the result

Rules:

• Prefer narrow evidence: file reads, grep, tests, existing issues/PRs, command output.
• Read referenced issues, PRs, specs, policies, designs, or incidents when the task points to them.
• For product copy, docs, design, or UI work, inspect the real product/project context before inventing wording or layout.
• Before editing a bug, know the failure shape: what breaks, where, and under what condition.
• After a failed fix attempt or strong correction, stop patching symptoms — re-read the evidence and restate the root cause before editing again.
• If the task is investigation-only, answer from evidence without editing.

3. Edit safely

• Smallest coherent change that satisfies the request.
• Follow repo-local style, patterns, and API boundaries.
• Keep interfaces, exports, config, and public surfaces no broader than the requirement needs.
• When the change touches related call sites or representations, remove duplication or split logic introduced by the change before finalizing.
• No drive-by refactors or speculative cleanup.
• Do not optimize only for passing tests; solve the requested behavior.
• After meaningful edits, run the smallest relevant repo-real check.
• On check failure, inspect root cause before patching again.

For multi-step or risky work, keep a compact checklist of intent, touched files, verification state, next step, and blockers.

For non-obvious architecture, security-sensitive, concurrency, or repeated-failure work, pause after investigation with evidence, risks, and a proposed plan before pushing ahead.

4. Verify before packaging

Before committing and creating a PR for code, config, or docs-as-code changes:

• Run the chosen validation path. Separate pre-existing failures from regressions.
• For docs or instruction-only changes, do a content consistency review instead of claiming automated validation.
• If no credible check exists, say so explicitly.

5. Commit

Default format when the repo does not specify otherwise:

<type>(<scope>): <Subject>

Types: feat, fix, ref, docs, test, build, ci, chore. Imperative present tense, no trailing period, no agent/tool branding. Keep lines under 100 characters.

Body only when it helps reviewers understand why.

Footer order: Fixes/Refs lines, then Co-authored-by trailers.

On-behalf-of commits

If the commit is authored by a bot and a human requested the work, add a trailer:

Co-authored-by: Full Name <email>

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.

6. Create or update PR

Before creating:

1. Changes committed on a non-default branch.
2. Push the branch explicitly: git push -u origin BRANCH.
3. Create with explicit targeting: gh pr create --repo owner/repo --head BRANCH ....

Defaults:

• Draft PRs unless the user or repo says otherwise.
• Reuse an existing PR for the branch; only open a new one when explicitly asked or the work is materially distinct.
• After new commits, re-evaluate title and body against the current diff.

Title: <type>(<scope>): <Subject> — same rules as commits, no agent branding.

Body:

• Reviewer-facing prose, not diff narration.
• What changed and why; what was verified; what remains unverified or risky.
• Issue references when relevant.
• No checkbox boilerplate, no PII or customer data in public repos.

Footers (in order):

1. Issue references (Fixes #N, Refs SENTRY-N), if any.
2. Action taken on behalf of Full Name. — when on-behalf-of.
3. Session link — when gen_ai.conversation.id is available:

---
[View Session in Sentry](https://sentry.sentry.io/traces/?project=4510944073809921&query=gen_ai.conversation.id%3A%22<url-encoded conversation id>%22)

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.

7. Report result

Return: repo, branch, PR URL/number (when applicable), checks run with results, pre-existing failures if any, checks not run and why.

On failure, report the exact command and error. Do not claim success from partial state.

Before finishing, reconcile any plan or checklist stated earlier — mark items as done, blocked, or cancelled.

Operation-specific notes

Clone — shallow by default; deepen only when history is needed. Read repo instructions after cloning, before editing.

Source investigation — use local files first, otherwise clone shallowly or use gh. Cite evidence: file paths, symbols, PRs, issues, command output.

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).

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.

Guardrails

• Default shallow clones; deepen only when needed.
• Confirm before destructive merges or force operations.
• Answer source questions from repo evidence, not product framing or memory.
• GitHub App auth is host-managed; do not ask users to reconnect accounts.
• Stop and return concrete remediation on missing access or permissions.