> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pnbr.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Create a Shape

> Describe the records a project needs, test them against a real example, and compile a Shape draft.

Use this when the Runtime catalog does not contain a Shape that can represent
your job without bending the meaning of the records.

## Before you start

* [Connect the Shapes MCP](/shapes/connect).
* Name the project that will eventually use the Shape.
* Bring one real example the Shape must represent.
* List what an agent should be able to find or add afterward.

## Ask your agent

> Create a Shape draft for customer discovery. It must represent inquiries,
> interview participants, source evidence, findings, and open questions.
> Findings should link to their evidence, and evidence should link to a
> participant or source. Start with the smallest model that can represent the
> example below. Explain the draft in plain language and do not publish it.
>
> Example: \[paste one real interview finding and its supporting quote]

## Steps

<Steps>
  <Step title="Propose the smallest draft">
    The agent creates a draft from your brief. It should not add a type or field merely because similar systems often have one.
  </Step>

  <Step title="Test the example">
    Ask the agent to show where every part of the example would go. Rename unclear types or fields now; future agents will rely on those names and descriptions.
  </Step>

  <Step title="Add what the example proves is missing">
    Add or edit types, fields, and relationships one need at a time. If a required field cannot be populated reliably from the expected material, reconsider whether it should be required.
  </Step>

  <Step title="Compile the draft">
    Have the agent fix structural errors, then compile again. Do not remove a domain concept solely to silence an error; fix the model or explain why the concept does not belong.
  </Step>

  <Step title="Preview Runtime">
    Ask what record types and fields a Runtime agent would see if this draft were published.
  </Step>
</Steps>

## Verify the draft

Give the agent a second realistic example. The draft is ready for publication
review when both examples fit without invented fields, overloaded record types,
or ambiguous relationships.

## Troubleshooting

* **Two types mean the same thing:** keep the term people in the domain actually use and merge the duplicate before publication.
* **A relationship is hard to name:** write the sentence it should support, then name the relationship from that sentence.
* **Compilation passes but the example is awkward:** change the draft. Compilation checks structure, not whether the model makes sense for your work.
* **An existing Shape is almost identical:** stop and compare it before creating a duplicate. You may want to [fork it](/shapes/fork-a-variant).

<Accordion title="Tool trace">
  ```text theme={null}
  shape_workbench_propose_shape
  → shape_workbench_inspect
  → shape_workbench_add_type / shape_workbench_edit_type
  → shape_workbench_add_property / shape_workbench_edit_property
  → shape_workbench_add_relationship / shape_workbench_edit_relationship
  → shape_workbench_compile
  → shape_workbench_preview_operating_surface
  ```
</Accordion>

<Card title="Review and publish the draft" icon="rocket" href="/shapes/review-and-publish">
  Check the exact change and run publication without applying it first.
</Card>