القائمة
Analyze merged PR review comments to extract coding conventions and distill new CLAUDE.md guidelines. Use when you want to mine recent PRs for patterns not yet documented.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Debugging a ghostty crash
Drive a real browser during frontend work — verify a change rendered, click through a flow, fill forms, read console errors, take screenshots, or debug performance/memory/network. Use whenever interacting with a local web app in a browser (Playwright script templates, chrome-devtools tradeoffs, SPA mock-API gotchas).
How to use the tviz CLI to read and write Things 3 tasks
For non-Codex agents, get a Codex second opinion on your changes. Claude sends the diff to Codex for review, discusses the feedback, and synthesizes actionable results.
Productivity coach
Read Oxide RFD contents, metadata, and images by number using rfd-cli. Use when an RFD comes up (e.g. "RFD 63", "what does the networking RFD say") and you need the actual text.
| name | pr-lessons |
| description | Analyze merged PR review comments to extract coding conventions and distill new CLAUDE.md guidelines. Use when you want to mine recent PRs for patterns not yet documented. |
| allowed-tools | Bash, Read, Grep, Glob, Edit, Write, Task, WebFetch |
Analyze merged PRs for review comments requesting changes, then distill new guidelines for CLAUDE.md that aren't already covered. Start with enough PRs (~30-50 in a monorepo) to find 3-5 with relevant review comments, then expand until the signal thins out or enough patterns have been collected. In a monorepo, most PRs will be dependency bumps or touch unrelated components, so the initial pool needs to be larger than the number of PRs you actually want to analyze.
Expect a hit rate of ~15-20% of comment threads yielding generalizable conventions. This is normal — most threads are discussions, questions, or praise that don't produce CLAUDE.md guidelines.
List recent merged PRs, then check each for review comments and file relevance in a single pass. This avoids redundant API calls.
# List recent merged PRs (adjust --limit as needed)
gh pr list --state merged --limit 50 --json number,title
# Combined check: has review comments AND touches relevant files.
# In a monorepo, filter by subdirectory (e.g., nexus/, common/).
for pr in <numbers>; do
count=$(gh-api-read "repos/<owner>/<repo>/pulls/$pr/comments" | jq 'length')
[ "$count" -eq 0 ] && continue
relevant=$(gh-api-read "repos/<owner>/<repo>/pulls/$pr/files?per_page=100" \
| jq -r '.[].filename' \
| grep -cE '^<subdir>/' || true)
[ "$relevant" -eq 0 ] && continue
echo "PR #$pr: $count comments, $relevant relevant files"
done
Skip PRs that don't touch the target area — their review comments won't produce useful guidelines for the local CLAUDE.md.
For each relevant PR, fetch threaded review comments. Truncate diff_hunks to ~10 lines to control payload size — the hunks can be very large (60+ lines of endpoint definitions, schema changes, etc.) but usually only the first few lines provide enough context to understand the comment.
gh-api-read "repos/<owner>/<repo>/pulls/$pr/comments?per_page=100" \
| jq 'group_by(.in_reply_to_id // .id)
| map({
path: .[0].path,
diff_hunk: (.[0].diff_hunk | split("\n") | .[:10] | join("\n")),
messages: [.[] | {user: .user.login, body: .body}]
})'
This groups comments into conversation threads. The diff_hunk on the first
message gives the code context where the comment was placed.
If the diff_hunk isn't enough context (fallback, rarely needed), fetch the full diff filtered to only the commented files:
commented_files=$(gh-api-read "repos/<owner>/<repo>/pulls/$pr/comments" \
| jq -r '[.[].path] | unique[]')
gh pr diff $pr --repo <owner>/<repo> \
| awk -v files="$commented_files" '
BEGIN { split(files, arr, "\n"); for (i in arr) wanted[arr[i]]=1 }
/^diff --git/ { found=0; for (f in wanted) if (index($0, f)) found=1 }
found { print }'
If the diff_hunk and comment text aren't sufficient, use the local clone to see more surrounding code. This is rarely needed — the threaded comments plus truncated hunks are usually enough.
# See what the file looked like at the PR's base vs head
jj file show <path> -r <base-commit>
jj file show <path> -r <head-commit>
# Or use git if not using jj:
git show <commit>:<path>
# Browse the commit history of the PR branch
jj log -r '<base>::<head>'
This is useful when:
For each thread, classify it:
Focus on change requests and questions that reveal conventions.
For each actionable comment:
Group similar feedback across PRs into themes. Compare against existing CLAUDE.md to filter out:
Write new guidelines that are:
Before finalizing, spawn a subagent (via the Task tool) to critically evaluate the proposed guidelines. The subagent should receive only:
The subagent's job is to flag guidelines that should be dropped or reworked:
The subagent should return a filtered list: which guidelines to keep (and why they add value), which to cut, and any suggested rewording. Use its output to produce the final set of guidelines.
For small batches where the operator is reviewing the output manually, this step can be skipped.
The full diff of a PR can be very large. Strategies to manage: