Flows and the capability marketplace

Three resource types, not one

The marketplace is a single entry point, but flows, skills and MCP use independent resource types, lists, detail views and publish contracts. They must not be collapsed into one untyped catalogue.

A Skill is a set of versioned instructions, reference material, scripts and supporting files that an agent can assemble and use.

MCP is an external tool connection a model can call, in two forms: a remote configuration template and a local immutable image.

A Flow is a dependency graph of node invocations. It is not a capability package, and cannot be published as a skill or an extension.

The skill supply chain

Skills come from three sources, each with a different content authority.

A Git-linked skill takes the specified repository, ref and directory path as its sole content authority. The platform handles discovery, preview, manual or scheduled synchronisation, validation and automatic publishing, and never writes back to Git. One source can discover many skills in bulk through a discovery root, include paths and exclude patterns. A Git path that disappears only marks the source as missing; historical releases are neither deleted nor automatically withdrawn.

If you need to edit such a skill online, you must copy it into a new platform-owned skill.

A ZIP upload keeps the original digest as source evidence. Once extracted it becomes a platform-owned draft that can be inspected, edited and published explicitly. An upload is not a continuing external authority, and offers no reverse synchronisation.

A platform-owned skill takes the platform draft as its content authority. File edits autosave, and revision concurrency control prevents silent overwrites. Only explicit publishing is supported.

The three sources share the package contract at the publish boundary and nowhere else — they do not share a persistence model.

Release and immutability

Every source must satisfy the structural, security, determinism and materialisability constraints at the publish boundary. The root directory mandates only the skill description file, and stays compatible with legacy manifest files.

A release carries an immutable semantic version, a package digest, a source snapshot and audit information.

When Git content changes, each skill publishes automatically and independently; the batch summarises what was published, unchanged, failed and removed, and one failing item does not block the rest.

Tasks still resolve only exact versions and digests from the local registry, and the sandbox does not pull from Git at runtime.

That is the central constraint of the supply chain: the sandbox is forbidden from fetching capability code from the public internet through a package manager at start-up. A cache hit does not excuse skipping content digest verification either.

Asset ownership and promotion

An asset starts in personal scope and can be promoted one way only: personal → workspace → public.

A promotion creates the release at the target tier, migrates asset authority and closes the old scope's write entry in a single atomic state transition. It is not a copy. At any moment an asset has exactly one editable authority.

Maintainers can publish new versions directly. Ordinary members can only view, add, derive or propose changes.

A new asset derived from a fixed release gets a new identity, a new draft and a new version sequence, and retains its immutable upstream source. Upstream synchronisation is an explicit maintenance operation — a three-way merge of the fixed baseline, the target upstream version and the derivation's current draft — not an automatic overwrite or a track-the-latest relationship.

Solidifying a task flow

Any generated flow revision can be saved as a draft, and a failed revision remains available for later correction, but a generated revision cannot be published directly.

Solidifying creates a new flow draft identity and retains the source task, the snapshot revision, the original digest and the execution results.

The solidification wizard must sort the content into three classes — retain, parameterise, delete:

• task-specific values such as repository, branch, requirement, paths and connectors are extracted into flow inputs wherever possible;
• secrets, temporary tokens, user identity and private bodies are deleted without exception, and the user is given no option to retain them.

The parameterised final draft acquires a new digest. The source task's success is therefore provenance information only and cannot stand in for validating the final content.

Before publishing, the final digest must pass deterministic compilation, schema validation, capability visibility, security policy and a representative dry run. Publishing defaults to workspace-private; entering the public marketplace requires additional security, quality, licence and operational review.

Visibility is not installation

Once live authorisation passes, a capability enters the capability set of sandboxes, flows and collaboration directly, with no extra installation, subscription, copy or workspace binding required.

The design removes "installation state", a concept that is easy to get out of sync. It also means that if you lack permission the capability will not appear among the candidates — and that is not because the other side failed to publish it.

Permissions

A system administrator configures Git services and the platform read-only token, and manages public skills.

A workspace administrator manages private skills, Git sources, archives, platform drafts and publishing.

An ordinary member browses, previews and references.

Platform Git tokens are never echoed back, and never enter the browser, a task snapshot, a sandbox or a log.

The lifecycle of a published release

A release that a task has already referenced can only be deprecated or withdrawn — never overwritten or physically deleted.

A deprecated version can still be used by new tasks, but creation warns. A withdrawn version is refused to new task resolution, while running and historical tasks are unaffected.

A tag alias points only at a normally published version, and moves to the latest non-withdrawn version after a withdrawal.

Publishing, withdrawal, tag moves, task resolution, sandbox materialisation, connection readiness and rework refresh all enter the security audit. Secrets, full prompts and session bodies must not.