--- name: python-production-review description: "Perform a broad Python production audit, or reconcile specialist evidence and remaining integration risks." --- # Python Production Review Perform a production-readiness review without repeating focused specialist passes. Use orchestrated mode for final residual synthesis and standalone mode when this skill is invoked directly for a broad Python review. ## Choose The Mode ### Orchestrated Mode Use when `review-graph` or `python-review-orchestrator` supplies accepted focused review evidence. - Do not load the standalone checklist in orchestrated mode. - In a `review-graph` synthesis node, use this skill, the supplied handoff, and accepted evidence only. Report missing integration evidence to the coordinator; do not start a new source review. - Treat specialist findings and validation as established evidence. - Inspect cross-cutting integration and concerns that remain genuinely unowned. - Do not repeat API design, parsing, CLI, scientific, notebook, support-tooling, packaging, or test checklists. - In a `review-graph` synthesis node, remain read-only and evidence-only. Do not edit, run validators, route work, load another review skill, or create subagents. Return missing or stale validation as an exact blocker for the coordinator. - Consume the compiler-produced compact `SynthesisBundle`; do not request or load complete predecessor artifacts. ### Standalone Mode Use when invoked directly for a broad production review or when no focused orchestrator ran. - Read [`references/standalone-review.md`](references/standalone-review.md). - Select only checklist sections that match the changed surface. - Bring in focused skills when a concern requires their deeper workflow. ## Ownership Boundaries Route primary ownership as follows: - packaging, built artifacts, install behavior, runtime matrices, extras, and entry points: `python-build-portability` - public and materially shared API concepts, signatures, typing, and compatible evolution: `python-api-design` - user-facing CLI and application behavior: `python-cli-review` - invariant-bearing input parsing and domain models: `python-parse-dont-validate` - mathematical and numerical validity: `python-scientific-review` - development, release, benchmark, fixture, and CI scripts: `python-support-scripts` - notebook structure and reproducibility: `jupyter-notebook-review` - test design and durable evidence: `python-test-quality` - workflow mechanics, validators, and tool versions: `project-tooling-review` Retain final responsibility for integration among those surfaces and for ordinary reusable Python modules that match none of them. ## Residual Review For standalone and non-graph orchestration, inspect the relevant contracts below. Graph synthesis evaluates only accepted evidence for those concerns. ### Public And Cross-Module Contracts Use `python-api-design` for material public or cross-module interface changes. Reconcile its caller contracts with parsing, installed imports, runtime effects, and exception/resource behavior; do not repeat the API checklist when focused evidence is available. Retain ordinary runtime correctness for reusable modules with no narrower owner. When annotation evaluation or the Python floor changes, read [annotation compatibility](../python-build-portability/references/annotation-compatibility.md). ### Correctness And State Trace important operations from accepted input to committed result. Check coordinated mutation, cache/index coherence, idempotence, retries, partial failures, and observable post-error state. Prefer building a valid replacement before publishing it when multiple values must change together. Use the parsing specialist for construction-time domain invariants; retain multi-component lifecycle and integration behavior here when no narrower state specialist applies. ### Exceptions And Diagnostics Check that callers can distinguish actionable failure categories, exceptions preserve useful context and causal chains, cleanup does not hide the original failure, and normal user or data errors do not leak irrelevant implementation tracebacks. Avoid broad exception swallowing, exception-driven control flow across large regions, and `assert` for runtime validation. ### Resource And Lifetime Contracts Check files, sockets, subprocesses, temporary paths, database connections, locks, generators, iterators, context managers, callbacks, and background work for deterministic cleanup. Trace early returns, exceptions, cancellation, partial iteration, and interpreter shutdown where relevant. Flag resources whose ownership is unclear, generators that defer required cleanup without a documented close path, callbacks retaining objects unexpectedly, and import-time acquisition of external resources. ### Async And Concurrency When async, threads, processes, signals, or callbacks are present, check cancellation, task ownership, shutdown, blocking calls in async contexts, race-prone shared state, lock scope, queue backpressure, exception propagation, and deterministic testing. Recommend a dedicated specialist only when this surface grows enough to justify one. ### Security And Privacy Check unsafe deserialization, shell construction, path traversal, broad deletion, temporary-file exposure, secret logging, private-record output, dynamic imports, and trust placed in environment variables or external metadata. Keep findings tied to reachable behavior rather than generic hardening advice. ### Integration And Simplification Reconcile contracts across modules, installed entry points, generated artifacts, documentation examples, and external consumers. Look for duplicated adapters, obsolete compatibility layers, redundant wrappers, or abstractions that make invariants harder to see. Recommend deletion only when callers and validation evidence support it. ## Final Validation Apply one validation ledger in all execution modes, keyed by source/environment state, built artifact and installation-target identity, Python/platform/dependency configuration, instrumentation, and exact validator or test selection. In graph synthesis mode, consume the accepted parent ledger without running or adding validators; return uncovered integration requirements to the coordinator as blockers. In standalone mode, create the ledger, reuse matching evidence, and add validation only for an uncovered integration path. In non-graph orchestrated mode, consume the parent ledger and follow its validation workflow for uncovered evidence. Rerun only after a relevant change invalidates the result, for a materially different configuration, or for explicit nondeterminism diagnosis. Do not run full CI solely because this is the final pass; follow repository requirements and escalate only when narrower non-overlapping coverage is insufficient. Key platform entries by the actual executor and distinguish native runs from focused emulation. Emulated boundary coverage cannot satisfy a native platform configuration, and unexecuted matrix cells remain limitations. If available native CI for the same source state fails after local or modeled checks passed, preserve the contradiction as a readiness blocker until the defect is fixed and current native evidence is reconciled. ## Output In orchestrated mode, synthesize specialist outcomes, remove duplicate findings, identify cross-cutting blockers, and name residual risk. In standalone mode, lead with findings ordered by severity and list focused skills or checklist sections used. Always report validation performed, reused ledger evidence, and meaningful limitations. In a `review-graph` synthesis node, use the dispatched [SynthesisPayload schema](../review-graph/references/schemas/synthesis-payload-v1.schema.json). Return `readiness_verdict`: `ready` when required evidence reconciles and no actionable finding remains, `not-ready` when findings remain, or `blocked` when required evidence or routing is incomplete. Put exact reasons in `verdict_reasons`; preserve finding ownership, dispositions, and source-finding references, predecessor coverage, routing closure, validation results, and cross-surface risks in their dedicated fields. A completed review and passing validators do not imply repository readiness. Review outcomes: [typed contract](../review-graph/references/typed-results.md); read on rejection. Missing evidence stays blocked.