AI in Leaf NewAI-native project context arrived in Leaf 5Leaf 5 gives assistants an explicit map of your app instead of making them infer routes, modules, configuration, and structure from scratch. β
AI-native PHP
Leaf 5 is designed so AI tools can understand your app before they edit it. Routes, modules, config, entry point, and project structure become explicit context instead of hidden assumptions.
The goal
Less guessing
AI sees the app shape before it writes code.
Cleaner changes
Generated code follows Leaf conventions instead of inventing new ones.
Real products
Use AI for auth, dashboards, billing, APIs, and app features.
Why AI struggles with most frameworks β
AI does not usually fail because it cannot write code. It fails because the app gives it poor context.
- Unclear file locations
- Scattered configuration
- Missing module information
- Hallucinated framework patterns
- Readable app structure
- Known entry point
- Installed modules and references
- A project map AI can follow
Without a map, the assistant guesses, and you end up debugging the guesses.
How Leaf fixes this β
Leaf 5 gives AI tools a reliable, shared map of your app. Projects created with Leaf CLI are AI-ready immediately, and Leaf MVC needs no extra AI configuration. An agent working inside the project reads .leaf/CONTEXT.md alongside the filesystem, then updates that shared context as the app changes.
Instant project understanding β
Open an agent in the project and ask for the feature you want. It starts with Leaf's shared context, verifies that map against the live codebase, and keeps the context useful as it works.
Prompt
The agent reads the shared context and the project itself before writing the webhook, then records useful structural changes for the next agent.
Shared project memory
That means fewer invented files, fewer mismatched APIs, and less cleanup after generation.
The shared context format NEW β
.leaf/CONTEXT.md follows a small official format, leaf.context v1, so that edits from different assistants compose instead of colliding. What Claude writes today, Cursor can extend tomorrow, and Codex can clean up next week. Every Leaf MVC project ships with the template, and leaf up generates it when scaling a lite app.
The format is plain markdown with a handful of rules:
- The first line is a marker,
<!-- leaf.context v1 -->, so tools and agents can recognize the file. It is invisible when rendered and never edited. - Sections are
##headings in a stable order: Working With This File, Project Summary, Current Goal, Architecture, External Providers, Coding Conventions, Recent Changes, Known Decisions, Future Ideas. Agents preserve sections they don't recognize and may add project-specific ones at the end. - Placeholders are underscore-wrapped lines. When one contains
agent:, it is an instruction to the next assistant: ask the user something, make a choice, then replace the line with the answer. This is how a fresh template bootstraps itself into real project memory. - Entries are single lines wherever possible, so concurrent edits merge cleanly in git. Recent Changes entries are dated (
* 2026-08-06 β what changed), capped at five, newest first. Known Decisions always carry their reasoning, because a decision without its why gets relitigated by the next agent. - The file never duplicates the codebase. Routes, models, modules and structure live in code and in
leaf context; the shared memory holds only what code cannot say: goals, decisions, and the reasoning behind them. This is what keeps it from rotting. - No secrets, ever. Environment keys are referenced by name only.
The file also opens with a short "Working With This File" section carrying these same rules, so an assistant that has never seen Leaf before still edits it correctly.
When to use leaf context β
You do not need this command to make AI features work. Use it when the assistant cannot access your project folder, such as a web chat or another external tool.
leaf contextThe command is deliberately the opposite half of .leaf/CONTEXT.md. The shared file holds what code cannot say (goals, decisions, reasoning) and never duplicates the codebase. leaf context scans the codebase and generates the mechanical map the file leaves out: app type, installed modules, actual route registrations with their handlers and middleware, models, schema files, and environment key names (names only, values never leave your machine). It then appends the shared memory, so one paste gives an external assistant both halves. It does not replace the two-way context used by agents working inside the project.
Predictable structure means better output β
Leaf's structure is intentionally obvious. AI works better when the project has clear places for code to live.
my-app/
βββ app/
β βββ controllers/
β βββ database/
β βββ models/
β βββ routes/
β βββ views/
βββ public/This gives assistants a stable path for new controllers, models, routes, views, services, and modules.
Real features, not toy examples β
AI-assisted Leaf work is meant for actual product features.
From idea to feature β
The Leaf AI workflow is simple:
- Open an agent in your Leaf project.
- Describe the feature you want.
- Let the agent read the shared context and verify it against the current project.
- Review and run the changes while the agent syncs useful project knowledge back.
For an external assistant without project access, run leaf context and paste the compact output into your conversation first.
With project memory in the loop, the assistant works more like a teammate than autocomplete.
Where this is going β
AI in Leaf is not a bolt-on. Leaf 5 shapes the framework, CLI, docs, and project structure around a future where humans and AI build software together.
