Make Your AI Assistant a LoT Expert
AI coding assistants — in Cursor, VS Code with Copilot, or Claude — can generate excellent LoT (Language of Things) code when they know your project’s conventions. The key is giving them the right context upfront through an AGENTS.md or project rules file.
This page shows you how to set up that context so your assistant produces LoT code that matches your team’s standards from the first prompt.
Like a style guide that your co-pilot actually reads. Just as a design system keeps a UI consistent across 10 developers, a project rules file keeps your LoT code consistent across humans and AI assistants alike.
When to Use This
- You want your AI assistant to generate correct LoT code without constant corrections
- You’re setting up an AGENTS.md,
.cursor/rules/, or CLAUDE.md file for your project
- You’re onboarding new team members (human or AI) and need a single reference
- You’re starting a new Coreflux project and want AI-ready conventions from day one
This page focuses on AI assistant configuration. For the underlying conventions, naming rules, topic architecture, code patterns, and anti-patterns, see the LoT Concepts page — those standards are the foundation for everything below.
In This Page
Setting Up Your AI Assistant
An AGENTS.md file (or equivalent project rules file) tells your AI assistant how to work with your Coreflux project. It prevents the assistant from generating code with wrong naming, invented syntax, or inconsistent patterns. The conventions defined in the LoT Concepts page form the content — the structure below tells you how to organize them for your assistant.
What Is an AGENTS.md?
An AGENTS.md is a markdown file in your project root that AI coding assistants read automatically. It works across tools:
| File / Location | Supported By |
|---|
AGENTS.md (project root) | Cursor, GitHub Copilot, OpenAI Codex, Google Jules, Aider |
.cursor/rules/*.mdc | Cursor (native format with glob pattern support) |
CLAUDE.md (project root) | Claude Code |
.github/copilot-instructions.md | GitHub Copilot |
For maximum compatibility, use AGENTS.md in your project root. If you use Cursor extensively, you can also maintain .cursor/rules/ files for features like auto-attaching rules to specific file types.
The Three-Tier Boundary System
The most effective structure for preventing AI mistakes is a three-tier permission system. Define what the assistant should always do, what it should ask about first, and what it should never do:
| Tier | Guideline | LoT Examples |
|---|
| Always do | Follow without asking | Use PascalCase for entities, snake_case for variables, lot language tag for code blocks |
| Ask first | Confirm before proceeding | Adding new Routes (external connections), modifying Rules (access control), removing Actions |
| Never do | Refuse even if asked | Invent LoT syntax that doesn’t exist, use LOT or lot capitalization, mention competitor broker products |
Starter Template
The following template incorporates the conventions from the LoT Concepts page. Copy it into an AGENTS.md file at your project root and customize the project-specific sections:
Prefer to grab it from GitHub? The Coreflux AI Starter repository has ready-to-use templates (minimal, full, and industrial), pre-built MCP configs for every editor, and filled-in examples you can clone directly.
AGENTS.md
Cursor Rules (.mdc)
A cross-platform template that works with Cursor, Copilot, Claude, and other AI tools:# AGENTS.md
## Project Overview
This is a Coreflux LoT (Language of Things) project for [describe your system].
Built on the Coreflux MQTT broker with LoT Actions, Models, Rules, and Routes.
## Tech Stack
- **Platform:** Coreflux MQTT Broker
- **Language:** LoT (Language of Things)
- **Extensions:** Python integration (for complex logic only)
- **IDE:** VS Code with LoT Notebooks extension / Cursor
## LoT Naming Conventions
- **Actions:** PascalCase, verb-first (ProcessTemperature, MonitorPressure)
- **Models:** PascalCase, noun-based (SensorReading, EquipmentStatus)
- **Rules:** PascalCase, descriptive scope (AllowAdminActions, ProtectSysTopics)
- **Routes:** PascalCase, destination-based (CloudBridge, SensorDatabase)
- **Variables:** snake_case in quotes ("sensor_id", "raw_value")
- **Topics:** lowercase/slash-separated (sensors/+/temperature, alerts/critical/+)
- **Model fields:** snake_case ("equipment_id", "runtime_hours")
## Topic Hierarchy
- sensors/ — Raw incoming data
- processed/ — Transformed data
- alerts/ — Threshold violations
- config/ — Configuration values
- state/ — Internal persistent state (KEEP TOPIC)
- cache/ — Cached values
- system/ — Heartbeats and diagnostics
- commands/ — Inbound instructions
## Code Standards
- Always type-cast in calculations: PAYLOAD AS DOUBLE, GET TOPIC ... AS DOUBLE
- Use KEEP TOPIC for internal state, PUBLISH TOPIC for external broadcast
- Mark the primary data field AS TRIGGER in models — never timestamps
- Use COLLAPSED models when Actions need control over publish timing
- Break complex Actions into callable Actions with INPUT/OUTPUT
- Use LoT for publish, subscribe, conditionals, math — Python only for
ML, complex parsing, or external library calls
## Do
- Always respect the indentation of 4 spaces per additional level
- Use PascalCase for all entity names
- Use snake_case for all variables and model fields
- Add type casts to every numeric operation
- Use descriptive names that explain purpose
- Use lot as the code block language identifier
- Booleans and integers do not use quotes
- Consult the Coreflux MCP for documentation when unsure
- Routes that call functions from other protocols (like SQL queries) are not limited to the functionalities listed in this documentation, the full range of that external element is usually functional
## Don't
- Do not invent LoT syntax — only use documented keywords
- Do not use LOT (all caps) or lot (lowercase) — always LoT
- Do not mention competitor products (Mosquitto, HiveMQ, etc.)
- Do not trigger models on timestamp fields
- Do not use PUBLISH for internal-only state
- Do not create monolithic Actions — split into callables
## Ask First
- Before adding or modifying Routes (external system connections)
- Before modifying Rules (access control changes)
- Before removing any existing Action, Model, Rule, or Route
- Before using Python — confirm LoT can't handle it natively first
## Never
- Never hardcode credentials in Route definitions for production
- Never leave $SYS/# topics unrestricted
- Never skip type casting in mathematical operations
- Never generate LoT syntax you haven't verified in the documentation
For Cursor-native rules, create .cursor/rules/lot-conventions.mdc in your project:---
description: LoT development conventions for Coreflux projects
globs: ["*.lot", "*.lotnb", "*.md"]
---
# LoT Conventions
You are an expert LoT (Language of Things) developer for Coreflux.
## Naming
- Actions: PascalCase, verb-first (ProcessTemperature)
- Models: PascalCase, noun-based (SensorReading)
- Rules: PascalCase, descriptive (ProtectSysTopics)
- Routes: PascalCase, destination-based (CloudBridge)
- Variables: snake_case in quotes ("sensor_id")
- Topics: lowercase/slash-separated (sensors/+/temperature)
## Code Rules
- Always type-cast: PAYLOAD AS DOUBLE, GET TOPIC ... AS DOUBLE
- KEEP TOPIC for internal state, PUBLISH TOPIC for broadcast
- AS TRIGGER on primary data field, never timestamps
- Use COLLAPSED models when Actions control publish timing
- Use lot as the language tag for code blocks
- Python only for ML, complex parsing, or external libraries
## Prohibited
- Do not invent LoT syntax beyond documented keywords
- Do not use LOT or lot — always LoT
- Do not mention competitor MQTT brokers
- Do not create monolithic Actions — split into callables
Keeping It Effective
The best project rules files share these qualities:
| Quality | Why It Matters |
|---|
| Specific | ”Use PascalCase for Actions” beats “use good naming” |
| Example-driven | One code snippet beats three paragraphs of description |
| Iterative | Start small, then add rules when you see the AI make a mistake |
| Current | Update the file as your project conventions evolve |
| Concise | A 50-line focused file outperforms a 500-line generic one |
Do not include credentials, API keys, or sensitive connection strings in your AGENTS.md or rules files. These files are typically committed to version control.
Quick Reference Checklist
Use this checklist when reviewing LoT code — whether written by you or generated by an AI assistant:
Next Steps