The account team has used the same AI skill for six weeks. It turns call notes into a polished customer update, follows the approved structure, and usually saves twenty minutes.

Then a renewal call ends with an unusual condition: the discount applies only if legal approves a new data term. The skill produces its familiar update and treats the discount as settled. A manager catches the mistake before the message goes out. Everyone fixes the draft. Nobody fixes the skill.

That is how a useful prompt becomes a quiet source of repeat errors. The team treats each bad output as an isolated editing problem, even though the reusable instruction is now part of how work moves.

This deserves attention because shared AI instructions are becoming easier to create and distribute. On September 16, Google introduced Workspace skills, reusable prompts that can draw on team rules, templates, and reference files. Teams can build them collaboratively in Docs, test them in Workspace Studio, and share them across the organization. Google's examples include standardizing proposals, status updates, and invoice reviews. Google Workspace announcement

The opportunity is real. So is the change in category. Once several people depend on a prompt, it is no longer just a clever personal shortcut. It is a lightweight operating procedure, and it needs a maintenance contract.

A shared skill encodes judgment, not just wording

The visible part of an AI skill may be a set of instructions. The valuable part is the judgment hidden inside them.

A proposal skill may contain assumptions about which proof points matter, who can approve a discount, how risk is described, and what must be left out. A status-update skill may decide which delays count as material and whose work gets mentioned. An invoice-review skill may embody one specialist's sense of what looks suspicious.

That judgment changes. Policies are revised. Teams reorganize. A customer negotiates an exception. A source file moves. A repeated edge case reveals that an instruction was too broad. Even a well-designed skill can drift away from the work it is meant to support.

NIST's March 2026 report on monitoring deployed AI systems identifies rapid change, limited visibility, use-case-specific monitoring, and the difficulty of scaling human review among the practical barriers organizations face. The report also notes the challenge of keeping technical and policy documentation synchronized as both AI systems and their operating environments change. NIST AI 800-4

A small team does not need a monitoring department for every shared prompt. It does need an explicit answer to a simpler question: who notices when reality has moved?

Write the maintenance contract beside the skill

Keep the contract short enough that people will actually use it. Six fields are usually enough.

Job: What repeatable outcome should this skill produce? Be specific. "Create the weekly launch update from approved project sources" is clearer than "help with status reports."

Owner: Who can revise the skill and decide when a reported problem is local or systemic? Ownership should belong to someone close to the work, not automatically to the person most enthusiastic about AI.

Approved inputs: Which templates, folders, records, or rules define correct behavior? Name sources that can be kept current. Avoid the vague instruction to use anything relevant.

Expected variation: Which parts may change from case to case? A customer update may vary in tone and detail while its approval language remains fixed.

Stop cases: Which conditions should make the skill pause, label uncertainty, or return the work to a person? Examples include conflicting sources, an unfamiliar contract term, a missing approver, or a value outside a normal range.

Review trigger: What should force a retest? Useful triggers include a policy change, a source migration, three similar corrections, a new audience, or a fixed review date.

The contract is not a second prompt. It is the agreement around the prompt: why it exists, what keeps it trustworthy, and who is responsible when the world changes.

Capture exceptions where people discover them

The most important feedback often appears in ordinary meetings, not in a formal AI review.

A salesperson says the summary omitted a condition that customers now ask about. Finance explains that a once-rare billing arrangement is becoming common. A project lead notices that the skill keeps describing a checkpoint as a deadline. Someone has already built a private workaround that the rest of the team does not know exists.

Do not bury these observations in the recap. Mark them as skill exceptions with four pieces of context:

what the skill produced or failed to produce;
what the person changed;
why the change mattered;
which shared instruction, source, or assumption may be responsible.

This keeps a correction attached to its reasoning. "Changed the date" teaches the owner very little. "Changed October 3 from a delivery date to a legal-review checkpoint because the contract was still conditional" provides evidence that can improve the skill and its tests.

The skill owner can then distinguish a one-off exception from a recurring pattern. That is better than letting every user silently customize the output until the team appears consistent only on paper.

Do not encode every exception

A maintenance loop can become too eager. If every unusual case adds another instruction, the skill grows brittle, contradictory, and hard to test.

Before changing it, ask three questions:

Frequency: Is this likely to recur, or was it genuinely singular?
Consequence: If the skill gets this wrong again, how costly or difficult is the repair?
Detectability: Will an ordinary reviewer notice the error before it matters?

A rare wording preference with low consequence may not deserve a permanent rule. A rare error that could expose a confidential term probably does. A frequent issue that reviewers catch every time still creates friction and should usually be fixed.

Some exceptions belong in the source material rather than the skill. If the approval matrix is outdated, update the matrix. If the team has not decided how to handle a new contract type, record an open policy question. A prompt cannot repair an unresolved operating decision.

Retest with real cases, including the awkward ones

Google says Workspace Studio supports real-time testing before skills are rolled out broadly. Microsoft similarly advises users to review and test AI-generated workflows before production use, and its workflow tools expose run history, outputs, and errors for inspection. Microsoft Workflows guidance

For a team skill, a useful test set should include more than ideal examples:

one normal case;
one case with missing information;
one case with conflicting sources;
one recently reported exception;
one case where the correct behavior is to stop.

Compare the new version with the old one. Did the patch solve the target problem? Did it damage a routine case? Did it make the output more cautious everywhere because one exception was risky?

Keep a short version note: what changed, which evidence prompted it, which cases were tested, and when the next review is due. This is not bureaucracy for its own sake. It gives future users a reason to trust the current version and a place to challenge it.

Give the skill ten minutes on a recurring agenda

A monthly operations, sales, recruiting, or project meeting is often enough. Review the exception log, choose the one or two changes with the highest consequence or recurrence, assign the retest, and close items that do not justify a patch.

Watch a few simple signals: how often people materially rewrite the result, how often the skill stops for the right reason, whether the same correction recurs, and whether users have created unofficial variants. These measures are more revealing than raw usage. A frequently invoked skill can still be quietly expensive if every output needs expert repair.

The aim is not to make a prompt permanent. It is to make change deliberate. Team knowledge stays useful because someone can see where practice and instruction have started to diverge.

Caspi supports real-time meeting assistance, live recap, suggested questions, contextual chat, proactive flags from connected tools, post-call action items, and persistent meeting memory. Those capabilities can help teams preserve the exceptions, corrections, and decisions that should inform a shared AI skill. The maintenance contract turns that meeting evidence into a clear responsibility: notice the drift, test the change, and keep the team's reusable instructions aligned with the work they actually do.