async-signal-safety-review

Scope is strict: async-signal-safety and crash-time correctness only. This is NOT a general PR review. You are not evaluating whether the PR should land, whether the design is good, whether doc comments read well, whether names are clear, whether tests exist, or whether refactors are worthwhile. You are answering exactly one question per changed line: does this break async-signal-safety on the signal-handler path? Do NOT include in the report: • Style, naming, readability, or refactor opinions. • Doc / comment wording suggestions, unless the comment makes a false claim about signal safety (e.g. says something is unsafe when it is, or vice versa). • DX concerns, API-shape feedback, "the author should clarify intent", "worth a second look" items that aren't concrete signal-safety issues. • Test coverage commentary. • Summaries of what the diff does beyond the one-line Scope. • Praise, "looks good", "nice refactor", or any editorial voice. If a concern is not "X calls a lock/alloc/ObjC from a signal-reachable path" or "a comment misstates signal safety", it does not belong in the output. When in doubt, cut it.

The authoritative rules live in .claude/rules/async-signal-safety.md. Read that file before every review — do not summarize or duplicate the rules here; they may have been updated since this skill was last edited. Apply all rules from that file as-is.

Whenever you're unsure whether a system function is async-signal-safe, do not guess — read the actual implementation. Full instructions for how to look up symbols, which Apple OSS repo owns which function, how to fetch source via gh, how to delegate lookups to parallel subagents, and a list of common findings are in apple-oss-reference.md. Read that file when you encounter a suspect system call.

Determine the review mode from the user's input: • PR number (e.g. #809, PR 809): fetch the PR diff with gh pr diff <number> and review only those changes. • Branch name: diff that branch against master and review only those changes. • File or module name (e.g. signal monitor, KSCrashMonitor_Signal.c, KSObjC): ambiguous — the user might mean the whole file or just changes to it. Ask: "Do you want me to review the entire file or only the changes on the current branch?" Do not guess. • No argument: default to current branch vs master — git merge-base HEAD master, then git diff <base>...HEAD. Only review files where async-signal-safety applies (the paths: list in .claude/rules/async-signal-safety.md). Ignore Swift modules, Filters, Sinks, Installations, sample app, and docs — mention that you skipped them once, then move on.