Developer Preview terms

Developer Preview operating terms.

These Developer Preview terms cover public discovery, inspection, review, runtime governance, and prelaunch paid-marketplace modeling. Payment capture and automated payouts are not generally available.

Current operating policy for public launch

Publish a skill Read API docs

ScopeRegistry, marketplace, runtime gateway

MoneyPrelaunch ledger model; no general payment capture

TrustReview, incidents, reports, takedowns

DataManifest, runtime, billing, notification records

Buyer and developer use

Developers may discover, save, install, test, and invoke skills only through projects and project-scoped credentials.

Developers should inspect manifest schemas, permissions, pricing, version, review status, incidents, and published feedback before installation.
Project owners remain responsible for approving high-risk permissions, setting budgets, rotating API keys, and adopting reviewed version updates.
Runtime test calls from the console are non-billable unless the product explicitly marks them as paid provider execution.

Publisher responsibilities

Publishers must provide accurate skill contracts and maintain public listings as operational products, not one-time uploads.

Every listing must include display name, description, version, runtime, input/output schemas, permissions, examples, changelog, and support path.
Verified or installed versions are immutable; publishers must create a new semantic version for behavior, schema, permission, pricing, or runtime changes.
Paid publishing remains prelaunch and requires an active publisher profile, finance-reviewed paid-readiness state, approved pricing, and accepted refund/dispute terms before public activation.

Review, safety, and takedown

SkillHub may review, reject, restrict, suspend, deprecate, or remove listings to protect developers, publishers, and the marketplace.

Verification requires automated manifest, runtime, example, and security checks plus a reviewer decision.
Abuse reports, critical incidents, undeclared permissions, malicious runtime behavior, privacy issues, or billing abuse can trigger restriction or suspension.
Suppressed distribution is a ranking action, not a takedown; publishers can use the marketplace appeal workflow when quality gaps are fixed.

Pricing, commission, and paid-marketplace preview

Commercial records are modeled as prelaunch operating state before final payment capture and payout-provider automation are connected.

Usage logs do not pay publishers directly; after paid-marketplace gates, billable usage posts transactions, transaction splits, and publisher balance rows first.
The preview split model is 20% platform fee and 80% publisher share unless a newer active commission rule applies to future posting.
Balance maturity, manual finance review, and PayPal/Alipay transfer references are modeled for paid-marketplace preview. General payment capture and automated payouts remain unavailable.

Refunds and disputes

Refunds and disputes are handled as auditable adjustments instead of editing historical transactions.

Finance operators can approve, reject, post, fail, warn, win, or lose adjustment records with required reasons.
Posted refunds create negative adjustment transactions, negative splits, and reversed publisher balance entries.
Dispute losses can post refund adjustments automatically, while publishers and project operators can inspect scoped adjustment history.

Data retention and privacy posture

SkillHub stores operational records needed for registry trust, runtime governance, billing traceability, and account safety.

Stored records include manifests, versions, review decisions, runtime checks, installs, policies, invocations, usage, ledger entries, notifications, and audit logs.
Raw user tokens, API keys, email verification codes, OAuth secrets, webhook signing secrets, and provider keys must not be exposed after first reveal or through admin lists.
Publishers must declare data retention notes when skills handle user, business, secret, financial, or sensitive operational data.

Incidents, deprecation, and support

Operational failures should create durable signals for developers, publishers, and trust operators.

Runtime incidents can move through open, monitoring, resolved, and postmortem states with severity and decision reason.
Installed-skill update inboxes should show new versions, deprecations, security notes, and incident recovery states before agents are moved.
Publishers should maintain support paths, changelogs, and replacement guidance when versions are deprecated or skills are suspended.

Notifications and webhooks

In-app, email, and webhook notification states are modeled before final email-provider delivery is fully connected.

Users can manage notification preferences for review, update, runtime, billing, payout, buyer-request, and account-security events.
External email and webhook queues expose attempts, provider metadata, retry scheduling, signed webhook delivery, and redacted payload summaries.
Email provider delivery and webhook network delivery must never expose verification codes, tokens, secrets, or sensitive payload fields through admin views.

Deferred final integrations

Some provider integrations are intentionally last so the internal operating model stays stable first.

Payment capture, payment-provider customer sessions, provider-specific payout automation, and tax/KYC automation are deferred; paid-marketplace preview models manual PayPal/Alipay transfer records for future finance review.
Email provider delivery is connected through queued notification events; production readiness requires provider configuration and debug code previews disabled.
Terms may be updated before paid marketplace launch when provider, region, tax, refund-window, KYC, and minimum-payout decisions are finalized.