App update
An operation-layer op-card that refreshes the workflow's view of the host project. It re-validates and regenerates app.md (host facts) from current evidence at ../ when the existing app.md has gone stale — the stack changed, directories moved, commands were retired, or the test framework was swapped — and separately re-probes runtime availability before overwriting config.json unconditionally. You start it by pasting one prompt path; it records its run as an operation_record born complete in 4_done/.
The flow
The agent runs entirely outside the staged pipeline. After a pre-flight that confirms a valid existing app.md (a missing or invalid one routes you to app-init instead), it re-probes the host facts and the available runtimes, rewrites the two context files, then authors its own operation record. The three load-bearing steps are below.
What it is for
Run app-update when the host project has drifted away from what app.md describes. Over the life of a project the stack and tooling change: new top-level directories appear, docs are reorganised, a build command is renamed, dependencies are added or dropped, or the test framework is replaced. When that happens app.md still parses but no longer faithfully describes ../, and every downstream workflow agent reads stale routing.
app-update repairs that. It runs a fresh, bootstrap-grade re-survey of the host, rewrites app.md clean from current evidence — keeping only the facts the host still backs, rewriting what changed, and dropping what has become stale — and re-probes which runtimes are available, overwriting config.json. The trigger is suspected drift: run it whenever the stack or tooling changed, or after a major host update.
The logic
app-update sits in the operation layer with the op-card shape. It is direct-invoked — the orchestrator never dispatches it and it never enters the stage loop. At the end of a successful run it authors its own operation_record job, born complete in 4_done/, so the refresh is tracked like every other action the workflow performs (D-44, D-54). That record carries the run summary and drift verdicts; there is no follow-up orchestrator run to land it.
_processes/00_app/ home but are separate, independently-runnable agents — not modes of one tool. app-init bootstraps the first app.md on a fresh install; its trigger is a missing or invalid app.md. app-update re-validates and regenerates an existing valid app.md; its trigger is suspected drift. app-update is not a wrapper, alias, or --mode=refresh of app-init — it runs its own deep discovery and writes its own output. If you point it at a missing or invalid app.md, it stops and routes you to request-type-app-init.html.
The fields
Like every operation type, app-update is surfaced in the intake form only as a copy-the-prompt-path op-card. Its "fields" are the host itself, not form inputs.
## Stages block, no approval gates, no action-config fields. Selecting app-update in the form collapses the left column and renders only the op-card.
- Inputs — the current host project at
../plus the existingapp.mdthat the agent re-validates and regenerates.config.jsonis not re-validated from existing state; runtime availability is re-probed unconditionally and the file is overwritten from that probe. - Outputs — a refreshed
app.md(host facts; rewritten clean) and a re-probedconfig.json(runtime availability), plus theoperation_recordjob in4_done/that records the run.
How to run it
Paste the prompt path below into a fresh Claude Code session opened at the workflow root. There is nothing else to configure — the agent runs immediately and asks you only about genuinely ambiguous host facts.
_processes/00_app/app-update.prompt.md