| name | update-creation |
| description | Change an existing skill, app, service, or shared script/reference (under .agents/shared/) -- extend it, refactor it, or just verify it still works. Invoke at turn-end when a skill ran but you had to do extra repeatable work by hand, or when you and the user discussed a change to it and applied it live. |
| metadata | {"author":"imbue"} |
Updating an existing creation
This is the change lead of the generic creation lifecycle. The creation
already exists; you dispatch a generic worker to harden the change in the
background, proxy its gates, merge, and go live. There is one flow with a
design-gate toggle keyed on whether the change is already committed.
The two origins
- committed -- you and the user discussed the change live and it is already
committed on the branch. The design was approved organically in chat, so the
worker skips the design gate, reads the committed diff as ground truth,
verifies it, and presents the final gate.
- emergent -- a skill ran but additional repeatable work had to be done by
hand, with no design conversation. The worker reconstructs the incident from
your transcript, runs a design gate (Gate 1), implements, runs scenarios, and
presents the final gate.
Pick committed when the user was explicitly in the design loop and the
change is already committed. Otherwise emergent (the safe default; its
Gate 1 re-surfaces the design for an approval pass).
Confirm the user actually wants the change before you dispatch (committed
origin). Applying a change live is not the user approving it. Do not launch
the hardening worker in the same turn you made the change: end that turn by
surfacing the change and asking whether it's what they wanted, and only invoke
this flow once they've given a clear go-ahead. Like any incremental work this
can take several rounds -- the user may keep responding with adjustments;
treat each as another live iteration and do not launch the worker until you
are sure they're satisfied with the update, not just at a single mid-thread
"looks fine." (The emergent origin is transparent work with no live change to
approve, so this gate doesn't apply there; its Gate 1 covers design approval.)
"Repeatable" covers deterministic extensions (an extra flag, a new output
format), model-judgement extensions (an additional judgement step with a stable
recipe, scripted as [ai-script]), and executor meta-work. One-off creative or
exploratory work is NOT an update candidate.
The type parameter
type is skill, app, service, or system-interface. It drives where the
worker looks (type-<TYPE>.md) and the go-live strategy (Step 4):
skill → cross-reference sweep is part of the edit, nothing else; app →
refresh the tab (a background service has no tab -- restart it instead);
system-interface → the update-system-interface wrapper owns a
preview-before-merge and a go-live through the atomic update apply, and calls
into this flow for the orchestration core only (see that skill).
Conventions
Use $TARGET for the creation (e.g. migrate-config, an app or service name). Then:
- Worker agent name and branch:
update-$TARGET / mngr/update-$TARGET
- Runtime dir / task file:
data/.tasks/harden/update-$TARGET/ /
data/.tasks/harden/update-$TARGET/task.md
Step 1: Open a tracking ticket
Single-flight check first. At most one harden pass per creation may be in
flight (counting heal passes on the same target). Run the pre-dispatch check
in .agents/shared/references/harden-contention.md;
if another agent's pass is live, leave the note it describes on their ticket
and stop -- the superseding pass forced at their merge time covers your change.
Only dispatch if no pass is live (or you took over an abandoned one).
mkdir -p data/.tasks/harden/update-$TARGET
TICKET_ID=$(tk create "update $TARGET" -t task \
--acceptance "task file written; worker launched; worker DONE; branch merged")
tk start "$TICKET_ID"
Step 2: Capture the change and write the task file
For the committed origin, capture the commit metadata and full diff so the
worker has a convenience index (the change is also on its branch on disk):
COMMIT_RANGE="HEAD~1..HEAD"
git log --format='%H %s' "$COMMIT_RANGE" > data/.tasks/harden/update-$TARGET/commit.log
git log -p "$COMMIT_RANGE" > data/.tasks/harden/update-$TARGET/commit.diff
Write the task file. Frontmatter carries operation: update, the type,
and finish_report_path (the report destination the lead polls; see
.agents/shared/references/worker-reporting.md). The body carries the
## Change origin marker the worker dispatches on, plus origin-specific content:
cat > data/.tasks/harden/update-$TARGET/task.md << TASK_EOF
---
finish_report_path: data/.tasks/harden/update-$TARGET/reports/report.md
operation: update
type: skill
---
# Task: update \`$TARGET\`
## Change origin
ORIGIN: emergent
## Incident summary (emergent) / Committed change (committed)
<emergent: 2-5 sentences -- what the user asked for, how \`$TARGET\` fell short,
and the additional repeatable work you did by hand.>
<committed: branch, commit range (see commit.log), a summary of what changed and
why, and the design rationale the worker checks the diff against.>
## Anchors (verbatim quotes)
The worker uses these with \`mngr transcript\` to locate the relevant turns.
<emergent: the user's request, the insufficient \`$TARGET\` output, and a quote
showing the manual follow-up. committed: 1-3 quotes that pinned the design.>
## What the updated creation must do
<emergent only: the contract the creation must honor after the change -- inputs
it should now accept, outputs it should now produce. Describe the new contract;
the incident is captured above.>
## What to do
Use the installed \`harden-worker\` sub-skill. It reads \`operation\`,
\`type\`, and the \`## Change origin\` marker, then follows the matching
references. Push reports to the lead per its reporting protocol.
## Success criteria
- The change is hardened, tested, and passes the review gates on your branch.
- The user approved the final creation (Gate 2); for the emergent origin, also
the outline (Gate 1).
TASK_EOF
Set ORIGIN: committed and type: as appropriate. Fill in the real
content; do not leave placeholders. The ## Change origin marker is required --
the worker fails loudly if it is missing.
Step 3: Launch the worker and poll
Commit any pending changes before you launch, and never harden inline. The
worker is created from your committed HEAD, so uncommitted changes never reach
it -- and create_worker.py launch refuses a dirty tree outright. Commit your
work first (the change being hardened is exactly what belongs on the branch);
commit, never stash -- stashed work gets lost during multi-agent
coordination. A dirty tree (even unrelated changes) is never a reason to do the
hardening inline: commit, then dispatch. Hardening always runs in the background
worker.
uv run .agents/skills/launch-task/scripts/create_worker.py launch \
--name update-$TARGET \
--template worker \
--runtime-dir data/.tasks/harden/update-$TARGET/ \
--task-file data/.tasks/harden/update-$TARGET/task.md
Then background-poll (create_worker.py await --task-file ... --timeout 90m,
run_in_background: true) and follow .agents/shared/references/lead-proxy.md.
Flow-specific substitutions:
- Worker name:
update-$TARGET; branch: mngr/update-$TARGET
- Poll path:
data/.tasks/harden/update-$TARGET/reports/report.md; reports dir
data/.tasks/harden/update-$TARGET/reports/; consumed
data/.tasks/harden/update-$TARGET/reports/consumed/
- Gates:
outline-approval (emergent only -- the design gate) and
final-creation (both).
- Terminal statuses:
done (go live, Step 4); no-update-needed (no change --
close the ticket, no merge); stuck (failure flow per
.agents/skills/launch-task/references/worker-failure.md).
Step 4: Merge and go live
On done, first run the merge-time checks in
.agents/shared/references/harden-contention.md:
wait out any foreground editing lease on the service, confirm the branch is
still fresh (the creation's footprint has not changed since the worker
branched), and never hand-resolve a conflicted merge -- a stale or conflicted
pass is discarded and superseded by one new pass covering everything since the
last hardened merge.
Then merge mngr/update-$TARGET and go live by creation:
- skill: nothing beyond the merge (the worker's cross-reference sweep is part
of the change). If the target is a built-in upstream skill, note the local
drift to reconcile later via
update-self / submit-upstream-changes.
- service: refresh the tab (
python3 system/scripts/layout.py refresh <service-name>).
- system-interface: do not merge or go live here -- the
update-system-interface wrapper drives preview-before-merge and the
go-live through the atomic update apply. (That wrapper uses this flow for
Steps 1-3 only.)
Then close the ticket:
tk close "$TICKET_ID" "Updated $TARGET -- worker branch merged."
Gotchas
- Update is non-blocking -- the user's original request is already delivered;
the update worker produces a quieter follow-up commit.
- The committed origin's worker may produce no new commits of its own if
verification is clean. That is expected -- the substantive change is already
on the branch from the live commit.
