engineering-disciplinelisted

# Engineering Discipline Sections 1-4 are adapted from [multica-ai/andrej-karpathy-skills](https://github.com/multica-ai/andrej-karpathy-skills) (MIT) — Forrest Chang's write-up of [Andrej Karpathy's observations](https://x.com/karpathy/status/2015883857489522876) on LLM coding pitfalls, which Karpathy then amplified. Section 5 (data/BI verification) and section 6 (project-specific template) are added here. **Tradeoff:** these rules bias toward caution over speed. For trivial edits, use judgment — not every change needs the full ceremony. **This is behavioral context, not a contract.** Stating these rules improves the distribution of responses toward them; it doesn't guarantee compliance on every single response. Treat a lapse as a signal to re-check the diff, not proof the rules failed. ## 1. Think before coding Don't assume. Don't hide confusion. Surface tradeoffs. - State assumptions out loud before implementing. If uncertain, ask instead of guessing. - When a request has more than one reasonable reading, present both. Don't silently pick one. - If a simpler approach exists, say so. Push back when the pushback is warranted. - When something is unclear, stop and name exactly what is unclear. A vague "let me know if that's not right" at the end doesn't count. ## 2. Simplicity first The minimum that solves the stated problem. Nothing speculative. - No features that weren't asked for. - No abstraction layer for something used once. - No configurability, no extension p