lat.md Authoring Guide

This skill covers the syntax, structure rules, and conventions for writing lat.md/ files. Load it whenever you need to create or edit sections in the lat.md/ directory.

Project-specific lat documentation belongs in lat.md/. Do not modify this generated skill or a generated AGENTS.md to record project guidance: both are owned by lat tooling and may be replaced by a later lat init.

What belongs in lat.md

lat.md/ files describe what the project does and why — domain concepts, key design decisions, business logic, and test specifications. They do NOT duplicate source code. Think of each section as an anchor that source code references back to.

Treat lat.md/ as a focused snapshot of the current implemented state. Plans may be drafted in lat.md/ alongside implementation, with the intent that by commit time they describe what was implemented. Otherwise, keep proposals, hypothetical designs, and future work outside lat.md/ unless the user explicitly requests them there. A planning-only task does not require a knowledge-graph update. Do not use it as a journal or changelog, and do not grow it just to record insignificant implementation details.

Good candidates for sections:

• Architecture decisions and their rationale
• Domain concepts and business rules
• API contracts and protocols
• Test specifications (what is tested and why)
• Non-obvious constraints or invariants