Skip to main content

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 / LocationSupported By
AGENTS.md (project root)Cursor, GitHub Copilot, OpenAI Codex, Google Jules, Aider
.cursor/rules/*.mdcCursor (native format with glob pattern support)
CLAUDE.md (project root)Claude Code
.github/copilot-instructions.mdGitHub 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:
TierGuidelineLoT Examples
Always doFollow without askingUse PascalCase for entities, snake_case for variables, lot language tag for code blocks
Ask firstConfirm before proceedingAdding new Routes (external connections), modifying Rules (access control), removing Actions
Never doRefuse even if askedInvent 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.
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

Keeping It Effective

The best project rules files share these qualities:
QualityWhy It Matters
Specific”Use PascalCase for Actions” beats “use good naming”
Example-drivenOne code snippet beats three paragraphs of description
IterativeStart small, then add rules when you see the AI make a mistake
CurrentUpdate the file as your project conventions evolve
ConciseA 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:
  • All entity names are PascalCase and descriptive
  • All variables and model fields are snake_case
  • All topics are lowercase with slash separators
  • All numeric operations include explicit type casts (AS DOUBLE, AS INT)
  • Models trigger on primary data fields, not timestamps
  • Internal state uses KEEP TOPIC, not PUBLISH TOPIC
  • Complex logic is split into callable Actions with INPUT/OUTPUT
  • Rules use permission tags (USER HAS) over user names (USER IS)
  • Python is used only where LoT can’t handle the task natively
  • $SYS/# topics are protected by a high-priority Rule

Next Steps