review-all

Full Review

Orchestrate all domain-specific review skills as parallel subagents, then consolidate into a unified report.

Workflow

1. Scope and explore

• Confirm scope with the user: full codebase, specific packages/directories, changed files only (PR or branch diff), or specific concern.
• Resolve scope to a file/package list. Based on what the user requested:
  • Changed files (PR or branch): Run git diff --name-only --diff-filter=d <base>...HEAD to get changed files (default <base> is main). If the user references a PR number, use gh pr diff <number> --name-only instead. Derive affected Go packages from the file paths (unique parent directories containing .go files).
  • Explicit paths/packages: The user may specify directories (e.g. internal/auth/), Go package patterns (e.g. ./internal/auth/...), or individual files. When given a directory or package pattern, include all files under it. Derive Go package paths for static analysis tool invocations.
  • Full codebase: No filtering. Explore everything (default).
• Pass the resolved scope (file list, derived package paths, and file-type flags below) to each review subagent in step 3 so they skip their own scope confirmation and use the provided scope directly.
• Resolve pr_url for deep-linking (display-only, used in the final consolidated report). Run gh pr view --json url -q .url 2>/dev/null to capture the PR URL for the current branch (or for the PR number the user supplied via gh pr view <num> --json url -q .url). Empty string if no PR exists. Pass pr_url to each subagent in step 3 and to the summarization subagent in step 4. Subagents wrap finding path:line references using ~/.claude/scripts/pr-deeplink.sh "$pr_url" <path> <line>. See Finding link wrapping below.
• Classify the resolved files to determine which reviews to launch:
  • has_code: any source files (.go, .rs, .ts, .tsx, .js, .jsx, .swift, .kt, .kts, .py, .rb)
  • has_go: any .go files
  • has_proto: any .proto files
  • has_sql: any .sql files
  • has_iac: any Dockerfiles/Containerfiles, k8s manifests, Terraform (.tf/.tofu), Helm charts (Chart.yaml), service mesh / gateway CRDs (Linkerd/Istio/Gateway API/Ingress/Envoy bootstrap)
  • has_ci: any GitHub Actions workflows (.github/workflows/*.yml), composite actions (action.yml), Dependabot/Renovate configs, or CI configs (.circleci/config.yml, .buildkite/pipeline.yml, .gitlab-ci.yml, Jenkinsfile, azure-pipelines.yml, cloudbuild.yaml, bitbucket-pipelines.yml)
  • has_infra: shorthand for has_iac || has_ci (kept for backwards compatibility with existing review-* subagents)
  • has_api_specs: any .proto, OpenAPI/Swagger specs (openapi.{yml,yaml,json}, swagger.{yml,yaml,json}), or GraphQL schemas (*.graphql, *.gql)
  • has_docs: any .md files or OpenAPI/Swagger specs
  • has_manifest: any dependency manifest (go.mod, package.json, requirements.txt, pyproject.toml, Cargo.toml, Gemfile, mix.exs, composer.json)
  • has_changes: true when scope is "changed files (PR or branch)", or when scope is "explicit paths" and those paths have a diff against the base ref (run git diff --name-only --diff-filter=d <base>...HEAD -- <paths> to check; default base is main). False for full-codebase reviews with no diff baseline.
• Detect opt-in flags from the user's request phrasing:
  • include_performance: true when the user explicitly asks for performance, perf, benchmark, profiling, pprof, hot-path, or latency review alongside the comprehensive request. Default false. Never auto-enable from file types.
  • include_deep_security: true when the user explicitly asks for a deep / thorough security review, "CodeQL", "capability audit", "supply-chain audit", or otherwise signals willingness to pay the multi-minute cost of CodeQL database builds and capslock VTA. Default false. Standard review-security still runs without this flag; the flag only enables the deep static-analysis tier. Never auto-enable from file types.
• Determine which review types are applicable using the flags above:
  • review-security: applicable if has_code or has_infra
  • review-reliability: applicable if has_code or has_iac
  • review-code: applicable if has_code or has_proto
  • review-database: applicable if has_sql, or database-interacting code exists (check imports for DB drivers like pgx, pq, database/sql, sqlx, diesel, sqlalchemy, etc.)
  • review-coverage: applicable if has_go and has_changes
  • review-documentation: always applicable
  • review-infrastructure: applicable if has_iac
  • review-ci: applicable if has_ci
  • review-observability: applicable if has_code (observability gaps are code-level; configs alone aren't enough)
  • review-api-compat: applicable if has_api_specs AND has_changes (it's a diff-aware review; no diff baseline = nothing to compare)
  • review-performance: applicable ONLY if include_performance is true. Never auto-launched.
  • evaluate-dependency: applicable if has_manifest AND has_changes. Diff the manifest to find added or version-bumped dependencies (git diff <base>...HEAD -- <manifest>); run it in review mode once per added/bumped dependency. Skip when the only manifest change is a removal or a checksum-only lockfile churn.