AI & Claude Code

A Meno project is a normal Astro repository: .astro files under src/pages/ and src/components/, JSON content under src/content/, plus project.config.json, colors.json, and variables.json. There is no proprietary database and no opaque build artifact — the source of truth is plain text you can read, diff, and hand-edit.

That means any AI coding agent that works on a filesystem — Claude Code, Cursor, or another terminal or editor-based assistant — can open the project and edit it directly, working alongside the visual editor. You are not locked into one surface: the agent edits files, you tweak the same pages visually, and both stay in sync.

Why any agent can edit a Meno project

Meno's on-disk format is the meno-astro dialect — a constrained, fully round-trippable subset of Astro. A page is frontmatter (const meta = {…}) plus a node tree wrapped in <BaseLayout meta={meta}>. A component is a single authoritative resolveProps(Astro, {…}) block plus markup and optional <style> / <script>. Styles live in style({…}), internationalized values in i18n({…}), and templates are plain JSX expressions like {item.title}.

Because this is real, idiomatic Astro, an agent does not need a plugin or an API to participate. It reads and writes the .astro and JSON files the same way it would in any other codebase. The only requirement is that hand-written code stays inside the dialect grammar — and Meno ships the agent everything it needs to do that.

What Meno gives the agent

Every Meno project includes context files that teach an agent the format from the first session:

• A CLAUDE.md at the project root, read automatically by Claude Code at the start of every session. It covers the project layout, the golden rules of the dialect, file skeletons for pages and components, and the CMS conventions.

• A /meno-astro skill (in .claude/) — a copy-pasteable grammar cheat-sheet for authoring or editing .astro by hand. Invoke it when you want the agent to focus on dialect correctness for a specific page, component, or node type.

• Spec documents the agent can consult for depth: .claude/docs/meno/meno-astro-dialect.md (the full grammar — nodes, lists, templates, conditionals, CMS routes, normalization) and .claude/docs/meno/meno-astro-api.md (the meno-astro runtime API surface).

With these in place, the agent follows Meno conventions without extra prompting. The CLAUDE.md distills the rules; the skill and spec docs are there when a task needs more detail.

The golden rules the agent follows

The CLAUDE.md and the /meno-astro skill repeat the same handful of rules that keep hand-edits inside the grammar:

1. Styles live in style({…}), never in a raw class="..." string. The argument is a Meno StyleObject with base, tablet, and mobile keys.

2. Internationalized values live in i18n({…}) with the { _i18n: true, en, pl, … } shape.

3. A model template {{expr}} is a JSX {expr} in markup — a bare identifier, member access, or ternary.

4. The resolveProps(Astro, {…}) argument is the single source of truth for a component's props. Keep class: className in the destructure and edit that literal to change props.

5. Component tags are capitalized and need a matching local import in the frontmatter, e.g. import Heading from '../components/Heading.astro'.

A short component the agent might write looks like this:

---
import { resolveProps, style } from 'meno-astro';

const { text, class: className } = resolveProps(Astro, {
  text: { type: "string", default: "Heading" }
});

const __meno = { category: "ui" };
---
<h2 class={style({ base: { fontWeight: "500" } })}>{text}</h2>

For the complete grammar — including lists, conditionals, interactive styles, and CMS routes — see Hand-Editing the Format and the meno-astro API reference.

The round-trip workflow

The two editing surfaces stay in sync through the meno-astro codec (emit / parse):

• When the agent edits an .astro or content file by hand, the editor parses it back into its visual model — so the change shows up in the visual editor.

• When you make a change visually, Meno re-emits the .astro file canonically — so the agent sees the update on its next read.

This round-trip is lossless as long as the agent stays inside the dialect. An edit that uses style({…}), i18n({…}), and {expr} templates parses cleanly and survives. Code outside the grammar — a raw Tailwind class="…" string, or ad-hoc Astro logic the parser can't model — won't round-trip and can be dropped on the next visual save. The fix is simply to express the intent in dialect.

Practical guidance

A few habits keep agent-driven changes clean:

• Keep changes in the grammar. Point the agent at the /meno-astro skill or the dialect spec before a big edit, and ask it to flag anything it can't express in dialect rather than writing it raw.

• Let the agent mirror generated files, not author them. Some files are derived boilerplate — src/content.config.ts, src/cmsComponents.ts, and the getStaticPaths() / cms import lines in a CMS template route. They are regenerated from the model on save, so the agent should treat them as outputs and edit the source instead (the meta.cms schema for a collection, for example).

• Review diffs in Git. Because everything is plain text, you can read exactly what the agent changed in a normal diff. Commit before a large agent run, review the diff after, and connect the repository through GitHub so changes flow through pull requests and your normal review process.

Versus the in-editor AI assistant

This article is about external coding agents that operate on the filesystem. Meno also has an AI Assistant — a chat panel built into Meno Studio. The assistant works inside the editor against the visual model and is the fastest way to make a change while you're already in the editor; an external agent like Claude Code works in your terminal against the raw .astro files and fits naturally into a code-first or Git-driven workflow.

They are complementary. Use the in-editor assistant for quick edits while designing, and a terminal agent for larger refactors, repo-wide changes, or work you want to review as a diff.

Both surfaces edit the same project. Whichever you reach for, the result is the same set of .astro files — a normal Astro codebase you can build, version, and deploy.