github-deep-review

---
name: github-deep-review
description: "Use when working with gitHub deep review: bugs, PRs, best fix, stale-or-real, read code first from steipete/agent-scripts."
source: https://github.com/steipete/agent-scripts/tree/main/skills/github-deep-review
generated: 2026-05-27T20:55:45.652Z
category: tool
audience: engineers
---

## When to use

- Use this shape when the user asks "what is this about", "is this the best fix", or "what did we fix":.
- Using the github-deep-review skill's upstream workflow, guardrails, and local-tool assumptions.
- Auditing commands or operational steps before changing github deep review behavior.
- Needing a compact agent reference for gitHub deep review: bugs, PRs, best fix, stale-or-real, read code first.

## Key concepts

### Start

Use gh, not web browsing, for GitHub refs: For PRs, collect author context by default unless the author is Peter (steipete or an obvious Peter-owned account). Use the local workflow in ~/Projects/agent-scripts/skills/github-author-context/SKILL.md and include a short Author context: block near the top of the review when the author is not Peter. After merge/rejection/close/review, use that same author-context workflow to append a contributor note only when the interaction creates durable...

### Review Contract

Always answer these, explicitly: URL/ref: issue or PR number and affected surface. What is the bug or behavior being fixed? Can we identify the root cause? If yes, where in code and why. If no, what evidence is missing. For regressions, who/what introduced it and when? Include commit/PR provenance when traceable by bounded history; say unknown instead of guessing. Is the current/proposed fix the best possible fix after reading adjacent code? Would a bigger refactor improve correctness...

### Code Reading Depth

Read past the first touched file. Follow the real call path: entrypoint -> validation/parsing -> routing/dispatch -> owner module -> shared helper -> persistence/network/runtime boundary config/schema/docs -> runtime usage -> doctor/migration/fix path provider/channel/plugin owner code -> generic core seam, only if multiple owners need it tests around the touched surface plus adjacent regression tests When behavior depends on a dependency, read the upstream docs/source/types or current...

### Provenance

For bug/regression reviews, include a compact Provenance: answer when feasible: Use git log -S/-G, git blame, linked PRs/issues, and tests. Separate author, committer/merger, and current PR author when they differ. Phrase as introduced by, made visible by, or carried forward by. Include confidence: clear, likely, or unknown. For features, docs, refactors, or untraceable bugs, write N/A or say what evidence is missing.

### Fix Quality Bar

Good fixes usually: live at the ownership boundary where the bug belongs preserve public/backward-compatible behavior unless the issue is about retiring it add a regression test at the smallest meaningful seam avoid broad special cases, hidden migrations, semantic sentinels, and provider/channel IDs in generic core update docs/changelog when user-visible behavior changes fail clearly in runtime paths and repair through doctor/migration paths when that is the established contract Call out...

### PR Review Shape

Lead with findings when reviewing a PR. Findings need file/line/symbol references and a concrete failure mode. Avoid vague "consider" comments. If no blocking issues: say no blocking correctness issues found list the strongest proof checked name residual risk/test gaps answer whether the design is the best available shape Do not approve, comment, close, merge, push, or land unless the user asked for that action.

## API reference

```
npx skills add steipete/agent-scripts --skill github-deep-review
```

Install the github-deep-review skill from steipete/agent-scripts.

```
npx skills add steipete/agent-scripts --skill github-deep-review
```

```
gh issue view <n> --json number,title,state,author,body,comments,labels,updatedAt,url.
```

Command or snippet documented by the upstream github-deep-review skill.

```
gh issue view <n> --json number,title,state,author,body,comments,labels,updatedAt,url
gh pr view <n> --json number,title,state,author,body,comments,reviews,files,commits,statusCheckRollup,mergeStateStatus,headRefName,headRepositoryOwner,url
gh pr diff <n> --patch
```

```
git status --short --branch.
```

Command or snippet documented by the upstream github-deep-review skill.

```
git status --short --branch
git fetch origin
git log --oneline --decorate -20
rg "<key symbol/error/config/endpoint>"
```

```
Ref: #123 / PR #456.
```

Command or snippet documented by the upstream github-deep-review skill.

```
Ref: #123 / PR #456
Surface: <runtime/CLI/provider/channel/docs>

Bug: <one or two sentences>
Cause: <code path + confidence>
Provenance: <introduced/made visible/carried forward by commit/PR/date, or N/A/unknown>
Best fix: <what should change and why>
Refactor: <yes/no, specific shape>
Proof: <tests/live/CI/source/dependency docs>
Risk: <remaining uncertainty>
```

## Gotchas

- Always answer these, explicitly:.
- Prefer current source and executable proof over issue comments. Treat stale comments, old CI, and old release behavior as hints until rechecked.
- avoid broad special cases, hidden migrations, semantic sentinels, and provider/channel IDs in generic core.
- Do not approve, comment, close, merge, push, or land unless the user asked for that action.

---
Generated by SkillMake from https://github.com/steipete/agent-scripts/tree/main/skills/github-deep-review on 2026-05-27T20:55:45.652Z.
Verify against source before relying on details.

File: ~/.claude/skills/github-deep-review/SKILL.md