Community Skill

The OAN community skill is the AI-assistant path for ordinary adoption tasks. It helps users prepare registration material, choose resource fields, query Discovery, inspect lifecycle, and understand verification evidence. It should make OAN easier to try without turning public users into node operators.

The skill’s boundary is important. Community skill workflows should focus on resource registration and Discovery against official or user-configured compatible nodes. Official operations, private server deployment, chain upgrades, governance voting, and pressure testing belong to official operations skills, not the community package.

This boundary protects the community package from becoming a confusing operator toolbox. A community user should open the skill and see help for publishing and finding resources. They should not be exposed to private governance keys, server SSH details, or official deployment runbooks.

OAN ecosystem map

What the Skill Should Help With

Workflow What the assistant can do
Prepare a resource Ask for resource type, description, endpoint or package, domains, tags, version, and DID material.
Validate input Point out missing domains, vague tags, unsupported resource type, or endpoint mismatch.
Register Submit through official baseUrl or a configured third-party node.
Discover Build queries, add filters, call Discovery, and summarize candidates.
Inspect lifecycle Explain whether a resource is submitted, Root-accepted, published, indexed, active, superseded, or revoked.
Explain evidence Show what needs verification before install, connection, or invocation.

The skill should use the SDK where possible so behavior stays consistent with application code. It should not duplicate protocol logic in fragile shell snippets.

When the SDK is missing a helper, the skill can document the gap and use a narrow fallback, but the long-term direction should be SDK-backed. That keeps registration, Discovery, endpoint configuration, and verification behavior aligned across web, scripts, and assistant workflows.

Configuration

The skill should default to the official baseUrl, because that is the easiest public path. It should also allow a user to configure a third-party baseUrl or explicit Registrar and Discovery endpoints. The assistant should repeat the target endpoint before performing a write action, because users need to know where their resource is being submitted.

For read-only Discovery queries, configuration can be lighter, but it should still be visible. A result from one Discovery node may differ from another because of domain scope, lifecycle, indexing, or ranking.

Configuration should also support migration. The default official baseUrl may change when the public service moves from a temporary IP to a domain. Users who configure a third-party node should be able to update one setting rather than edit every workflow prompt.

Registration Workflow

A good registration workflow is conversational but precise. It should ask:

  • What resource type are you publishing?
  • What is the resource name and short description?
  • Where is the endpoint, manifest, schema, repository, or artifact?
  • Which authorizedDomains apply?
  • Which capabilityTags describe the resource?
  • Which version is being published?
  • Do you already have DID material, or should local demo material be generated?
  • Which baseUrl or endpoint should receive the submission?

After submission, the skill should report lifecycle state and not imply that Discovery visibility is immediate.

The skill should also summarize what it submitted. A short confirmation containing resource DID, resource type, domains, tags, endpoint or package reference, version, target Registrar, and returned status gives the user a useful audit trail.

Discovery Workflow

For Discovery, the skill should help users phrase better queries, choose optional filters, and interpret results. It can explain why a candidate matched, but it should separate relevance from trust. If a candidate looks useful, the skill should point to verification steps and native protocol next steps.

This is especially valuable for non-expert users. The assistant can translate between “I need a tool that does X” and structured Discovery fields without hiding OAN’s evidence model.

The skill can also help users improve failed searches. If the query is vague, it can suggest a task-focused query. If filters are too narrow, it can explain which one may be blocking results. If a result appears relevant but lacks verification, it should warn instead of overstating confidence.

What the Skill Should Avoid

The community skill should avoid handling production secrets, deploying official nodes, editing private governance files, voting on chain, changing Root authorization state, or running official pressure tests. Those tasks require private operational context and belong in official operations automation.

It should also avoid making claims like “safe to use” solely from a high Discovery score. It can say “candidate found” and “evidence available”; verification and native protocol safety still matter.

A healthy community skill should leave users more capable. It should teach the distinction between domains and tags, between Discovery and verification, between official defaults and third-party endpoints, and between OAN trust evidence and runtime product safety.

Further Reading