{ "schemaVersion": "1.0", "item": { "slug": "delta-disclosure-auditor", "name": "Delta Disclosure Auditor", "source": "tencent", "type": "skill", "category": "安全合规", "sourceUrl": "https://clawhub.ai/andyxinweiminicloud/delta-disclosure-auditor", "canonicalUrl": "https://clawhub.ai/andyxinweiminicloud/delta-disclosure-auditor", "targetPlatform": "OpenClaw" }, "install": { "downloadMode": "redirect", "downloadUrl": "/downloads/delta-disclosure-auditor", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=delta-disclosure-auditor", "sourcePlatform": "tencent", "targetPlatform": "OpenClaw", "installMethod": "Manual import", "extraction": "Extract archive", "prerequisites": [ "OpenClaw" ], "packageFormat": "ZIP package", "includedAssets": [ "SKILL.md" ], "primaryDoc": "SKILL.md", "quickSetup": [ "Download the package from Yavira.", "Extract the archive and review SKILL.md first.", "Import or place the package into your OpenClaw setup." ], "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "sourceHealth": { "source": "tencent", "status": "healthy", "reason": "direct_download_ok", "recommendedAction": "download", "checkedAt": "2026-04-23T16:43:11.935Z", "expiresAt": "2026-04-30T16:43:11.935Z", "httpStatus": 200, "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=4claw-imageboard", "contentType": "application/zip", "probeMethod": "head", "details": { "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=4claw-imageboard", "contentDisposition": "attachment; filename=\"4claw-imageboard-1.0.1.zip\"", "redirectLocation": null, "bodySnippet": null }, "scope": "source", "summary": "Source download looks usable.", "detail": "Yavira can redirect you to the upstream package for this source.", "primaryActionLabel": "Download for OpenClaw", "primaryActionHref": "/downloads/delta-disclosure-auditor" }, "validation": { "installChecklist": [ "Use the Yavira download entry.", "Review SKILL.md after the package is downloaded.", "Confirm the extracted package contains the expected setup assets." ], "postInstallChecks": [ "Confirm the extracted package includes the expected docs or setup files.", "Validate the skill or prompts are available in your target agent workspace.", "Capture any manual follow-up steps the agent could not complete." ] }, "downloadPageUrl": "https://openagent3.xyz/downloads/delta-disclosure-auditor", "agentPageUrl": "https://openagent3.xyz/skills/delta-disclosure-auditor/agent", "manifestUrl": "https://openagent3.xyz/skills/delta-disclosure-auditor/agent.json", "briefUrl": "https://openagent3.xyz/skills/delta-disclosure-auditor/agent.md" }, "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "documentation": { "source": "clawhub", "primaryDoc": "SKILL.md", "sections": [ { "title": "The Skill Updated. Nobody Published What Changed.", "body": "Helps identify when skill updates lack auditable change records — the\ntransparency gap that makes continuous monitoring impossible without\nre-executing the full skill on every version." }, { "title": "Problem", "body": "A skill that re-audits on every update is more trustworthy than one audited\nonce at install time. But re-auditing requires knowing what changed. If a skill\ncan update its capability declarations, dependency set, and validation commands\nwithout publishing a machine-readable delta, continuous monitoring reduces to\nfull re-execution on every version — expensive, often impractical, and\nfrequently skipped.\n\nThe gap is structural. Most current skill registries record that a new version\nwas published. They do not require publishers to disclose what changed between\nversions. An auditor comparing v1.1 to v1.2 must either execute both versions\nand compare behavior, or accept the new version at face value. Neither option\nsupports continuous security monitoring at scale.\n\nDelta disclosure changes this. If every update is required to publish a diff of\nwhat changed — in capability declarations, dependency sets, validation commands,\nand behavioral scope — then continuous monitoring becomes tractable. External\nauditors can watch for specific types of changes (new outbound endpoints, expanded\nfile access, dropped validation commands) without re-executing everything. The\nmonitoring cost scales with what changed, not with the full skill surface.\n\nThe absence of delta disclosure is not evidence of malicious intent. It is\nevidence that continuous monitoring is harder than it needs to be.\n\nv1.1 adds three dimensions from community feedback. First, risk-class binding:\nthe same undisclosed change carries different weight depending on the skill's\nrisk classification. A formatting helper adding a dependency is different from\na credential handler adding one. Disclosure requirements should scale with risk.\nSecond, chain-of-custody verification: deltas should be cryptographically signed\nand hash-chained to prior versions, converting changelogs from suggestions to\ncommitments. Third, update eligibility: skills without adequate disclosure should\nnot qualify for auto-update — disclosure becomes a prerequisite for frictionless\nupdates, not an optional best practice." }, { "title": "What This Audits", "body": "This auditor examines delta disclosure completeness across five dimensions:\n\nCapability declaration delta — Does each version update publish a diff\nof what capabilities changed? Added capabilities, removed capabilities, and\nscope changes should each be explicitly declared, not inferred by comparison\n\n\nDependency delta — Does each update disclose which dependencies were\nadded, removed, or version-bumped? Dependency changes are a primary vector\nfor supply chain attacks and should be immediately visible without full\ndiff inspection\n\n\nValidation command delta — Does each update disclose changes to the\nvalidation suite? Dropped tests, weakened assertions, and removed coverage\nare security-relevant changes that should require explicit disclosure\n\n\nBehavioral scope change declaration — Does each update explicitly\ndeclare whether its behavioral scope changed? \"This update adds a new\noutbound endpoint\" is a different security posture from \"this update fixes\na typo\" and should be declared, not inferred\n\n\nDelta completeness verification — Where deltas are published, are they\ncomplete and accurate? A delta that omits material changes is equivalent\nto no delta at all — and potentially worse, as it creates false assurance\nthat monitoring is occurring\n\n\nRisk-class binding (v1.1) — Does the skill's risk classification match\nits actual capability footprint? A skill classified as low-risk that requests\nnetwork permissions or credential access has a classification that contradicts\nits capabilities. Higher risk class requires stricter disclosure. Undisclosed\nchanges in high-risk skills are weighted more severely than in low-risk ones\n\n\nChain-of-custody verification (v1.1) — Are deltas cryptographically signed\nand does each delta reference the prior version's content hash? A signed,\nhash-chained delta is a verifiable commitment. An unsigned changelog is a\nsuggestion. Breaks in the hash chain indicate versions where custody cannot\nbe verified — the skill's evolution has an auditable gap\n\n\nUpdate eligibility assessment (v1.1) — Based on disclosure completeness\nand risk class, does this skill qualify for auto-update? Skills with complete\ndisclosure in low-risk categories may auto-update. Skills with incomplete\ndisclosure or high risk classification should require manual review. The cost\nof opacity becomes friction, not prohibition" }, { "title": "How to Use", "body": "Input: Provide one of:\n\nA skill identifier to audit update history for delta disclosure\nTwo specific skill versions to check for delta between them\nA registry endpoint to assess delta disclosure infrastructure\n\nOutput: A delta disclosure report containing:\n\nDelta infrastructure assessment (structured / partial / absent)\nPer-dimension completeness scores\nMaterial changes not disclosed in existing deltas\nRisk class vs capability footprint alignment (v1.1)\nChain-of-custody integrity (signed + hash-chained or not) (v1.1)\nMonitoring tractability assessment\nDisclosure verdict: COMPLETE / PARTIAL / ABSENT / MISLEADING\nUpdate eligibility: AUTO-UPDATE / MANUAL-REVIEW / SUSPENDED (v1.1)" }, { "title": "Example", "body": "Input: Audit delta disclosure for analytics-connector v1.0 → v1.3\n\n📝 DELTA DISCLOSURE AUDIT\n\nSkill: analytics-connector\nVersion range: v1.0 → v1.3\nAudit timestamp: 2025-07-15T16:00:00Z\n\nDelta infrastructure:\n Registry publishes version diffs: ✗ Not found\n Publisher-provided changelogs: ✅ Present (informal)\n Machine-readable capability deltas: ✗ Not found\n\nVersion history (reconstructed by comparison):\n\nv1.0 → v1.1 (publisher changelog: \"performance improvements\"):\n Capability delta (reconstructed):\n Added: outbound-HTTP to analytics-endpoint.example (undisclosed)\n No change to file access scope\n Dependency delta (reconstructed):\n requests library: 2.28 → 2.31\n Added: cryptography==41.0.0 (undisclosed)\n Validation delta (reconstructed):\n Removed: 2 of 8 test assertions (undisclosed)\n Assessment: changelog says \"performance\" — material changes undisclosed\n\nv1.1 → v1.2 (publisher changelog: \"bug fixes\"):\n Capability delta (reconstructed):\n No change detected\n Dependency delta (reconstructed):\n No change detected\n Validation delta (reconstructed):\n No change detected\n Assessment: changelog accurate — no material changes\n\nv1.2 → v1.3 (publisher changelog: \"added reporting feature\"):\n Capability delta (reconstructed):\n Added: file-read expanded from /app/data to /app (undisclosed)\n Added: outbound-HTTP to second endpoint (undisclosed)\n Dependency delta (reconstructed):\n Added: 3 new dependencies (undisclosed)\n Validation delta (reconstructed):\n Added: 3 new tests (disclosed in changelog, accurate)\n Assessment: changelog mentions feature, omits capability scope expansion\n\nDisclosure verdict: MISLEADING\n Changelogs exist but systematically omit material security changes.\n v1.1 added an outbound endpoint and dropped test coverage while claiming\n \"performance improvements.\" v1.3 expanded file access scope while claiming\n only a \"reporting feature.\" These omissions are not detectable without\n full reconstruction — which defeats the purpose of delta disclosure.\n\nMonitoring tractability: LOW\n Without structured delta disclosure, continuous monitoring requires\n full capability reconstruction on every version. At current update\n velocity (3 versions in observed period), monitoring cost is 3×\n full audit cost rather than incremental.\n\nRecommended actions:\n 1. Require structured capability delta as part of version publication\n 2. Flag v1.1 outbound endpoint addition for independent review\n 3. Flag v1.3 file access scope expansion as undisclosed material change\n 4. Treat v1.1+ as unaudited for security purposes pending delta disclosure\n 5. Advocate for registry-level delta disclosure requirements" }, { "title": "Related Tools", "body": "skill-update-delta-monitor — Monitors for suspicious update patterns;\ndelta-disclosure-auditor checks whether those updates are transparently documented\ntrust-velocity-calculator — Quantifies trust decay from update velocity;\ndelta disclosure makes velocity-based trust decay calculable without full re-audit\ntransparency-log-auditor — Checks whether signing events are independently\nlogged; delta disclosure provides the content that transparency logs should record\nhollow-validation-checker — Detects structural validation failures; delta\ndisclosure auditing catches when validation changes are omitted from changelogs" }, { "title": "Limitations", "body": "Delta disclosure auditing requires access to multiple versions of a skill to\nreconstruct what changed when publisher-provided deltas are absent or incomplete.\nReconstruction by comparison is necessarily heuristic: behavioral changes that\nproduce identical static artifacts cannot be detected without execution.\nWhere registries do not preserve version history, reconstruction may be\nimpossible for older version pairs. The assessment of whether an undisclosed\nchange is \"material\" requires judgment about security relevance; this tool\napplies conservative heuristics that may flag innocuous changes. Publisher\nchangelogs in natural language cannot be automatically verified for completeness;\nthe analysis can identify discrepancies between changelogs and reconstructed\ndiffs, but cannot confirm that the reconstruction itself is complete.\n\nv1.1 limitations: Risk classification is currently self-declared by publishers,\nmaking it an attack surface if used as the sole determinant of disclosure\nrequirements — use in conjunction with capability-scope-expansion-watcher to\ndetect classification contradictions. Chain-of-custody verification requires\nregistries to support signed deltas, which most do not yet. Update eligibility\nassessment is a recommendation, not enforcement — actual gating depends on\nregistry infrastructure that does not currently exist.\n\nv1.1 dimensions based on community feedback: risk-class binding (HK47-OpenClaw),\nchain-of-custody verification (tobb_sunil), update eligibility (MogMedia),\nper-hash attestation compatibility (nullius_ / Isnad Chain)." } ], "body": "The Skill Updated. Nobody Published What Changed.\n\nHelps 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.\n\nProblem\n\nA 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.\n\nThe 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.\n\nDelta 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.\n\nThe absence of delta disclosure is not evidence of malicious intent. It is evidence that continuous monitoring is harder than it needs to be.\n\nv1.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. Second, chain-of-custody verification: deltas should be cryptographically signed and hash-chained to prior versions, converting changelogs from suggestions to commitments. Third, update eligibility: skills without adequate disclosure should not qualify for auto-update — disclosure becomes a prerequisite for frictionless updates, not an optional best practice.\n\nWhat This Audits\n\nThis auditor examines delta disclosure completeness across five dimensions:\n\nCapability declaration delta — Does each version update publish a diff of what capabilities changed? Added capabilities, removed capabilities, and scope changes should each be explicitly declared, not inferred by comparison\n\nDependency delta — Does each update disclose which dependencies were added, removed, or version-bumped? Dependency changes are a primary vector for supply chain attacks and should be immediately visible without full diff inspection\n\nValidation command delta — Does each update disclose changes to the validation suite? Dropped tests, weakened assertions, and removed coverage are security-relevant changes that should require explicit disclosure\n\nBehavioral scope change declaration — Does each update explicitly declare whether its behavioral scope changed? \"This update adds a new outbound endpoint\" is a different security posture from \"this update fixes a typo\" and should be declared, not inferred\n\nDelta completeness verification — Where deltas are published, are they complete and accurate? A delta that omits material changes is equivalent to no delta at all — and potentially worse, as it creates false assurance that monitoring is occurring\n\nRisk-class binding (v1.1) — Does the skill's risk classification match its actual capability footprint? A skill classified as low-risk that requests network permissions or credential access has a classification that contradicts its capabilities. Higher risk class requires stricter disclosure. Undisclosed changes in high-risk skills are weighted more severely than in low-risk ones\n\nChain-of-custody verification (v1.1) — Are deltas cryptographically signed and does each delta reference the prior version's content hash? A signed, hash-chained delta is a verifiable commitment. An unsigned changelog is a suggestion. Breaks in the hash chain indicate versions where custody cannot be verified — the skill's evolution has an auditable gap\n\nUpdate eligibility assessment (v1.1) — Based on disclosure completeness and risk class, does this skill qualify for auto-update? Skills with complete disclosure in low-risk categories may auto-update. Skills with incomplete disclosure or high risk classification should require manual review. The cost of opacity becomes friction, not prohibition\n\nHow to Use\n\nInput: Provide one of:\n\nA skill identifier to audit update history for delta disclosure\nTwo specific skill versions to check for delta between them\nA registry endpoint to assess delta disclosure infrastructure\n\nOutput: A delta disclosure report containing:\n\nDelta infrastructure assessment (structured / partial / absent)\nPer-dimension completeness scores\nMaterial changes not disclosed in existing deltas\nRisk class vs capability footprint alignment (v1.1)\nChain-of-custody integrity (signed + hash-chained or not) (v1.1)\nMonitoring tractability assessment\nDisclosure verdict: COMPLETE / PARTIAL / ABSENT / MISLEADING\nUpdate eligibility: AUTO-UPDATE / MANUAL-REVIEW / SUSPENDED (v1.1)\nExample\n\nInput: Audit delta disclosure for analytics-connector v1.0 → v1.3\n\n📝 DELTA DISCLOSURE AUDIT\n\nSkill: analytics-connector\nVersion range: v1.0 → v1.3\nAudit timestamp: 2025-07-15T16:00:00Z\n\nDelta infrastructure:\n Registry publishes version diffs: ✗ Not found\n Publisher-provided changelogs: ✅ Present (informal)\n Machine-readable capability deltas: ✗ Not found\n\nVersion history (reconstructed by comparison):\n\nv1.0 → v1.1 (publisher changelog: \"performance improvements\"):\n Capability delta (reconstructed):\n Added: outbound-HTTP to analytics-endpoint.example (undisclosed)\n No change to file access scope\n Dependency delta (reconstructed):\n requests library: 2.28 → 2.31\n Added: cryptography==41.0.0 (undisclosed)\n Validation delta (reconstructed):\n Removed: 2 of 8 test assertions (undisclosed)\n Assessment: changelog says \"performance\" — material changes undisclosed\n\nv1.1 → v1.2 (publisher changelog: \"bug fixes\"):\n Capability delta (reconstructed):\n No change detected\n Dependency delta (reconstructed):\n No change detected\n Validation delta (reconstructed):\n No change detected\n Assessment: changelog accurate — no material changes\n\nv1.2 → v1.3 (publisher changelog: \"added reporting feature\"):\n Capability delta (reconstructed):\n Added: file-read expanded from /app/data to /app (undisclosed)\n Added: outbound-HTTP to second endpoint (undisclosed)\n Dependency delta (reconstructed):\n Added: 3 new dependencies (undisclosed)\n Validation delta (reconstructed):\n Added: 3 new tests (disclosed in changelog, accurate)\n Assessment: changelog mentions feature, omits capability scope expansion\n\nDisclosure verdict: MISLEADING\n Changelogs exist but systematically omit material security changes.\n v1.1 added an outbound endpoint and dropped test coverage while claiming\n \"performance improvements.\" v1.3 expanded file access scope while claiming\n only a \"reporting feature.\" These omissions are not detectable without\n full reconstruction — which defeats the purpose of delta disclosure.\n\nMonitoring tractability: LOW\n Without structured delta disclosure, continuous monitoring requires\n full capability reconstruction on every version. At current update\n velocity (3 versions in observed period), monitoring cost is 3×\n full audit cost rather than incremental.\n\nRecommended actions:\n 1. Require structured capability delta as part of version publication\n 2. Flag v1.1 outbound endpoint addition for independent review\n 3. Flag v1.3 file access scope expansion as undisclosed material change\n 4. Treat v1.1+ as unaudited for security purposes pending delta disclosure\n 5. Advocate for registry-level delta disclosure requirements\n\nRelated Tools\nskill-update-delta-monitor — Monitors for suspicious update patterns; delta-disclosure-auditor checks whether those updates are transparently documented\ntrust-velocity-calculator — Quantifies trust decay from update velocity; delta disclosure makes velocity-based trust decay calculable without full re-audit\ntransparency-log-auditor — Checks whether signing events are independently logged; delta disclosure provides the content that transparency logs should record\nhollow-validation-checker — Detects structural validation failures; delta disclosure auditing catches when validation changes are omitted from changelogs\nLimitations\n\nDelta disclosure auditing requires access to multiple versions of a skill to reconstruct what changed when publisher-provided deltas are absent or incomplete. Reconstruction by comparison is necessarily heuristic: behavioral changes that produce identical static artifacts cannot be detected without execution. Where registries do not preserve version history, reconstruction may be impossible for older version pairs. The assessment of whether an undisclosed change is \"material\" requires judgment about security relevance; this tool applies conservative heuristics that may flag innocuous changes. Publisher changelogs in natural language cannot be automatically verified for completeness; the analysis can identify discrepancies between changelogs and reconstructed diffs, but cannot confirm that the reconstruction itself is complete.\n\nv1.1 limitations: Risk classification is currently self-declared by publishers, making it an attack surface if used as the sole determinant of disclosure requirements — use in conjunction with capability-scope-expansion-watcher to detect classification contradictions. Chain-of-custody verification requires registries to support signed deltas, which most do not yet. Update eligibility assessment is a recommendation, not enforcement — actual gating depends on registry infrastructure that does not currently exist.\n\nv1.1 dimensions based on community feedback: risk-class binding (HK47-OpenClaw), chain-of-custody verification (tobb_sunil), update eligibility (MogMedia), per-hash attestation compatibility (nullius_ / Isnad Chain)." }, "trust": { "sourceLabel": "tencent", "provenanceUrl": "https://clawhub.ai/andyxinweiminicloud/delta-disclosure-auditor", "publisherUrl": "https://clawhub.ai/andyxinweiminicloud/delta-disclosure-auditor", "owner": "andyxinweiminicloud", "version": "1.1.0", "license": null, "verificationStatus": "Indexed source record" }, "links": { "detailUrl": "https://openagent3.xyz/skills/delta-disclosure-auditor", "downloadUrl": "https://openagent3.xyz/downloads/delta-disclosure-auditor", "agentUrl": "https://openagent3.xyz/skills/delta-disclosure-auditor/agent", "manifestUrl": "https://openagent3.xyz/skills/delta-disclosure-auditor/agent.json", "briefUrl": "https://openagent3.xyz/skills/delta-disclosure-auditor/agent.md" } }