Skip to main content
This guide is for authors who want to publish their capabilities to the QoderWork public marketplace. It introduces the QoderWork extension ecosystem and the listing requirements for each of the four extension types.

​
QoderWork Extension Ecosystem

QoderWork offers four types of extensions that let users equip AI with capabilities, roles, and external connections on demand, evolving it from a “general-purpose assistant” into a “dedicated agent” tailored to their business. The four types are independent yet composable: Skills provide atomic capabilities, Plugins package capabilities into expert roles, Connectors bridge external systems, and Workbenches host complete interfaces for vertical scenarios.

​
Skill — Atomic Capability

A Skill is the most fundamental capability unit in QoderWork. Each Skill represents a reusable “method” that AI can follow. When a user submits a task that matches a Skill, the AI automatically invokes it and completes the work according to its built-in steps, guidelines, and examples, significantly improving output quality for that specific scenario. Typical use cases: generating PDF reports, drafting professional contracts, interpreting user feedback data, compiling weekly reports, and more. Characteristics: fine-grained, plug-and-play, reusable across multiple Plugins — the building block for higher-level capabilities.

​
Plugin (Expert Suite) — Virtual Role Expert

A Plugin is a collection of capabilities organized around a real-world job function or professional role. It consists of multiple Skills, one or more Connector dependencies, and role instruction documents. Once installed, it gives you a “virtual colleague” in QoderWork who can independently handle the complete workflow for that role. Typical use cases: Super HR (end-to-end recruiting), Super Legal (contract review), Super Finance (reconciliation and anomaly analysis), Super Product Manager (requirements planning), and more. Characteristics: role-centric, with interconnected capabilities and a complete workflow — ideal for complex tasks that require a one-person-army approach.

​
Connector — External System Connector

A Connector is a standardized bridge between QoderWork and a third-party system. It is essentially an MCP Server that supports OAuth authorization. Once installed and authorized, AI can read from and write to the corresponding system within the permissions granted by the user, incorporating external business systems into the workflow. Typical use cases: connecting to DingTalk, Notion, Slack, Jira, enterprise CRM, or custom business systems. Characteristics: service-scoped, with user-controlled authorization, callable by any Skill or Plugin — the key entry point for AI to access real business data.

​
Workbench — Standalone Interface for Vertical Scenarios

A Workbench is a heavier type of extension in QoderWork that provides a standalone work interface and state management for specific professional scenarios. It orchestrates related Skills, Connectors, and custom UI on a single canvas. Compared to the general chat interface, Workbenches are better suited for high-frequency, stateful, multi-task professional workflows. Typical use cases: valuation review workbench, contract review workbench, sales lead dashboard, and more. Characteristics: features a standalone interface with persistent state, targets a single vertical scenario, and supports deeply customized interaction flows — a “dedicated workspace” for professional roles.

​
Listing Requirements

All four extension types share the same self-service listing process: submit within QoderWork, pass review, and get listed on the public marketplace. Once approved, the extension becomes publicly visible and can be managed on an ongoing basis from “My Publications”. The following sections highlight the key requirements specific to each type.

​
Skill Listing Requirements

A Skill’s core value lies in being “accurately understood and reliably reused by AI,” so the review focuses on content quality:
  • Clear content: The description must explain the Skill’s purpose and trigger scenarios in the third person, and include keywords that users are likely to use in natural language, helping AI invoke it at the right time.
  • Sound structure: The body should contain clear usage steps, precautions, and verification methods. Avoid placeholders (such as TODO or <your-token>) or pseudocode that cannot be executed directly.
  • Safe and harmless: Must not contain malicious scripts, suspicious external requests, or privilege-escalation instructions, nor leak real credentials in examples.
Skills are reviewed primarily by automated checks with manual spot-checks as a supplement. Results are typically available within minutes.

​
Plugin (Expert Suite) Listing Requirements

A Plugin represents the complete capabilities of “an expert,” so the review focuses more on the coherence and professionalism of the suite as a whole:
  • Follows suite structure: Must be organized according to the specification, with complete metadata (plugin.json), embedded Skills, and necessary role instruction documents. Each embedded Skill must also be compliant on its own.
  • Organized around a role: The suite name should directly use a real-world job title (2-6 characters). The included Skills and Connectors should have a clear collaborative relationship — avoid simply bundling unrelated capabilities.
  • Resolvable dependencies: Any Connector referenced in the suite must be a valid, currently listed item in the marketplace.
Plugins undergo a client-side structural pre-check before submission. Once the pre-check passes, they enter an automated review process similar to Skills.

​
Connector Listing Requirements

Connectors involve external data access and user authorization, making them the extension type with the strictest review requirements. In principle, each company may submit one official Connector for its own service:
  • OAuth-enabled MCP Server: Must be a publicly reachable HTTPS MCP Server with a complete OAuth authorization flow, ensuring that user access permissions are controllable and revocable.
  • Company identity verification: The submitter must be an authorized representative of the company that owns the service. Identity verification (personal or corporate) must be completed during submission, and the official team will confirm the submitter’s identity via phone.
  • Legal and privacy compliance: Must provide publicly accessible privacy policies and terms of service, and clearly state the scope of data collected and its intended use.
  • Complete self-test report: Must submit a self-test report covering connectivity verification, representative tool invocations, permission scope, error handling, and service availability.
After passing automated review, Connectors enter a mandatory manual final review and are not automatically approved.

​
Workbench Listing Requirements

Workbenches are a more complex extension type that hosts a full interface and business workflow, imposing higher engineering delivery requirements:
  • Follows SDK specification: Must be developed using the official QoderWork Workbench SDK, including a compliant manifest file, UI resources, and MCP Server implementation.
  • Clear vertical focus: Each Workbench should target a single, well-defined professional scenario with a complete input, processing, and output pipeline.
  • Clear resource boundaries: The Skills and Connectors that the Workbench depends on must be explicitly declared within the suite and integrated through the SDK-provided interfaces with proper permission confirmation.
Because Workbenches involve deep customization of interfaces and state, it is recommended to complete end-to-end testing before submission to ensure stable loading and operation within QoderWork.

​
Extension Specifications

This section provides the specific structural and formatting requirements for each extension type. In addition to meeting the listing requirements above, extensions must comply with the specifications listed here to pass review.

​
Skill Specification

Each Skill is organized as a standalone folder, with SKILL.md as its core file and optional reference materials. Directory Structure 
<skill-name>/
├── SKILL.md          # Skill definition file (required)
└── references/       # Reference file directory (optional; for templates, examples, data, and other supporting materials)
    ├── template.md
    └── example.json
SKILL.md Format The file starts with a YAML frontmatter block, followed by Markdown content: 
---
name: contract-review           # Skill identifier (required)
description: Reviews contract clauses and flags risk points. Applicable when a user uploads a contract file and requests a review.  # Functional description (required)
version: 1.0.0                  # Version number (optional)
---
Naming Rules
  • Only lowercase letters, digits, and hyphens (-) are allowed; must not start or end with a hyphen
  • Maximum 64 characters
  • The name serves as the Skill’s unique identifier and cannot be changed after publishing
Version Number Uses Semantic Versioning in the format major.minor.patch, such as 1.2.0. Must be incremented with each new release. Reference Files The references/ directory stores supplementary materials that the Skill may reference during execution, such as document templates, format examples, and dictionary data. Files in this directory are automatically provided as context when AI invokes the Skill — no additional configuration is needed.

​
Plugin (Expert Suite) Specification

A Plugin is organized as a folder that combines multiple Skills, role instructions, and MCP dependencies into a complete role expert. Directory Structure 
<plugin-name>/
├── .qoder-plugin/           # Plugin metadata directory (required)
│   └── plugin.json          # Metadata manifest (required)
├── skills/                  # Skills directory (core)
│   ├── skillA/SKILL.md
│   └── skillB/SKILL.md
├── agents/                  # Subagent role configurations (optional)
│   ├── agentA.md
│   └── agentB.md
├── .mcp.json                # MCP Connector declarations (optional)
├── qoder.md                 # Project instruction file (optional; compatible with cursor.md / claude.md)
├── CONNECTORS.md            # Connector dependency documentation (optional)
└── README.md                # Plugin documentation (optional)
plugin.json Essentials plugin.json declares the suite’s name, version, included Skill manifest, and role information. The name should ideally be a real-world job title, 2-6 characters long. Declarative MCP Connector Configuration (Optional) If Skills within the suite need to call external systems, you can declare the required MCP Server connections in a .mcp.json file. When users install the suite, QoderWork will guide them through the corresponding authorization setup. 
{
  "mcpServers": {
    "DingTalk Logs": {
      "type": "streamable-http",
      "url": "{{USER_CONFIG}}",
      "_setup": {
        "configUrl": "https://aihub.dingtalk.com/#/detail?mcpId=9639",
        "guide": "Visit the link above to log in to DingTalk and obtain your personal MCP Server URL",
        "required": true
      }
    }
  }
}
Field descriptions:
  • type: Transport protocol; supports streamable-http and stdio
  • url: Use {{USER_CONFIG}} as a placeholder, which will be replaced with the actual address when the user installs the suite
  • _setup.configUrl: A link to the page where users can obtain their credentials or server address
  • _setup.guide: Configuration instructions displayed to the user
  • _setup.required: Whether the field is mandatory; when set to true, users cannot use the connection without completing the configuration
This file is optional. If the suite does not depend on any external systems, it can be omitted.

​
Connector Specification and Guidelines

A Connector is essentially a public-facing MCP Server and must meet the following technical and compliance requirements to be listed. Technical Requirements
  • The service address must use HTTPS and be a publicly reachable, stable domain name (internal IPs or temporary tunnels are not accepted)
  • Must implement a complete OAuth 2.0 authorization flow, ensuring that user authorization is controllable and revocable
  • Tool definitions must have clear names and descriptions, and parameters should use JSON Schema to declare types and constraints
  • A health check endpoint is recommended so the platform can monitor service availability

​
After Publishing

Once listed, authors can manage their published extensions from “Settings > My Publications”, including viewing install counts, editing public information, releasing new versions, temporarily delisting, and relisting. Editing public information triggers only a lightweight automated review and does not affect existing users. Releasing a new version goes through the full review process again; existing users will receive an update notification and can choose whether to upgrade. If an extension is rejected, the specific reasons can be found in “My Publications”. You can revise and resubmit as required, or file an appeal if needed. Whether the author voluntarily delists an extension or it is forcibly delisted by the platform, local copies already installed by users will not be forcibly removed. However, the extension will no longer be shown in the marketplace or distributed to new users.
If you have questions about the publishing process or listing requirements, you can contact the review team through the official QoderWork feedback channel.