Conciseness

Every sentence carries non-obvious operational knowledge Claude could not infer — e.g. "list-deployments only runs next to a manifest.yml with an app_id and a name, even with --app-id" and "Never retry by stripping IDs: that creates a second app next to the customer's". Nothing explains concepts Claude already knows, and no dates or version numbers pad the body, matching anchor 5's "every token earns its place".

Actionability

All commands are copy-paste ready with exact flags (the stub-manifest workaround, "foundry apps sync --app-id <app-id> --deployment-version <version> -d $WORK/deployed --replace-all --no-git --no-prompt"), decision logic is driven by concrete exit codes ("Exit code 2 means the plan removes an artifact..."), and failure signatures are quoted verbatim ("Error: ... has entries with IDs but no name", "The templates API returned 403") with remedies — anchor 5.

Workflow Clarity

The 7-step procedure is explicitly sequenced with validation checkpoints throughout: step 1 confirms profile/CID ownership, step 5 gates destructive removals on exit code 2 with user confirmation, step 6 runs "foundry apps validate" before deploy, and "When it fails" provides error-recovery paths (stop, keep $WORK, use debugging-workflows) — anchor 5's explicit validation with feedback loops; the destructive-operation cap does not apply since validation is present.

Progressive Disclosure

The ~60-line body keeps the procedure inline while offloading verification detail to a single, clearly signaled, one-level-deep reference — "See [references/live-verification.md](references/live-verification.md) for what was checked against a live CID and the checklist for re-testing" — and the script lives in scripts/upgrade_manifest.py as cited; both bundle files exist and contain exactly what is claimed, matching anchor 5.

Specificity

"Upgrade a Falcon Foundry app that was installed from a template to a newer version of that template, in place" defines the action precisely (in place, from-template, newer version) and specifies accepted inputs ("app ID plus a newer template archive, directory, or GitHub repo"), but lists only the one core action rather than several — noticeably above the anchor-3 example ("Processes PDF files and extracts content") yet below anchor 5's multi-action comprehensiveness.

Completeness

The "what" is explicit and concrete (upgrade a template-installed app in place) and the "when" is given as an explicit TRIGGER clause with multiple concrete trigger phrases, plus a DO NOT TRIGGER clause; this clearly matches anchor 5 (both what and when with concrete trigger phrases) rather than anchor 4's merely adequate 'when'.

Trigger Term Quality

Quoted natural phrases users would actually say — "upgrade an app", "update an app installed from a template", "pull the latest template into my app", "update a sample app installed in my CID to the latest version" — cover the upgrade/update/pull synonym space plus all input forms, matching anchor 5's comprehensive natural-term coverage.

Distinctiveness Conflict Risk

The Falcon Foundry template-upgrade niche is narrow, and "DO NOT TRIGGER for creating a new app (use development-workflow) or for deploying changes to an app the user develops locally" explicitly disambiguates the closest competing skill, giving minimal conflict risk per anchor 5.