Language Idiom Enforcement

language-idiom-enforcement

Registry Trigger

Use when

• language idioms error handling type modeling resource management module boundaries naming casing visibility exports public API naming predicate boolean names collection names concurrency formatting standard library hallucinated APIs non idiomatic code

Do not use when

• no task-local language idiom enforcement decision is required

Skill Role

Select language-native expressions that affect correctness, ownership, failure handling, public contracts, or maintainability. Exclude formatting-only enforcement, runtime selection, and performance proof.

High-Value Rules

• Start from current repository and language authority. Inspect nearby accepted code, configured compiler or linter rules, supported language version, public conventions, and framework constraints before proposing an idiom.
• Use types to make invalid states harder to represent. Prefer the language's established nullability, sum or sealed type, value object, ownership, result, and collection semantics when they clarify the task-local invariant.
• Preserve failure and resource semantics. Choose error propagation, wrapping, cleanup, cancellation, and lifetime patterns that retain actionable context without leaking resources or swallowing control flow.
• Respect concurrency conventions with semantic evidence. Match the runtime's synchronization, task, cancellation, and shared-state model; route measured scheduling or memory-safety questions to the performance-safety owner.
• Treat public naming and module shape as contracts. Check exported symbols, predicates, callbacks, generic constraints, extension points, serialization-visible names, and generated surfaces before normalizing style.
• Keep documentation syntax within its owner. Limit this Skill to repository-backed language syntax and public-surface requirements, leaving semantic-explanation decisions to code-clarity-maintainability.
• Justify deviations by constraint. Keep a non-idiomatic form only when compatibility, generated code, framework protocol, performance evidence, or repository policy requires it, and record the boundary that prevents normalization.
• Validate changed semantics, not stylistic conformity alone. Use compile, static analysis, focused tests, and public-surface comparison appropriate to the affected ownership, error, or API behavior.

Anti-Patterns

• Apply a generic language style guide over stronger repository, framework, generated-code, or compatibility evidence.
• Replace explicit domain meaning with clever syntax, compressed control flow, or an abstraction unfamiliar to the owning codebase.
• Label code non-idiomatic without naming the semantic risk, authoritative convention, and behavior-preserving alternative.

Stop Conditions

Escalate when repository and language authorities conflict, public compatibility is uncertain, or the proposed idiom changes ownership or concurrency behavior. Also escalate when generated or framework code controls the surface, or validation cannot distinguish style from semantic change.

Output Contract

• language-idiom decision with current authority, affected semantic boundary, chosen pattern, justified deviations, compatibility effects, and validation evidence

Targeted References