sim_prompt
Ask an LLM to derive something from a stored entity: a variant model, a report, a piece of generated code — whatever the prompt asks for. The parent's JSON rides along as context, the same way the guided builder gives its interviewer the draft. The parent is looked up as a model first, then a prompt, then an artifact, then a map — whichever resolves — and the context block is labelled by what kind it found ("## Parent model", "## Parent prompt", ...), so the LLM is never told a report is a Petri net. The prompt is stored first and content-addressed like a model, so it has an id of its own before the LLM ever answers; both the prompt and whatever came back are placed in lineage under the parent (sim_prompt as the activity), so Ancestry walks parent -> prompt -> result. A Relation{prompt, "produced", result} is recorded alongside — sim_reroll's forward index, and queryable directly via sim_edges/sim_neighbors. If the response parses and validates as a Petri-net model it is stored as a NEW model you own; otherwise the raw text is stored as an artifact. Refused if this deployment has no LLM provider configured.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | the natural-language instruction | |
| parent | Yes | id to run the prompt against — a model, prompt, artifact, or map | |
| system | No | optional system-level instructions, in addition to the parent context this tool always supplies |