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 requires an active publisher profile, acceptable payout-account state, approved pricing, and accepted refund/dispute terms.
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 payout
Commercial records are modeled before final payment capture and payout-provider automation are connected.
- Usage logs do not pay publishers directly; billable usage posts transactions, transaction splits, and publisher balance rows first.
- The launch default split is 20% platform fee and 80% publisher share unless a newer active commission rule applies to future posting.
- Balances mature after the risk window, then eligible balances can enter payout review. P0 finance completes manual PayPal/Alipay transfers and records the transfer reference; provider payout automation remains deferred.
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; P0 publisher payouts use manual PayPal/Alipay transfer records.
- 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.