Three-Tier Model
Not all guidelines carry equal weight. Some prevent real breakage. Others improve consistency. A few only matter at scale. Treating them all as equally urgent leads to either paralysis (too much to write) or a bloated guidelines file that the model can’t reliably follow.
guide-LLiMes organizes guidelines into three tiers based on a single question: “If we skip this, what breaks?”
The Tiers
Must-Have — Prevent breakage
These are non-negotiable. Without them, the LLM will produce code that fundamentally doesn’t fit your project.
| Guideline | What breaks without it |
|---|---|
| Project Scope | Model invents features outside your domain |
| Tech Stack | Model suggests wrong languages, frameworks, libraries |
| Coding Standards | Every generation looks different, diffs are noisy |
| Testing Strategy | Model skips tests or writes wrong types |
| Directory Structure | Files land in wrong places, imports break |
| API Contracts | Model breaks public interfaces, ignores versioning |
| Security Basics | Model logs secrets, bypasses auth |
| LLM Guardrails | Model modifies migrations, CI configs, infra |
When to write: Stage 1. Pick at least 3 that matter most for your project.
Should-Have — Reduce variance
These make LLM output more predictable and reviewable. The model can produce working code without them, but the quality and consistency will fluctuate.
| Guideline | What improves with it |
|---|---|
| Spec Templates | Prompts become consistent, nothing gets forgotten |
| ADRs | Model understands why things are the way they are |
| Review Guidelines | Reviews are faster, expectations are clear |
| Error Handling | Errors are typed, logged, and handled uniformly |
| Performance Expectations | Model considers scale, doesn’t write naive implementations |
| Test Data Conventions | Tests are isolated, reproducible, not flaky |
| Documentation Structure | Docs go in the right place, stay findable |
When to write: Within the first month. Prioritize based on where you see the most variance in LLM output.
Nice-to-Have — Scale and compliance
These matter when your team grows, your domain is regulated, or you want to prevent long-term architecture drift.
| Guideline | When it becomes necessary |
|---|---|
| CI Quality Gates | Team > 3 people, or many LLM-generated PRs |
| Architecture Tests | Module boundaries are being quietly violated |
| Domain Glossary | Model invents conflicting terms for the same concept |
| Migration Rules | Schema changes are frequent and risky |
| Security Playbook | Domain handles sensitive data or is regulated |
| LLM Evaluation Loop | You want to systematically improve guideline effectiveness |
When to write: First quarter onward, driven by actual pain points.
How to Use This Model
- Start with must-haves. Pick the 3 that address your biggest pain points. Write them. Use them for a week.
- Observe what goes wrong. If the LLM keeps making the same type of mistake, there’s a missing guideline for it.
- Promote as needed. Something you thought was “nice-to-have” might turn out to be a must-have for your project. The tiers are starting points, not fixed categories.
- Don’t write everything at once. A guidelines file with 50 rules that you wrote in one sitting is almost certainly too broad, too shallow, or both.
Tier Boundaries Are Project-Specific
A healthcare startup handling patient data will need Security Basics as a deep, detailed must-have from day one. A weekend side project might skip it entirely.
A team building a public API will treat API Contracts as critical. An internal tool with no external consumers might keep it minimal.
Use the tiers as a framework for thinking about priority, not as universal truth.
Next: Token Budgets — why your guidelines can’t be infinitely long.