Skip to main content
Employee Resources

Skills and Connectors

Install Skills, connect external services, and assign resources to Wakers with least-privilege access.

Capabilities & Resources centrally manages reusable Skills, connectors, knowledge bases, WakerFlows, and public projects. A Skill defines a repeatable working method; a connector lets a Waker call an external application, MCP service, or built-in tool. A resource appearing in the marketplace or My resources does not mean every Waker can use it. The complete path is: install or create → assign to a Waker → check permissions → validate in a new chat.

Open Capabilities & Resources

Path: left navigation → Capabilities & Resources. Use the tabs to switch resource types. A Waker's Skills and Connectors pages manage only the resources assigned to that Waker.
Skill marketplace

Choose the right resource

NeedUse
Apply a repeatable method to a class of tasksSkill
Access an external app, account, or MCP serviceConnector
Search stable information repeatedlyKnowledge Base
Orchestrate multi-stage or multi-Waker workWakerFlow
Provide a reusable code or document workspaceProject
Do not store tokens in a Skill, and do not use a connector description as a business knowledge base.

Install a Skill from the marketplace

  1. Open SkillsSkill Marketplace.
  2. Search or filter for the capability. Install counts and recommendations are signals, not a security review.
  3. Open the detail page and read the use cases, triggers, source, included files, and scripts.
  4. Confirm that file access, network access, and external tools are appropriate for the environment.
  5. Install the Skill and check its status and version under My Skills.
  6. Open the target Waker → Skills and add or confirm the Skill.
  7. Start a new chat and run one low-risk task that directly matches the Waker's responsibility.
Installation is complete only when the intended Waker recognizes the use case, follows the expected method, and does not access objects outside the permitted scope.

Upload your own Skill

Use the upload entry in the resource center or the target Waker. Depending on the page, the package can be a Markdown file or an archive containing SKILL.md and required resources. Before uploading, check:
  • the name, description, and trigger conditions in SKILL.md;
  • scripts that write files, access the network, or invoke commands;
  • relative paths and required bundled resources;
  • credentials, personal data, and private addresses;
  • conflicts with instructions in existing Skills.
Validate the package on a test Waker first. After changing its structure or scripts, upload the new version and rerun a fixed regression task.

Manage self-evolving Skills

Path: Waker Management → target Waker → Memory & LearningSelf-evolving Skill. Self-evolution turns a successfully completed complex task into a reusable way of working. When enabled, the Waker reviews suitable completed tasks, updates an existing evolving Skill first, and creates a new Skill only when necessary. This page contains Skills summarized by the Waker during tasks and uploaded Skills for which Allow self-evolution was explicitly enabled.
  1. Turn on the Waker-level switch. Turning it off stops new chat-driven creation and updates, but does not delete existing Skills.
  2. For an uploaded Skill, open its details and enable Allow self-evolution only when the Waker may improve that package. Leave it read-only when the original content must remain fixed.
  3. Complete a complex task with clear inputs, steps, and an accepted result. Ordinary questions normally do not produce a reusable Skill.
  4. Return to this page and verify that the new or updated Skill describes the right trigger, procedure, boundaries, and completion criteria.
  5. Run a similar but not identical task to confirm that the Waker applies the Skill in the right situation instead of forcing it onto unrelated work.
Self-evolution does not replace human review. Methods involving external sending, publishing, deletion, production operations, or sensitive data still need permission controls and human approval. Edit, disable evolution, or roll back when a Skill captures an accidental path, overgeneralizes one task, or retains information that should not persist.

Inspect history and roll back

For Skills that support version management:
  1. Open the Skill details and select History.
  2. Select a version and inspect its summary and file diff. Identify whether it came from creation, editing, self-evolution, or rollback.
  3. Choose the required historical version and roll back.
  4. Start a new chat and rerun a fixed task to verify the active content.
Rollback changes the active Skill content; it does not undo tasks or external operations that already used that Skill. If the page reports an evolution conflict, compare the current and proposed versions, then keep the current version, accept the proposal, or merge manually. Do not overwrite without reading the diff.

Update, replace, or uninstall a Skill

  1. Identify Wakers, Autonomous Work items, and WakerFlows that depend on it.
  2. Review changes to inputs, tools, and permission scope.
  3. Update one test Waker and run the fixed sample.
  4. Expand the update only after the result is confirmed.
  5. Before uninstalling, remove or replace the Skill in dependent workflows.
Existing chats can retain previous context. Validate updates in a new chat.

Install a connector

Connector marketplace
  1. Open ConnectorsConnector Marketplace.
  2. Review supported tools, authentication, permission scope, edition, and environment requirements.
  3. Select install or connect, then complete OAuth, QR-code, credential, or local-command authorization as prompted.
  4. Confirm the connection under My Connectors. If tool switches are available, enable only the tools needed for current work.
  5. Add the connector under the target Waker → Connectors.
  6. Validate with a read-only query or test object before enabling write, send, or delete operations.
Marketplace availability varies by CN or Global edition, account, version, and feature flag. Follow the connector types shown in the product.

Understand connector states

StateMeaningStill verify
InstalledThe connector is present in ResourcesIt may still need sign-in, authorization, or Waker assignment
AuthorizedThe external account or local service is authenticatedThe scope is sufficient but not excessive
EnabledThe target Waker can see the connectorTools are available and the test uses a new chat
Connected / HealthyThe connector runtime can communicateA read-only task returns the expected result
Installed does not mean ready. Troubleshoot in the order install → authorize → enable → connect → invoke.

Configure Browser Connector

Browser Connector lets a Waker read or operate authorized browser tabs for page checks, form assistance, and web research. It does not automatically receive the entire browsing history and works only in a connected, authorized browser environment.

1. Install and assign

  1. Search for Browser Connector in the marketplace, open its details, and install it.
  2. Select the Waker that needs browser access.
  3. Open Browser Connector under My Connectors. The first-use view provides extension installation and connection guidance.
Prefer the extension-store link shown by the product. If manual loading is required, enable developer mode in the browser's extension manager, choose Load unpacked, and select the directory provided by the product. Do not download a same-named extension from an untrusted source.

2. Connect and inspect tabs

  1. Open the web page that the Waker should use.
  2. Select the Browser Connector extension and connect it to the current QoderWake instance.
  3. Return to connector details and confirm a Connected or Healthy state and the expected available tab.
  4. Resolve Not authorized, Disconnected, or Version incompatible states directly; do not expand Waker permissions to bypass a connection problem.

3. Validate with a read-only task

Start a new chat and ask the Waker to read the title and summarize the structure of the currently authorized tab. Confirm it selected the intended tab before testing clicks, typing, or downloads. Sending, submitting, deleting, purchasing, publishing, and account-setting changes are high-impact browser operations. The Waker should state the target, impact, and recovery plan, then wait for human confirmation.

Add a custom MCP connector

When the page provides manual or JSON configuration:
  1. Obtain the confirmed configuration format from the service provider.
  2. Use a trusted command, server address, and startup arguments.
  3. Put credentials in protected fields or environment variables, not task text or ordinary JSON.
  4. Restrict accessible directories, network destinations, and tool names.
  5. Save, check the discovered tool count, and execute one read-only call.
When the tool count is zero, check service startup, configuration syntax, networking, and authentication before expanding permissions.

Assign resources to a Waker

The resource center answers “what capabilities are available”; a Waker detail page answers “what this Waker may use.”
  1. Open the target Waker's Skills or Connectors page.
  2. Select Add and choose an installed resource.
  3. Confirm that the resource matches the Waker's role.
  4. Open Permissions and verify that file, tool, and model safety rules remain limited.
  5. Validate in a new chat.
One connector can be assigned to several Wakers, but every Waker still follows its own responsibility and permission boundary.

Credential and permission safety

  • Start with read-only access, a test account, and the smallest scope.
  • Keep human confirmation for external sending, deletion, publishing, payments, and production changes.
  • Never put secrets, tokens, or cookies in tasks, memory, knowledge bases, role files, or screenshots.
  • Compare the authorization screen with the actual tools; reject permissions that are not required.
  • Before removing a connector, check dependent Wakers, Autonomous Work, and WakerFlows.

Troubleshooting

SymptomCheck
Resource not foundSearch/filter → CN or Global edition and account → version and feature flag
Installed but unusedAssigned Waker → new chat → role and trigger description
Connector not authorizedRepeat authentication → account permission → network and edition
Browser Connector cannot find a tabExtension installed and enabled → current instance connected → tab authorized → connection refreshed
No tools discoveredService state → configuration → authentication → network
Call rejectedWaker permission → connector permission → external object permission
Automation fails after updateSkill/connector version → changed inputs or tools → rerun the workflow
Completion check: the resource is available, the target Waker uses the correct capability in a new chat, permissions remain minimal, and test objects are not confused with production objects.