production-code-quality

name	production-code-quality
description	Apply language- and platform-specific engineering rules to retained source code being created or changed. Use for implementation quality and configured gates; skip review-only work, disposable experiments, and generated or vendored code.

Production Code Quality

1. Establish the changed surface before choosing conventions. Inspect only the repository instructions, source and tests, nearby patterns, manifests and lockfiles, target configuration, and formatter, analyzer, compiler, or test settings that can affect the in-scope code. Identify only the language, framework, runtime, platform, and tool versions that affect that surface; do not inventory unrelated packages or subprojects.
2. For every language with added or modified retained source, read its applicable language reference: Python, TypeScript and JavaScript, Go, Rust, Java and Kotlin, .NET, C and C++, or Swift. Read other languages and current official documentation for each unlisted affected language. Do not load guides for languages outside the changed surface.
3. Assess the local quality baseline before preserving conventions. Keep compatible, deliberate conventions, but do not reproduce unsafe, obsolete, inconsistent, or unmaintainable patterns. In a low-quality codebase, make new code and each touched responsibility a clean local precedent. Improve adjacent code only when correctness, cohesion, or reliable verification requires it. Preserve behavior and compatibility, keep the diff bounded, and expand into unrelated debt only with explicit approval. For a new project, select maintained stable tooling and official defaults for the target environment.
4. For a poorly understood or legacy area, read legacy-change before changing behavior. Establish a characterization baseline and a testable seam when needed.
5. Design precise names, cohesive units, explicit contracts and ownership, simple control flow, deliberate error handling, minimal dependencies, and the smallest public surface. Introduce a pattern only for a concrete force it resolves. Treat size as a design signal, not a universal line limit. Split code when responsibilities, reasons to change, branching complexity, reviewability, or testability demand it; obey configured numeric limits when present.
6. Read security only when the change creates, crosses, or alters one of these: a trust boundary; authentication, authorization, or permissions; secrets; sensitive data; untrusted input; output encoding or rendering; files or archives; processes or commands; cryptography; dependencies; or build, release, and deployment handling. Read testing when selecting or changing test strategy. Read compatibility when changing a public API, library, protocol, schema, persisted format, event, command line, configuration, deployment contract, or supported environment. Use a specialized process only when its own trigger applies; this skill does not require other skills.
7. Implement completely, then run the configured formatting, analysis, compilation, tests, build, and relevant runtime checks. Use sources when a durable engineering source is needed to guide a trade-off or substantiate a recommendation.

Finish when changed code meets the configured project rules and applicable current language guidance in proportion to its risk, every changed contract is verified, and no material quality gate remains unrun without an explicit reason. Report legacy constraints that prevent the touched area from meeting that bar.