skill-code-standards

Apply a language-agnostic standards method covering types, naming, error handling, and dependencies while letting each language's formatter, linter, and compiler own hard invariants. Inspect existing repository conventions first and never invent a new standard when one already exists.

Never swallow errors; catch specific failures only to add context, translate at boundaries, retry safely, or clean up. Preserve the original cause when wrapping, use native cleanup constructs for files, locks, and connections, and choose one ownership boundary for logging rather than logging at every layer.

Add a dependency only after exhausting simpler options: no new mechanism, existing repository helpers, standard library, native platform features, then already-installed dependencies. A new dependency is justified only when a maintained capability materially beats a small local implementation.

No. Formatters and linters own mechanical style, compilers and type checkers own executable type constraints, and tests own behavioral proof. This Skill owns only the implementation judgment between those controls and uses the project's configured tooling.

Skip when a formatter, generated-code owner, or narrow mechanical edit fully determines the result. Also avoid applying one language's naming convention everywhere or enforcing fixed function-length limits without evidence.