What can change without any version bump?

This is the one defensive pattern that survives every kind of change described here. A skill that checks for the tool it needs, uses it if present, and says plainly what it could not do otherwise will keep working across sandbox changes, served-configuration flips, and version bumps. A skill that assumes a surface breaks silently on all three.

At least some served configuration is subscribed to rather than read once, so it can change while a session is running and the application reacts. A skill that reads a capability at the start of a long task and caches the answer can be wrong by the end of it.

The instructions a Cowork session runs with can be patched from the operator's side, including a mode that replaces the computed instructions wholesale rather than adding to them. So a model of the session prompt as 'the standard preset plus my additions' can be wrong at any time, with no local artifact changing. Depend on behaviour you can observe, not on text you expect to be present.

Behaviour governed from the operator's side changes with no new version, no release note, and nothing observable locally. This has been directly observed: a capability that was off in one week's capture was on in the next, with no application update in between.

A meaningful part of what a session offers is decided on the operator's side at spawn time. Two sessions on the same application version can therefore present different tools and different defaults. Nothing about the installed version tells you what a given session will look like.

When something changes underneath you, the cost of diagnosis is dominated by not knowing what was assumed. A short stated list of dependencies — this needs a delivery tool, this needs shell access, this assumes files persist within the turn — turns a silent failure into an obvious one.

Tool surfaces have changed across releases: names differ between runtimes, tools have been added and withdrawn, and which ones a session gets is decided when it starts. Name a tool only after checking it exists, and say what you will do if it does not.

When a long conversation is compacted, previously-invoked skills are re-attached from a stored copy rather than re-read from disk, and that copy is subject to two separate limits. The first shortens an over-long skill, keeping roughly the first twenty thousand characters and discarding the tail — and the shortened version replaces the stored copy, so a later compaction cannot bring the rest back. The second is a shared budget across every skill invoked in the session: once it is exhausted, a skill that does not fit is not shortened but emptied, and stays gone for the rest of that session. Skills are packed most-recently-used first and counted at their already-shortened size, so the one that disappears is usually not the largest — it is whichever was used least recently when the budget ran out. Only the first of the two announces itself. When your skill is shortened, a marker is appended to what the model reads, saying in so many words that the text was cut and can be re-read from its path — so a skill can be written to notice that and try to recover. When a skill is emptied by the shared budget it is simply not there that turn: no marker, no entry, nothing to compare against. So a recovery instruction is worth writing, and is worth writing as covering the case it can actually detect rather than as covering both. Nothing errors, and the file on disk is untouched — but treat that recovery as best-effort rather than a guarantee. The location offered to the reader is the one captured when the skill was first invoked, not one resolved fresh at the moment it is read, and where a skill's files are staged is decided by the surface rather than by you. Within a running session it resolves. The case to design against is a session resumed later, where a location captured earlier may no longer describe where that skill now lives — and it would fail by pointing somewhere that is not there rather than by saying so. Two practical consequences: put load-bearing instructions early and push detail into reference files, which are read on demand and are genuinely not counted against either limit; and if a later section of your own skill appears to be missing, say so and re-read the file rather than proceeding on what is left. Be aware of what moving detail into a reference actually trades, though: the shortened skill body tells the reader it was cut, while material that came from a reference and later falls out of the conversation leaves no such signal — so the pointer telling the reader those references exist and must be read has to survive near the top of the file, and is doing more work after the move than before it. One reassurance, so you do not defend against the wrong thing: the shared limit is counted separately for each agent, so dispatching work to sub-agents does not consume the budget your main thread is working within.

A fallback is the right answer when a missing capability costs you convenience. It is the wrong answer when the missing capability is a gate, a second opinion, or a verification step, because what you ship then is a self-graded, self-reviewed result that looks exactly like a checked one — same structure, same confident summary, same score — and neither the user nor a later reader can tell the difference. This is not hypothetical: a review skill run on a surface without its own plugin hand-wrote every hand-off it would normally have delegated, scored its own checklist, ran no adversarial pass and no gates, and produced a report indistinguishable from a verified one, with a single sentence carrying the wrong explanation and nothing else signalling. If you cannot run your checks, refusing costs the user one run; degrading costs them their trust in every run you did check. Where you do continue, name in the output exactly which check did not happen and why, and never let a skipped step be recorded with a value that implies it could be retried here.