Fork a Shape

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

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.

Open a fork draft

Confirm the new Shape name and target project. The source Shape should remain untouched.

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.

Compile and compare

Compile the fork, inspect its diff, and compare it with the source Shape so reviewers can see what the variant changes.

Preview and publish

Follow the normal dry-run and approval steps, then publish the fork as a separate Shape.

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.

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

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.

Tool trace

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

Change a Shape

Begin

Design and publish

Evolve

Before you start

Ask your agent

Steps

Verify

Troubleshooting

​Before you start

​Ask your agent

​Steps

​Verify

​Troubleshooting

Before you start

Ask your agent

Steps

Verify

Troubleshooting