Use the engineering-principles skill for shared guidance on reasoning, expression, boundaries, and verification. The other pages in this section are supporting explanations, not additional skills to install.
Start with the concrete risk
A naming question, an unclear result, and a dependency cycle need different kinds of attention. Choose the layer that helps explain the actual change:
| Concern | Guide |
|---|---|
| A name hides intent, units, or side effects | Lexical expression |
| A caller cannot distinguish outcomes or follow control flow | Functions and control flow |
| Responsibilities or cleanup have no clear owner | Module boundaries |
| Dependencies make change or operation difficult | Architecture and evolution |
The four-layer guide explains how these questions connect. The Karpathy guidelines focus on working habits that keep a change bounded and checkable.
Turn a principle into useful feedback
Name the affected behavior or maintenance risk, point to evidence, and suggest the smallest correction. “This function has too many responsibilities” is less useful than explaining which independent reasons for change are entangled and what currently breaks because of that.
Apply existing project conventions where they serve the task. A principle should help resolve a concrete problem, not generate unrelated cleanup or a requirement to apply every pattern.
For a review verdict, use agent-code-reviewer. For a choice that changes the architecture, use senior mode.