// Use when the user invokes Wox test assurance or asks to run Wox `make test` and `make smoke`; direct invocation is explicit permission to execute both suites and fix failures until they pass.
Update Wox CHANGELOG.md based on commits since the last release. Use when the user asks to "update changelog", "write release notes", or "summarize changes since last release" and the output must follow the repository's existing changelog format.
Create, scaffold, implement, and package Wox plugins (nodejs, python, script-nodejs, script-python). Use when cloning official SDK templates, generating script plugin templates, editing plugin.json metadata, defining SettingDefinitions and validators, wiring i18n, implementing plugin APIs, or preparing plugin repositories for local packaging. If the user wants to publish a plugin to the official Wox store or check whether it is already listed, prefer wox-plugin-submit2store.
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.
| name | wox-test-ensurance |
| description | Use when the user invokes Wox test assurance or asks to run Wox `make test` and `make smoke`; direct invocation is explicit permission to execute both suites and fix failures until they pass. |
Drive Wox test assurance from the repository root until both make test and make smoke pass. Treat failing output as evidence, fix the real cause first, and only change tests when the implementation is demonstrably correct and the test is stale, over-specified, or invalid.
If this skill is explicitly invoked, the user has already asked to run the required test and smoke commands. Do not stop after summarizing a plan or ask for extra confirmation based on AGENTS.md test restrictions; the skill invocation is the explicit request that satisfies that rule.
Start execution immediately from C:\dev\Wox unless the user provides another Wox checkout path.
Before running any test command, ensure no local Wox instance or VS Code-launched Wox debug process is still running. Force-stop matching processes before make test; stale core/UI processes can hold ports, keep old state alive, or block smoke launch/build output.
Use a Windows PowerShell check like this from the Wox checkout, adjusting $repo only when the user provides another path:
$repo = (Resolve-Path "C:\dev\Wox").Path
$woxProcesses = Get-CimInstance Win32_Process | Where-Object {
$name = $_.Name
$cmd = $_.CommandLine
$exe = $_.ExecutablePath
$isWoxBinary = $name -in @("Wox.exe", "wox.exe", "wox-ui.exe", "wox.core.exe", "__debug_bin.exe")
$isWoxDebug = $name -in @("dlv.exe", "__debug_bin.exe") -and $cmd -like "*$repo*"
$isRepoRuntime = ($exe -like "$repo*") -and ($name -like "*wox*")
$isWoxBinary -or $isWoxDebug -or $isRepoRuntime
}
$woxProcesses | ForEach-Object { Stop-Process -Id $_.ProcessId -Force }
If stopped processes are found, mention them briefly in the working update or final summary.
make test first and capture the failing package, test name, command output, and relevant logs.make test fails, investigate and fix it before starting smoke verification.make smoke after make test is green.make smoke fails, investigate from the real failing smoke path and logs.make test and full make smoke from the repository root in that order.Prefer this order:
Use targeted reruns only while narrowing a failure. They are not final proof. The final proof is the complete make test and make smoke sequence passing.
make smoke hangs near build or launch, check whether a stale wox-ui.exe from the repo build output is still running before changing tests.make command passes.dart format --line-length 180 <files>.make test passed from the Wox repository root.make smoke passed from the Wox repository root.