aimeat-protocol: Skill for Claude Code

Building an AIMEAT application

Research first, before reading repo source

The moment the task is "build / make / publish an app on AIMEAT":

You have aimeat_* MCP tools. Follow the research-first flow: load the skill node:aimeat-app-builder and call aimeat_appdev_overview first. A NEW app goes on the Atelier track: load node:aimeat-app-builder-atelier, read its specification (aimeat_handbook_get { tier: "build-app-atelier" }, in parts, or GET /v1/prompts/build-app-atelier) and fork a genre (aimeat_designbook_search { kind: "genre" }, then aimeat_app_template_get { id: "genre-<id>" }). GET /v1/prompts/build-app and the Classic shells are for improving an app that is already Classic, or when Jouni asks for Classic by name.

The track is not changed in the middle of a build. On 2026-09-19 a model began on Atelier, judged the Classic shell quicker to start from, changed over, and handed Jouni an app with a hand-built header and a broken sign-in bar; it had accepted that because its own tests passed. "Quicker to start" is not a reason. If the Atelier road stops you, say what stopped you and wait. The publish names a build that left the track (app_hints, pitfall track-drift), and a finished app is compared with the genre it was forked from before it is shown.

This is a hard precondition of the build, not an optional preamble, and it comes before reading repo source: existing published apps and the KB show which libs and patterns are already proven, so reuse beats re-deriving from lib sources. Skipping it once produced non-theming (hardcoded colours), meta-less, duplicate, low-polish apps.

Four node-side stores answer almost everything, and they are shared by every session:

• aimeat_appdev_overview: what apps, extensions and capabilities already exist. Check before building anything.
• aimeat_skill_list then aimeat_skill_get: most published apps carry their own operating guide as a skill (user:{owner}/{app}-agent-guide, cadence-crm, operate-exchange, node:origami-boards, …). If you are working on or against a named app, load its skill instead of reconstructing how it works.
• App Development Notes: the dev organism's workspace fbb51de5-56d5-4143-9871-b998a1187655 / ws-mslr8u99kzk, one appnote document per app: locked design decisions, prod organism/workspace ids, traps hit while building, open questions the developer still owns. Read the app's note before changing it; write back what the next session would want.
• aimeat_appdev_pitfall_list: the app-building trap catalogue (curated plus what other sessions learned).
• node:aimeat-app-workstation, once the app is past roughly 300 kB or a few thousand lines. One file has no natural brake and the cost lands on the edit loop: a 3.18 MB app on this node turned five-minute changes into forty-minute ones, and 477 kB of it was base64 images inlined into the source. The skill is the way out (assets to storage, sources split behind a build script that assembles the one file, GET /v1/app-templates/workstation-project for the scaffold). The publish response's next_steps.size says when you are there.