Preparing a plugin for publishing

Tracker users can find and enable plugins in the catalog: How to connect a plugin from the catalog.

Before publishing, read the Plugin developer agreement for the Yandex 360 services plugin catalog.

To add your developed plugin to the catalog:

1. Prepare the description and images for the plugin.

2. Prepare the help — documentation for users.

3. Submit the plugin for publishing.

After automatic moderation, the plugin will appear in the catalog of your organization with a request to enable. The organization administrator will need to approve it. How to approve a request

A plugin developed in your organization can be added to the public catalog so that it becomes available to users of other organizations. The publishing method depends on whether the plugin has already been published in your organization's catalog.

Designing the card

Before publishing, add images and a description for the plugin card to the project:

• public/logo.svg — plugin logo, must be square.
• marketplace/header-image.jpg — image for the plugin card, must have a 2.41:1 aspect ratio.
• marketplace/index.md — description for the plugin card.

Name

• Use 3 to 32 characters.
• Write the name in English. Official brand and product names, such as Figma or Miro, are allowed as exceptions.
• Don't include words such as “plugin”, “widget”, or “app” in the name.
• Don't use only the name of the service that the plugin integrates with.
• Don't use a name that is more than 90% similar to the name of an existing plugin or app.
• Don't put a period at the end.

For an integration with an external service, use the “function + service” naming pattern. For example: Sending messages to Telegram.

Short description

The short description is displayed on the plugin card in the catalog. It should complement the name and explain the plugin's primary function.

• Write one or two sentences with a total length of up to 75 characters.
• Don't put a period at the end.

Example:

• Name: Private notes.
• Short description: A private space for notes in an issue with flexible access permissions.

Full description

The full description must not exceed 4,000 characters. You can use bulleted and numbered lists. Don't add external links or advertising.

Recommended structure for the full description:

1. What problems the plugin solves. List its main features.
2. Who the plugin is intended for. Specify the roles or job titles of users who may find it useful.
3. How to use the plugin. Add a brief guide or usage scenario.

Text style and tone

• Use a neutral, informative tone. Don't use promotional claims, superlatives, or unsubstantiated statements such as “best” or “No. 1”.
• Use letters, numbers, single spaces, and necessary punctuation marks. Don't add emoji, exclamation marks, or special characters such as @, #, $, %, ^, &, or *.
• Don't use uppercase letters for emphasis. Acronyms of up to four letters, such as API or CRM, are allowed as exceptions.
• Don't capitalize common nouns.
• Don't abbreviate words.
• Spell brand and product names the same way as on their official websites and in their documentation.
• Use hyphens and dashes correctly. For example, Charon — data export is correct, while Charon - data export is incorrect.
• Use diacritics where required by English spelling, including in proper names.

Plugin category

To make plugins easier to find, they're grouped by category in the catalog. When creating or publishing a plugin, you need to specify its categories. Categories are set in the manifest in the categories field.

Full list of available categories:

Plugin help

Help is your plugin's documentation for users. It's displayed in the plugin catalog and at the integration point in the Tracker interface.

There are two ways to provide help: host it on an external domain or include it directly in the plugin distribution package.

External help

If the documentation is already hosted on your domain, specify a link to it in the docsUrl field of manifest.json:

{
    "docsUrl": "https://example.com/docs/plugin.html",
    "slots": {
        "tracker": {
            "issue.action": [
                {
                    "entrypoint": "index.html",
                    "contextLevel": "basic",
                    "title": {
                        "ru": "Мой плагин",
                        "en": "My Plugin"
                    }
                }
            ]
        }
    }
}

Tracker will display a link to the help in the plugin catalog and at your plugin's integration point.

Internal help

If you want to include documentation directly in the plugin distribution package, create a docs/ folder in the project root and place the index.md and toc.yaml files inside. The toc.yaml file describes the document structure:

title: My Docs
href: index.md
items:
    - name: Introduction
      href: index.md
    - name: Getting Started
      href: getting-started.md
    - name: Reference
      href: reference.md

File structure

Minimum structure for a single-page help:

docs/
├── toc.yaml
└── index.md

Preview

If you want to see what the documentation will look like, run the build-docs command and open docs-build/index.html in your browser.

Publishing help

When publishing the plugin, the help is automatically built with Diplodoc. After successful verification, the /docs/index.html link will be added to the plugin manifest.

The help is not embedded in the Tracker interface — the user follows the link, just like with external help.

Publishing the plugin

To submit a plugin for publishing:

1. Get a token for the CLI:

   weavix login
   

2. Run the publishing:

   weavix submit
   

   This command will automatically register the plugin if needed, upload the distribution package, and submit the version for moderation.

3. After submitting for moderation, check the publishing status:

   weavix list
   

   To view moderator comments for a plugin version, run:

   weavix info
   

   The command displays comments under the corresponding version with the author's name and date. Comments aren't displayed in the output of weavix list.

Publishing in the public catalog

Being public is a property of the plugin, not of a particular version. The publishing method depends on the plugin's current state.

weavix upgrade

Before making a plugin public

Both submit --public and make-public check that the plugin card contains:

• name, description, support, categories, and slug in manifest.json.
• marketplace/index.md.
• marketplace/header-image.jpg.

The manifest fields are described in Plugin description in manifest.json.

Both commands also scan the archive for secrets. If the CLI finds possible secrets, fix them or select the false positives in the interactive prompt. The CLI prints a fingerprint for each finding.

Every make-public run asks you to confirm the irreversible visibility change. To skip the prompt, add --yes. This flag is required when running without a terminal.

When running without a terminal, acknowledge the fingerprints of false positives explicitly:

weavix make-public <plugin-id> --yes --ack <fingerprint...>

If a non-interactive submit --public reports possible secrets, the plugin has already been registered. Use the plugin ID and fingerprints printed by the CLI in the command above, then submit the version with weavix submit.

New or unpublished plugin

Run:

weavix submit --public

The CLI registers the plugin, changes its visibility to PUBLIC, and submits the version for Yandex moderation. Once approved, the version appears in the public catalog and becomes available to users in all organizations.

If the plugin is already public, submit new versions with weavix submit without the --public flag. If the plugin has already been published in your organization's catalog, the CLI stops with an error telling you to run make-public instead.

You can also run make-public for a registered plugin that has not been published yet: it changes the visibility to PUBLIC immediately but doesn't submit a version. Then submit the version with weavix submit.

Plugin published in an organization

To publish the latest version approved by your organization in the public catalog, run:

weavix make-public

To publish a different plugin, specify its ID:

weavix make-public <plugin-id>

If the plugin card is incomplete, fill in the missing data listed by the CLI. Then submit a new version with weavix submit and wait for your organization's approval. Finally, run weavix make-public again.

After the request is created, new version submissions are blocked until the moderator decides. If you run submit while the request is pending, the CLI reports an error and suggests withdrawing the request. To view the latest request, run:

weavix info

The command displays the request ID and status, version ID, request and review dates, and the moderator's comment.

To withdraw the active request and allow version submissions again, run:

weavix withdraw --publication

For a different plugin, pass its ID: weavix withdraw --publication <plugin-id>.

Adding to the catalog

After automatic moderation, the plugin will appear in your organization's catalog with a request to enable. The organization administrator will need to approve it. How to approve a request

Once approved by the administrator, the plugin will become available to the organization's users just like plugins from the general catalog. How to enable a plugin

To make a plugin created for your organization available to all Tracker users, publish it in the public catalog. Once approved by Yandex, the plugin will appear in the public catalog.