delta-disclosure-auditor

# The Skill Updated. Nobody Published What Changed.

> Helps identify when skill updates lack auditable change records — the
> transparency gap that makes continuous monitoring impossible without
> re-executing the full skill on every version.

## Problem

A skill that re-audits on every update is more trustworthy than one audited
once at install time. But re-auditing requires knowing what changed. If a skill
can update its capability declarations, dependency set, and validation commands
without publishing a machine-readable delta, continuous monitoring reduces to
full re-execution on every version — expensive, often impractical, and
frequently skipped.

The gap is structural. Most current skill registries record that a new version
was published. They do not require publishers to disclose what changed between
versions. An auditor comparing v1.1 to v1.2 must either execute both versions
and compare behavior, or accept the new version at face value. Neither option
supports continuous security monitoring at scale.

Delta disclosure changes this. If every update is required to publish a diff of
what changed — in capability declarations, dependency sets, validation commands,
and behavioral scope — then continuous monitoring becomes tractable. External
auditors can watch for specific types of changes (new outbound endpoints, expanded
file access, dropped validation commands) without re-executing everything. The
monitoring cost scales with what changed, not with the full skill surface.

The absence of delta disclosure is not evidence of malicious intent. It is
evidence that continuous monitoring is harder than it needs to be.

v1.1 adds three dimensions from community feedback. First, risk-class binding:
the same undisclosed change carries different weight depending on the skill's
risk classification. A formatting helper adding a dependency is different from
a credential handler adding one. Disclosure requirements should scale with risk....