Wox Plugin Submit2store

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 Window Switcher
• 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.

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.