Polyglot Production Code

Use this skill to make production changes in a supported language without imposing an alien house style. It is self-contained: inspect the target repository first, then apply the relevant defaults below only where the repository's own configuration is silent.

When to Use

• Adding, changing, reviewing, or repairing code in Python, JavaScript/TypeScript, Go, Rust, Java, Kotlin, C#, C, C++, Swift, Ruby, PHP, or Scala.
• Establishing a minimal production quality gate in a repository that lacks one.
• Reviewing whether a change follows its language's established naming, error, testing, API, and tooling conventions.

Do not use to reformat unrelated code, replace a documented local style, or transplant rules from one language ecosystem into another.

Prerequisites

1. Identify the language version, build tool, package/dependency manifest, formatter, linter/analyzer, type checker, test runner, and CI workflow.
2. Read repository instructions and inspect adjacent production code, tests, and recent similar changes.
3. Classify the change: feature, defect repair, refactor, contract change, migration, or dependency update.
4. Name the observable behavior and the narrowest relevant checks before editing.

Completion: local authority and the change's verification target are known before implementation begins.

Procedure

1. Honor local authority. Use committed formatter, linter, type policy, language version, dependency policy, and CI commands before applying the defaults below.
   • Completion: the change follows existing configuration or records why a missing configuration needs a declared baseline.
2. Preserve native structure. Match the ecosystem's package, module, crate, namespace, header, or source-set conventions. Keep every changed unit cohesive.
   • Completion: imports/includes, public boundaries, and source/test layout match the repository pattern.
3. Make contracts explicit. Use the language's natural types, schemas, doc comments, headers, and error mechanisms to state caller-relevant inputs, outputs, failure modes, ownership, lifecycle, concurrency, or nullability.
   • Completion: a caller can use the changed interface without reading implementation internals.
4. Choose recoverable failure paths deliberately. Do not use a panic, assertion, exception, or process exit for an ordinary user-triggerable condition when the language has an explicit recoverable mechanism.
   • Completion: failure behavior is diagnosable, preserves material cause/context, and has tests where it is material.
5. Use the native quality loop. Run the configured formatter, static analysis, focused tests, relevant integration/contract tests, and build or documentation checks.
   • Completion: actual command results are recorded; failed checks are not concealed.
6. Avoid mechanical churn. Do not combine a feature or repair with unrelated formatting, import-order, or style edits.
   • Completion: the diff is behaviorally focused and reviewable.

Language Defaults

Python

• Use four spaces; modules/functions/values are snake_case; classes are CapWords; failure exception classes end in Error.
• Keep modules focused. Prefer absolute imports; use explicit relative imports only when they materially clarify package locality.
• Type public functions and cross-module boundaries. Treat the repository's strict type check as a quality gate, not decorative documentation.
• Configure format, lint, type, tests, coverage, and dependencies coherently, ordinarily in pyproject.toml when supported.
• Keep tests discoverable in an explicit test tree; add regression tests for defects and relevant failure behavior.
• Raise specific errors and use named loggers for production diagnostics rather than print.
• Document public and non-obvious APIs; use schemas and signatures as the canonical contract where possible.

JavaScript and TypeScript

• Run one committed formatter configuration. Do not hand-tune whitespace against its output.
• Use UpperCamelCase for types, classes, interfaces, enums, and decorators; use lowerCamelCase for values, parameters, functions, methods, properties, and modules.
• Keep modules focused and imports explicit when named imports improve clarity.
• Validate network, file, environment, and user input at runtime boundaries. TypeScript declarations do not validate untrusted runtime data.
• Use purpose-built Error subclasses when the domain needs them; preserve cause and context and test failure behavior.
• Use JSDoc for exported or non-obvious APIs. Let TypeScript declarations carry routine type details.
• Keep unit, integration/end-to-end, type-check, and build commands independently runnable.

Go

• Run gofmt or go fmt for changed packages and goimports when imports change. Do not hand-format against them.
• Use short, clear package names; avoid repeating the package name in exported identifiers; preserve standard initialisms such as URL, HTTP, and ID.
• Keep packages cohesive and public APIs small. Pass context.Context as the first parameter for request-scoped cancellation, deadlines, authorization, or tracing. Do not store it in a struct.
• Return and handle errors. Do not panic for normal operational failures. Wrap errors with operation context while preserving errors.Is/errors.As inspection.
• Document every exported package, type, function, method, and sentinel error with identifier-leading comments.
• Keep *_test.go tests with the package, cover success/failure/edge cases, and use race detection for concurrent code.
• Run go test ./..., go vet ./..., formatting/import checks, and intentional module-hygiene checks.

Rust

• Use default rustfmt output and enforce cargo fmt --check. Do not customize formatting without a repository reason.
• Use snake_case for modules, functions, methods, and locals; UpperCamelCase for types, traits, and enum variants; SCREAMING_SNAKE_CASE for constants/statics.
• Use as_ for cheap borrowed views, to_ for potentially costly conversions, and into_ for ownership-consuming conversions.
• Organize focused modules/crates and expose an intentional public API. Prefer standard traits and conversions before bespoke wrappers.
• Use Result<T, E> for recoverable failure; reserve panic! for violated invariants. Do not use production unwrap or expect unless impossibility is explicit and justified.
• Document public APIs with examples and material # Errors, # Panics, or safety sections. Keep unit tests near source and integration tests in tests/.
• Run cargo fmt --check, configured Clippy checks, cargo test, and relevant documentation checks.

Java, Kotlin, and C#

• Use the committed formatter/analyzer and build wrapper. Keep packages/namespaces/source sets and test projects aligned with production structure.
• Java: use UpperCamelCase types, lowerCamelCase methods/fields, UPPER_SNAKE_CASE constants, no wildcard imports, deliberate exception wrapping, and Javadoc for material public/protected contracts.
• Kotlin: use UpperCamelCase types/files and lowerCamelCase functions/properties; favor nullability and sealed/result-style outcomes for expected states; do not use !! as routine control flow; use KDoc for non-obvious public contracts.
• C#: version .editorconfig; use PascalCase types/members, camelCase locals/parameters, I-prefixed interfaces, and Async-suffixed asynchronous methods. Catch only to recover, preserve stacks with throw;, and use XML docs for public API where material.
• Keep unit tests deterministic and infrastructure-free; separate integration tests. Run the normal Maven/Gradle or dotnet test lifecycle with the project analyzers.

C and C++

• Match local formatter and language baseline first. Do not mix styles or make format-only churn.
• C: use descriptive lower_snake_case; reserve uppercase for macros and enum constants. Keep public headers self-sufficient and document ownership, input constraints, output validity, and explicit failure states. Use location-aware diagnostics where relevant.
• C++: keep include dependencies explicit; make ownership and lifetime visible with RAII and appropriate smart pointers. Choose and document the exception policy. Assertions are for internal invariant failures, not user-triggerable failure.
• Explain contracts and rationale, not syntax. Put API-use comments at declarations and implementation rationale at definitions.
• Use build-system test targets and explicit compiler warnings. Run sanitizer, fuzz, coverage, and pedantic configurations when supported and relevant.

Swift, Ruby, PHP, and Scala

• Swift: optimize APIs for call-site clarity with precise labels and domain terms; document public declarations concisely; use typed errors and committed swift-format configuration with corresponding test targets.
• Ruby: use snake_case methods/values/files, CamelCase classes/modules, ? predicates, and ! only for dangerous or raising counterparts. Align files and constants, rescue narrowly, use RDoc for material public API, and enforce the committed RuboCop/test commands.
• PHP: use LF, four spaces, explicit visibility, namespaces/imports, PascalCase classes, camelCase methods, and cohesive files. Enable strict types in new code unless compatibility says otherwise. Use strict test assertions and static analysis; catch Throwable subclasses narrowly with preserved context.
• Scala: commit and use scalafmt; package by domain; avoid null; use Option for absence, Either for expected domain failure, and Try at exception-wrapping boundaries. Use Scaladoc for material public APIs and run the configured sbt test/format/lint checks.

Pitfalls

• Universal-style fantasy: A generic default never overrides an established repository convention.
• Formatter warfare: Do not manually undo the formatter or merge format-only changes into behavioral work.
• Type-only trust: Static types do not validate external runtime data.
• Exception misuse: Do not make routine user-triggerable failure fatal when an explicit recoverable path exists.
• Documentation theater: Public documentation explains contract and failure behavior, not line-by-line implementation.
• Test monoculture: Unit tests alone may not protect builds, type checks, integrations, concurrency, sanitizers, or generated documentation.
• Dependency drift: Do not introduce a formatter, linter, framework, or runtime merely because this skill mentions it; use the project's current toolchain unless change scope authorizes adoption.

Verification

Before reporting completion, verify that:

• local language/tooling configuration and adjacent code were inspected;
• changed code follows local conventions or an explicitly declared language baseline;
• public contracts and recoverable error paths are appropriate to the language;
• relevant formatting, static analysis, build, and test commands ran with actual results; and
• the final diff contains no unrelated style churn.