In this briefing
- 01Process packaging: turn one-off prompts into knowledge that loads on demand
- 02Release lifecycle: skills also need versions, validation and provenance records
- 03Runtime diagnosis: installed, loaded and effective are not the same state
- 04Evidence boundary: an open format does not ensure portability or production safety
- →What to watch next
- ↗Sources and verification
- Snowflake describes skills as reusable units for team-specific processes, while plugins add versioning, CI validation, installation, updates and registry records; this is vendor engineering guidance, not a validated customer outcome.
- Claude Code added the skill-doctor command (/skill-doctor) and organisation-policy loading status, while Codex added the ability to list, install and remove plugins from remote marketplaces. The updates distinguish whether an asset is installed, loaded or actually used by a task.
- An open format lowers the barrier to packaging process knowledge, but the allowed-tools field remains experimental and implementation support varies. Enterprises still need to validate provenance, versions, triggering, context cost, production permissions and rollback independently.
Process packaging: turn one-off prompts into knowledge that loads on demand
On 4 September, Snowflake published CoCo data-engineering guidance that narrows the goal from having an Agent produce a result once to helping a team obtain repeatable, high-quality outcomes. It recommends encoding stable processes through repository-level instructions, skills, subagents, commands, hooks and MCP tools. It also says a skill should capture team practices that the model cannot infer, such as the testing steps, naming conventions or partitioning strategy for a dbt project. This is Snowflake's engineering position for its own product and data-engineering context; it cannot be extrapolated directly to show that every industry has adopted the same method.
Agent Skills documentation defines a skill as a directory containing at least one SKILL.md file, with optional scripts, reference material, templates and other assets. Loading follows progressive disclosure: an Agent first reads the name and description, then reads the complete instructions when a task matches, and loads resources as needed. Procedural knowledge that previously sat in personal prompts or chat histories can therefore gain a file boundary suitable for a repository, version control and review. A common directory structure does not mean that different Agents will execute it with the same semantics.
An enterprise can begin with frequent, stable and readily testable processes, such as data-quality checks, contract-field verification or pre-publication validation, and assign each skill a business owner, maintainer and version. Here, an ‘asset’ is an operational-management concept, not accounting recognition. Its value lies in reviewability and reproducibility, not in loading all tacit knowledge into the context at once. Incorrect triggering, stale references and missing script dependencies still require separate tests.
Release lifecycle: skills also need versions, validation and provenance records
Snowflake presents a plugin as a fuller release unit than an individual skill because it can package skills, subagents, commands, hooks and MCP services. Its stated management features include a manifest version, CI validation, single-unit installation, updates, and registry records for source, installation time and active state. An organisational catalogue can also support internal sharing and discovery. These mechanisms make process knowledge resemble a software artefact, but being validatable means only that structure or rules can be checked by machine; it does not show that business logic, data permissions or output correctness have passed acceptance testing.
OpenAI released Codex 0.153.0 on 3 September and extended the plugin lifecycle to remote marketplaces: the command line can list, install and remove remote plugins, while the app server gained a plugin-reconciliation interface. Remote distribution can make reuse more efficient, but it also broadens supply-chain review. An enterprise needs to know where a plugin came from, which scripts and connectors it contains, whether an update changes permissions, and whether the previous version can be restored. Marketplace visibility must not be treated as evidence of trustworthiness.
Procurement and platform teams can place skills and plugins under existing artefact-management controls: pin the source and version, retain change-review and validation records, separate development, test and production catalogues, and prepare withdrawal, downgrade and dependency-failure paths. If a plugin can carry hooks or external tool connections, review should cover the complete package rather than only SKILL.md.
Runtime diagnosis: installed, loaded and effective are not the same state
Claude Code v2.1.261 was released in the early hours of 5 September Beijing time. It added the skill-doctor command (/skill-doctor) to show skills that were loaded but went unused and the context they cost. The /status command and claude doctor also explain why an organisation's policy could not be loaded, for example when a proxy does not pass the relevant endpoint. The release also fixed a case in which a plugin force-enabled by managed settings was discarded in a cloud session before a fallback marketplace copy could still fail. These release notes expose observability and state-consistency issues; they are not an independent security audit.
In the same release cycle, Codex scoped remembered MCP tool approvals to the selected app account. Together with the policy-loading state in Claude Code, this shows that runtime process assets involve at least the package version, trigger match, context use, organisation policy, connected account and session environment. Checking only that a file exists or a plugin is enabled cannot show that a task actually used the intended process, or that it called the correct account within the intended permission boundary.
Release acceptance should record skill hit rate, reasons for non-use, context budget, policy-loading result, connected account, tool-call trace and final business validation rather than only an installation-success message. Each diagnostic also needs an owner and response: a high-risk task should stop if policy loading fails, descriptions and routing should be checked when a skill does not trigger, and regression tests should run again when versions drift.
Evidence boundary: an open format does not ensure portability or production safety
The Agent Skills specification permits a compatibility declaration in frontmatter and provides an experimental allowed-tools field, while explicitly warning that support for the latter may vary between implementations. It also says an Agent loads the complete SKILL.md after deciding to activate a skill and recommends keeping the main file below 500 lines. A growing number of skills is therefore not cost-free. The same file may also produce different results across models, clients, tool permissions and dependency environments.
In the same article, Snowflake explicitly advises that an Agent should not change production directly and should instead use established deployment and change-management tools such as dbt, schemachange, Flyway and Terraform, because content generated while the Agent runs is non-deterministic. This negative boundary matters more than the label ‘reusable’. No published independent benchmark shows that skills or plugins improve production defect rates, delivery times or compliance outcomes, and there is no evidence that cross-product migration removes the need for renewed testing.
A more cautious sequence is to reproduce one defined process in an isolated environment, then test missing dependencies, stale material, incorrect triggers, malicious packages and migration between clients. Only then should approved actions connect to existing CI/CD and permission systems. A process asset should help contain uncertainty; it cannot bypass production change control.
What to watch next
- Snowflake CoCo's plugin-catalogue permission model, signature or provenance checks, version rollback, and published customer results for data-pipeline reproducibility and defect rates.
- Whether Claude Code can expose the skill-doctor command (/skill-doctor) and organisation-policy diagnostics as machine-readable records for enterprise monitoring, audit and policy blocking.
- Tests of the same Agent Skills package across clients, covering triggering, tool authorisation, dependency resolution, context cost and output consistency.
Sources and verification
Golden Data has edited this briefing from the public materials listed above. The original sources govern facts and figures. The enterprise relevance sections are Golden Data editorial analysis and do not constitute an endorsement of any third-party product.
← Back to AI Daily Briefing