> ## 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.

# Fork a Shape

> Copy an existing Shape into a separate variant, tailor it, publish it, and confirm that the original did not change.

Use a fork when an existing Shape is a useful starting point but the new version
needs its own name, users, and future changes.

| What you need                                       | Choose    |
| --------------------------------------------------- | --------- |
| Improve the Shape for its current users             | Edit      |
| Keep the original and create an independent variant | Fork      |
| Start without inherited types or fields             | New draft |
| Read a Shape without changing it                    | Inspect   |

## Before you start

* Identify the source Shape and target project.
* Explain why both the source and the variant should continue to exist.
* List which inherited fields should stay, change, or be removed.

## Ask your agent

> Fork the default memory Shape into a sales-memory Shape for the Revenue
> project. Keep the useful memory fields, add what we need for objections and
> commitments, and remove fields we will not use. Show me the source, every
> change in the fork, and the fields Runtime would see. Do not publish it.

## Steps

<Steps>
  <Step title="Inspect the source Shape">
    Review what will be copied. If most of the source would be removed, a new draft may be clearer than a fork.
  </Step>

  <Step title="Open a fork draft">
    Confirm the new Shape name and target project. The source Shape should remain untouched.
  </Step>

  <Step title="Tailor the copied model">
    Rename unclear inherited fields, remove fields the variant will not use, and add only the records and relationships required by the new domain.
  </Step>

  <Step title="Compile and compare">
    Compile the fork, inspect its diff, and compare it with the source Shape so reviewers can see what the variant changes.
  </Step>

  <Step title="Preview and publish">
    Follow the normal dry-run and approval steps, then publish the fork as a separate Shape.
  </Step>

  <Step title="Check both Shapes in Runtime">
    Confirm that the new Shape appears in the target project and that the source Shape still has its original fields.
  </Step>
</Steps>

<Note>
  A fork copies the source as it exists now. Later changes to the source do not
  flow into the fork automatically.
</Note>

## Verify

Runtime should list the new Shape under its own name. The agent should be able to
explain when to use the source and when to use the fork, and the source should
show no changes from this workflow.

## Troubleshooting

* **The fork is almost identical to the source:** reconsider whether a second Shape helps anyone.
* **The fork removes most inherited fields:** start a new draft to avoid carrying confusing history.
* **The original changed:** stop and inspect whether the agent opened edit mode instead of fork mode.
* **You expected later source updates to appear:** compare and apply them manually; forks do not stay synchronized.

<Accordion title="Tool trace">
  ```text theme={null}
  shape_workbench_open({ mode: "inspect" })
  → shape_workbench_open({ mode: "fork" })
  → shape_workbench_edit_* / add_* / rename_* / reserve_*
  → shape_workbench_inspect
  → shape_workbench_compile
  → shape_workbench_diff
  → shape_workbench_review_family
  → shape_workbench_preview_operating_surface
  → shape_workbench_materialize({ dry_run: true, review_note: "..." })
  → approval and publication
  → Runtime: penumbra_introspect
  ```
</Accordion>