---
name: wox-plugin-submit2store
description: Submit the current Wox plugin repository to the official Wox store by ensuring the user has a reusable fork of Wox-launcher/Wox, checking whether the plugin ID already exists in Wox's store-plugin.json, adding a new store entry when missing, and preparing a pull request to Wox-launcher/Wox. Use when the user wants to publish a Wox plugin to the store, verify whether it has already been listed, or have Codex run the store submission PR workflow.
---

# Wox Plugin Submit2store

## Overview

Submit the current plugin repository to the Wox store through a PR against `Wox-launcher/Wox`. Ensure a reusable fork exists first, read local plugin metadata, refuse duplicate submissions, and only modify `store-plugin.json` when the plugin ID is not already present.

## Workflow

1. Ensure the user already has a fork of `Wox-launcher/Wox`, or create one.
2. Read the current plugin repository before touching the store repo.
3. Validate that the plugin has enough public metadata and release assets for a store entry.
4. Clone the user's fork into a temporary directory and add `upstream` for `https://github.com/Wox-launcher/Wox`.
5. Check upstream `store-plugin.json` for the current plugin ID.
6. Stop and tell the user not to submit when the ID already exists.
7. Add the new store entry when the ID is absent.
8. Commit on a branch in the fork and open a PR to `Wox-launcher/Wox`.

## Ensure A Fork Exists First

Treat fork setup as the first gate. Do not clone or edit a working copy until one of these is true:

- the user already has a fork of `Wox-launcher/Wox`
- the current authenticated GitHub user can create one now

Use this order:

1. Check whether the user already has a fork and reuse it when present.
2. If `gh` is available and authenticated, create the fork from the CLI.
3. If `gh` is unavailable, unauthenticated, or fails, send the user to the web fork flow and continue only after the fork exists.

For CLI-driven fork handling:

- prefer reusing an existing fork instead of creating a new one
- if a fork is missing, create it with GitHub CLI
- after the fork exists, treat the fork as `origin` and the official repo as `upstream`

For web fallback:

- direct the user to `https://github.com/Wox-launcher/Wox/fork`
- wait for the user to confirm the fork is ready
- continue by cloning the fork repository, not the upstream repository

When the user has direct write access to `Wox-launcher/Wox`, a fork is not required. Otherwise, do not assume direct push access.

## Read Local Metadata First

Read at least these files before preparing the store entry:

- `plugin.json`
- `package.json` when version information needs confirmation
- local screenshots or icon files when URLs need to be derived
- git remotes to determine the GitHub repository URL

Extract or derive these values:

- plugin `Id`
- `Name`
- `Author`
- `Version`
- `MinWoxVersion`
- `Runtime`
- `Description`
- repository `Website`
- `.wox` download asset URL
- public icon URL
- optional screenshot URLs
- supported operating systems

Stop and ask the user to fix the repository first when any of these conditions hold:

- `plugin.json` still contains template placeholders such as `{{.Id}}` or `{{.Name}}`
- the repository URL cannot be determined
- the plugin does not have a public release asset that matches the installable `.wox` package
- the icon or screenshot is only local and no stable public URL can be formed

## Clone The Fork And Check For Duplicates

Clone the user's fork into a temporary directory instead of modifying the current plugin workspace. Add the official repository as `upstream` so the branch and PR target remain `Wox-launcher/Wox`.

Inspect `store-plugin.json` from the current upstream default branch and search by the exact plugin ID from the local `plugin.json`.

When the ID already exists:

- do not modify `store-plugin.json`
- tell the user that the plugin is already listed
- include the existing matching entry or its location so the user can verify it quickly

When the ID does not exist:

- continue to create a new entry
- preserve the file's existing formatting and ordering style

## Build The Store Entry

Use the field template and sourcing rules in [references/store-plugin-entry.md](./references/store-plugin-entry.md).

Apply these rules while building the JSON object:

- Keep `Id`, `Name`, `Author`, `Version`, `MinWoxVersion`, and `Runtime` aligned with local plugin metadata.
- Prefer a plain `Description` string when no i18n payload exists.
- Add `I18n` only when the repository already has trustworthy localized copy.
- Convert local OS names to the store style: `Windows`, `Darwin`, `Linux`.
- Set `DateCreated` and `DateUpdated` to the current local timestamp in `YYYY-MM-DD HH:MM:SS`.
- Use raw GitHub content URLs for `IconUrl` and `ScreenshotUrls`.
- Use the canonical repository URL for `Website`.
- Use the latest release asset URL for `DownloadUrl`.

Before editing `store-plugin.json`, re-check that the generated URLs and filenames match the actual repository layout and release asset names.

## Prepare The PR

After editing the cloned fork workspace:

1. Create a branch such as `codex/add-<plugin-name>-store-entry`.
2. Commit only the `store-plugin.json` change.
3. Push to the user's fork.
4. Open a PR targeting `Wox-launcher/Wox`.

Use a concise PR title such as `Add <Plugin Name> to store`.

Use a PR body that includes:

- what plugin was added
- the repository URL
- the release download URL
- screenshots or icon coverage when relevant

## Report Back To The User

Always end with one of these outcomes:

- `Already listed`: explain that no submission is needed.
- `Ready to submit`: summarize the new store entry and PR URL.
- `Waiting for fork`: tell the user to finish the web fork flow before continuing.
- `Blocked`: list the missing metadata or missing public assets that prevented submission.