reviewing-codelisted

# Reviewing Code Produce a PR review optimized for posting as a single GitHub comment. The review applies a security lens, a comprehension audit, and a structural check, then labels findings by severity with a copy-paste-safe action checklist. ## Read first (always) List `learnings/` and read every file relevant to the current PR (the touched modules, frameworks, or risk areas). Project-specific review conventions, severity adjustments, banned patterns, or scope rules live there and override the defaults in this SKILL.md. If a learning conflicts with this file, **the learning wins** — mention it to the user. ## Tradeoff — when to apply, when to lighten up Apply the full discipline (security lens + comprehension audit + checklist + grep) for **production-bound PRs** touching shared services, payments, auth, user data, AI runtime, or anything externally observable. Lighten formality for: docs-only changes, lockfile bumps with no API change, single-line typo fixes, internal-tooling-only changes behind a feature flag not yet enabled. Still apply the security lens — even doc PRs can leak secrets in examples. ## Hard rules — output is a chat message, not a side effect The review is a chat message the human copies and posts. It is never a side effect: - **Never** run `gh pr review`, `gh pr comment`, or any GitHub-mutating command. The user posts the review themselves. - **Never** run `git commit`, `git add`, `git push`. Only the human commits. - **Never** write the review t