Code Discipline

Use this skill whenever a task involves adding or modifying logic, helper sprawl, unnecessary wrappers, duplicate utilities, duplicate constants, abstraction bloat, god files, schema boundaries, class-vs-composition choices, arrow-vs-declaration decisions, object-vs-positional parameter decisions, or security/maintainability hardening.

This is an anti-laziness skill. It prevents agents from "solving" tasks by inventing new files, helpers, and indirection when existing primitives already solve the problem. If a feature reveals a better boundary, refactor to it now when the change stays within current task scope and is justified by the Admission Gate below.

Default assumption:

• The user wants maintainable code with minimal abstraction surface area. When the feature exposes a clearly better boundary, take it now instead of preserving an inferior shape for diff size alone, including cases where short-term surface area increases are required to reduce long-term complexity and are justified by the Admission Gate.
• The user does not want renamed duplicates of existing behavior. Apply the same discipline to ORM schema boundaries, class inheritance, function signatures, and security-sensitive decisions.
• New helpers, wrappers, constants modules, and style-only indirection are disallowed unless justified by clear architectural value.
• These rules apply to abstractions, helpers, utilities, and indirection layers. New first-class domain files (for example, route handlers, entities, page components, test files) are governed by repo-standards-enforcement, not by the Admission Gate. Do not apply the Admission Gate to files whose primary purpose is domain logic rather than shared infrastructure.

When to Use

Invoke this skill for: