AI-Assisted Development Best Practices

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 Naming conventions, Working with JSON, Designing your data layer, and Anti-patterns — those standards are the foundation for everything below.

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 Naming conventions 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 Naming conventions and related pattern pages. 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

Coreflux MCP

Connect your AI assistant to the Coreflux documentation for real-time syntax help and guided answers.

Working with JSON

GET JSON patterns and structured output with Models.

Last modified on May 22, 2026

Developing with LoT Using AI How to Use a LoT Notebook

⌘I

Quick Start

Developing and Managing Coreflux

Coreflux MQTT Broker

LoT Language

Product Updates

AI-Assisted Development Best Practices

Make Your AI Assistant a LoT Expert

When to Use This

Setting Up Your AI Assistant

What Is an AGENTS.md?

The Three-Tier Boundary System

Starter Template

Keeping It Effective

Quick Reference Checklist

Next Steps

Coreflux MCP

Working with JSON

​Make Your AI Assistant a LoT Expert

​When to Use This

​Setting Up Your AI Assistant

​What Is an AGENTS.md?

​The Three-Tier Boundary System

​Starter Template

​Keeping It Effective

​Quick Reference Checklist

​Next Steps

Coreflux MCP

Working with JSON

Make Your AI Assistant a LoT Expert

When to Use This

Setting Up Your AI Assistant

What Is an AGENTS.md?

The Three-Tier Boundary System

Starter Template

Keeping It Effective

Quick Reference Checklist

Next Steps