Your first item

Ember Forge reads the same YAML layouts the major content plugins use, so a minimal ItemsAdder-style item works as-is.

Create plugins/ItemsAdder/contents/mypack/configs/items.yml:

info:
  namespace: mypack

items:
  ruby:
    display_name: "<#ff5f8f>Ruby"
    resource:
      material: PAPER
      model_path: "mypack:item/ruby"

Put the model and texture where the namespace expects them:

contents/mypack/resourcepack/assets/mypack/models/item/ruby.json
contents/mypack/resourcepack/assets/mypack/textures/item/ruby.png

Then:

/emberforge rebuild
/emberforge give <player> mypack:ruby

Both pack layouts work

Content packs ship in two different shapes, and Ember Forge reads both:

resourcepack/assets/<namespace>/models/...    # the "assets" layout
resourcepack/<namespace>/models/...           # the bare layout

Roughly a third of real packs use the second form. Reading only the first is a common bug — the items register fine, then render as a plain base item because their assets were never copied.

Base material and model id

Key	Meaning
resource.material	The vanilla item the custom model rides on
resource.model_path	Namespaced model, e.g. mypack:item/ruby
resource.model_id	Optional fixed custom-model-data value

Leave model_id out and Ember Forge assigns one from model-data-start, skipping anything in reserved-model-data. Assigned ids are recorded in plugins/EmberForge/model-ids.yml and reused, so an item keeps its id across rebuilds — otherwise every item already in a player's chest would change appearance on the next restart.