clean-code

Clean Code

Config Resolution

Projects can customize this skill's standards. Resolution order:

1. Read .lattice/config.yaml in the repo root.
2. If found, check paths.clean_code for a custom document path.
3. If a custom document exists at that path, read it and check its YAML frontmatter for mode:
   • mode: override: the custom document has full precedence. Use it instead of the embedded defaults. It must be comprehensive -- treat it as the sole reference.
   • mode: overlay (or no mode field): read the embedded ./references/defaults.md first, then apply the custom document's sections on top. A custom section replaces the matching default section (matched by exact heading); new sections append after the defaults.
4. If a custom path is configured but no document exists at it → tell the user which configured path is missing, then fall back to ./references/defaults.md.
5. If there is no config file or no paths.clean_code key, read ./references/defaults.md.
6. Language adaptation: if paths.language_idioms is set in the config and the document exists, read it and adapt the defaults using these sections:
   • "Error Handling" → adapt §8 (Error Handling) patterns to the language's idioms. Language idioms take precedence over the pseudocode defaults.
   • "Type System & Object Model" → adapt §1 (Single Responsibility) cohesion guidance to the language's constructs (e.g., struct vs class).
   • "Naming Conventions" → adapt §4 (Meaningful Naming) patterns to the language's conventions.
   • "Parameter & Function Design" → adapt §2 (Small, Focused Functions) and §5 (Parameter Design) to the language's capabilities.
   • "Dependency Management" → adapt §9 (Test-Friendly Code) dependency-injection patterns to the language's idioms.

Self-Validation Checklist

STOP after generating each component. Verify ALL checks. Fix every failed check before presenting. Judgment calls → present options (see Ambiguity Signals).