The skill and its recipes

The elasticore skill loads when Claude works in a project that applies the io.elasticore plugin, when files start with an //ecd: line, or when you ask for an application built "with ElastiCORE". Its rule: the DSL is the source of truth - change what the application is in YAML, regenerate, and write by hand only what the DSL cannot express, in the files the generator hands over.

The fast path

What the skill tells the agent to do first:

0. An existing project: check that build.gradle has an elasticore { } block with architecture = 'hexagonal' or 'ddd'.
1. A new project: references/new-project.md - the coordinates, how to find the newest 3.x release on Maven Central, a template its CI builds every week. Then copy the recipe that fits.
2. DSL syntax: references/quick-reference.md, one page. The long guides only for what it does not have.
3. Change the YAML, run ./gradlew compileJava (./gradlew.bat on Windows, from Git Bash too), fix every warning in the YAML.
4. Run and check: references/run-and-check.md - a jar in the background, stopped by its process id. Never ./gradlew bootRun from a tool's shell; never stop processes by name.
5. Do not write controllers, DTOs, repositories, security, sign-in or error handlers by hand. Extra rules go in <Entity>Service.beforeSave; an operation the CRUD does not have is a method there plus one small controller.

It also keeps the agent inside the project: no searching other repositories on the machine for templates, no git commands that discard work it did not create, and ElastiCORE only as a released version from Maven Central - never built from source for a project.

The recipes

Complete projects - DSL, the few hand-written files, and every request with its answer - that the kit's contract test generates, builds, starts and calls.

Recipe	Domain	Use it when
recipe-board.md	posts and comments	CRUD with validation, search and paging
recipe-library.md	books, members, loans	a rule reads other rows (no copy left to lend - 409), the server sets values, or there is an operation besides CRUD (return a loan)
recipe-shop.md	members, products, orders	users sign in and see only their own, an administrator does more, a record moves along (placed, shipped, cancelled), prices are kept and summed, the application starts with data

The library and shop recipes need ElastiCORE 3.0.261021 or later - on Maven Central that is 3.0.261022-rc1 and later (the generated sign-in, the 409 of a refused step, the 404 of a missing reference, @readonly, @search(isnull), @pattern, ConflictException); the library recipe's last section says what to write by hand on 3.0.261020.

The shop recipe's model, in short:

  Member:
    meta: entity @root @editable @expose(20) @signin @owner(memberId) @access(read=owner, create=public, update=owner)
          @Index(name="uk_member_login", columnList="login", unique=true) -- member
  PurchaseOrder:
    meta: entity @root @expose(20) @owner(memberId) @access(read=owner, create=user, cancel=owner)
          @event(Shipped(total), Cancelled(total)) @sort(orderId-) -- order
    fields:
      orderedAt: datetime @readonly @default(now) -- ordered at, set by the server
      shipTo:    Address @Embedded -- delivery address
      card:      Card! @Embedded -- payment card
      total:     money(12.2) @compute(sum(lines.subTotal)) -- the lines added up
      lines:     List<OrderLine> @OneToMany(mappedBy="order") @dtype(List<OrderLineDTO>) @minsize(1, 'an order needs a line')
    states:
      status:
        initial: PLACED
        ship:    PLACED -> SHIPPED
        cancel:  PLACED -> CANCELLED
        delete:  CANCELLED

plus three new Java files and one method added to PurchaseOrderService: start-up data in CurrentUser.runAsSystem, an @EventListener for the shipped and cancelled events, and an administrator's report behind ACCESS.require(currentUser, "report") with one small controller.

The quick reference

references/quick-reference.md is the DSL on one page for the rule engine with hexagonal or ddd, and every line of its sample is generated, compiled and called in the kit's CI:

• fields and their checks (string! does not refuse "", @notblank does; @length(min=), @email, @pattern, @min/@max, @past/@future, @writeonly, @password, @minsize), values with @Embedded, references and the names of their key fields;
• keys, the entity line, the exact API of an @expose entity (lists and searches are POST /search, an update carries its key in the body, PUT /batch, POST /delete, GET /schema/info);
• who may do what and the generated sign-in; a lifecycle and derived values; time stamps (@readonly @default(now), the audit pair with @EnableJpaAuditing);
• measures for BI tools (metrics.yml, ossie-export);
• where your own logic goes, and the runtime classes a file of yours uses - so the agent does not open the jar;
• messages in another language, names to avoid, and what to do after every change.

File ownership, generators, architectures

The skill teaches the agent to read a file's first lines before editing it (//ecd: - the generator's; // Initially generated by ElastiCORE; - yours), which files are rewritten without an //ecd: line (schema.yml, semantic_model.yml, the copied guides, the default messages file), and how to add one preserved block. It checks which generator a build runs: without an elasticore { } block the 2.x generator ignores @access, @owner, @password, @login, states:, @compute and @snapshot without a warning; layered Java keeps the 2.x-compatible output; ddd and hexagonal enforce everything.

Before it runs -Pforce, deletes a file you own, changes @access/@owner/@login/@password, removes or renames a field, or changes the architecture, it asks you.

The agents and commands

elasticore:modeler	finds the model and the generator, looks the constructs up in the project's guides ("if no guide shows an annotation, it does not exist"), makes the smallest DSL change, generates and compiles until there is no warning and no error, and returns a change report
elasticore:reviewer	sorts the changed files (DSL, owned, generated), finds hand edits to generated files, checks the DSL against the guides and the generator the build runs, and explains who gains or loses access; it reports and does not fix
/elasticore:generate	builds (compileJava by default, never -Pforce), says which generator ran, and explains the summary line, every warning and every hand-edited file with the DSL fix
/elasticore:change-report	from git diff -- src/main/resources/blueprint: what is stored, who may do what, the lifecycle, derived values, the API - and what needs a decision
/elasticore:review	hands the review to the reviewer; builds only with full

The change report's "Needs a decision" lists, for example: wider @access, a removed or renamed field, a narrowed type, a removed state or move, a reduced @expose, a changed key, a changed @password or @login.