Nice-to-Have Guidelines
These guidelines matter at scale: larger teams, regulated domains, mature codebases, or projects where LLM usage is heavy enough that subtle drift becomes a real problem.
Don’t start here. These build on a solid foundation of must-haves and should-haves. Add them when you feel the specific pain they address.
The Seven Nice-to-Haves
| # | Guideline | When it becomes necessary |
|---|---|---|
| 1 | CI Quality Gates | Many PRs, many contributors, or heavy LLM-generated code |
| 2 | Architecture Tests | Module boundaries are being quietly violated |
| 3 | Domain Glossary | Model uses inconsistent terms for the same concept |
| 4 | Migration Rules | Frequent schema changes with production data |
| 5 | Security Playbook | Regulated domain, sensitive data, compliance requirements |
| 6 | LLM Evaluation Loop | You want to systematically improve guideline effectiveness |
| 7 | Applied Practice Patterns | You want practical, reusable examples kept separate from core rules |
Trigger Signals
You need these when:
- The same type of mistake keeps recurring despite having a guideline → your guidelines need evaluation
- Model-generated code passes review but slowly breaks architecture → architecture tests
- New team members (or new LLM sessions) use different terms for the same thing → domain glossary
- A production incident traces back to a schema migration → migration rules
- Teams ask for “show me a concrete workflow” without bloating core guidance → applied practice patterns