Katara's checkup

A healer does not check a patient once and call them well forever. Bodies change. So do apps. The feature map in a verify skill starts to rot the moment the app changes, and a checkup finds the drift before it misleads the next agent.

On Codex, read avatar-mode/references/codex.md for tool equivalents.

This is the upkeep loop for a skill generated by vital-signs, or any project-local verification skill with a feature map. The unit of rigor is the feature, not every sentence. Cover every feature file from source and exercise every feature live, without turning every bullet into a terminal command.

Outcomes

Pick one, and say which.

• clean. Every feature got source and live coverage, and nothing is worth shipping. No branch, no PR.
• changed. One PR ships proven doc, harness, or map corrections.
• blocked. Coverage could not finish, or a proven fix could not ship safely. Say exactly what blocked it.

Edit scope

Edit only the verification skill's own directory: its SKILL.md, features/, and any harness scripts it owns. Never edit product code during a run. When the map describes a behavior the app no longer has, that is either doc drift (fix the map) or a product regression (report it, and do not paper over it in the docs).

Pass

0. Locate the target. Find the verification skill to maintain. It is the project-local skill whose body has launch and drive sections and a feature map (.claude/skills/verify/ or .agents/skills/verify/, or a verify-* sibling from an older generator). With several candidates, ask which one. With none, stop and point at vital-signs instead of inventing a target.

1. Index hygiene. Read the feature map README and list its sibling files. Fix missing, extra, duplicate, or dead entries. Keep this light, with no generated inventory.

2. Source wave. Dispatch one read-only team-avatar:toph per feature file, all at once, on Toph's model from the avatar-setup sheet. Each explains "how does this user-facing feature work?" from source with seismic-sense, flags likely doc drift with citations, and returns one concise live-verification recipe. These readers never drive the app and never edit files. Their return shape is a feature summary, the source entry points, likely drift or none, and one recipe. When you are already a subagent and cannot dispatch, read each feature yourself, one after another.

3. Reconcile. Confirm every feature file has a returned summary. Merge overlapping recipes into as few app states as practical. Spot-check the cited drift, and do not re-prove clean claims. Sweep recent churn for user-facing surfaces missing from the map. Require a concrete source path before calling one missing.

4. Live pass. Required even when the source looks clean. The coordinator owns all driving. Follow the verification skill's own launch model. That is one long-lived instance driven serially for servers and UIs, or a fresh isolated session per drive for short-lived CLIs. The skill's Launch section decides, not this one. Exercise every feature at least once, and hold three invariants for the whole pass, whatever fails.

   1. Never drive an instance you have not health-checked since it last did something surprising. Run doctor before the first drive, on each fresh session where sessions are the unit, and again after any failed drive. Where doctor cannot see the failure (a wedged UI state on a healthy process), reset to a known state or relaunch rather than hoping.
   2. Evidence captured so far survives every cleanup. Check it at its named location. Do not assume it.
   3. Nothing a drive started outlives that drive's usefulness. Clean failed-iteration residue whether the session is stuck, exited, or shared. For a shared instance, clean the residue, not the instance.

   A doctor failure caused by skill drift is drift. Fix it under the edit scope and retry once, restarting only what the fix invalidated, before you call the pass blocked. A feature that cannot be reached is verified-unreachable only with the concrete prerequisite (auth, entitlement, OS, external state) and the route you attempted. If the map omits that prerequisite, that is drift. Re-drive any harness fix from triage live before it ships. Final teardown happens after the last drive of the run, re-proofs included, so nothing outlives the run. Evidence stays, per the skill.

5. Triage. A wrong or missing user-POV description is doc drift. Fix it. Working behavior the harness cannot drive is a harness gap. Fix it, and follow the same helpers rule as vital-signs (scripts executable, invocation shown in the skill body). App behavior that is actually broken is a product gap. Record it for the user and keep it out of this PR.

6. Ship or stop. For changed, open one PR of proven corrections with yip-yip, after you re-read every changed file. For clean or blocked, open no PR. Report the outcome and the coverage honestly.

Keep concise run notes (features covered, unreachable prerequisites, confirmed drift, outcome) in a scratch location. Do not commit them.