| name | heal-creation |
| description | Fix an existing creation that errored or delivered a wrong result. This applies to skills, apps, and services. Invoke at turn-end, after you worked around the failure to satisfy the user's request. |
| metadata | {"author":"imbue"} |
Healing a broken creation
This is the heal lead of the generic creation lifecycle. An existing
creation should have delivered the correct result but did not; you dispatch a
generic worker to reproduce the incident, find the root cause, apply a minimal
fix, re-run scenarios, and present a single approval gate. Heal is a turn-end
action -- do not interrupt in-flight work to invoke it; the user's original
request is already delivered.
The type parameter
type is skill (the default), app, or service. The worker reads it and loads
type-<TYPE>.md. (A system-interface regression is a heal operation
too, but it is driven through update-system-interface, which owns the
preview and the apply-or-roll-back go-live -- do not drive a system-interface
heal from here.)
When NOT to heal
- The creation worked fine; the request was genuinely out of its scope -- that
is an
update-creation situation, not a heal.
- The failure was one-off and transient (network hiccup, rate limit).
- You are unsure why it failed. Finish the user's request, gather evidence, then
decide if heal applies.
Conventions
Use $TARGET for the creation you are healing (e.g. migrate-config, an app
or service name). Then:
