{"owner":"Wox-launcher","repo":"Wox","hasSkills":true,"totalSkillsCount":96,"totalTokensCount":57079,"categories":["anthropic-skill","root-instruction","plugin-manifest"],"hasMcp":false,"mcpConfig":null,"found":[".agents/skills/wox-blog/SKILL.md",".agents/skills/wox-cpu-debug/SKILL.md",".agents/skills/wox-generate-smoke-test-case/SKILL.md",".agents/skills/wox-plugin-submit2store/SKILL.md",".agents/skills/wox-commit/SKILL.md",".agents/skills/wox-i18n/SKILL.md",".agents/skills/wox-memory-debug/SKILL.md",".agents/skills/wox-plugin-creator/SKILL.md",".agents/skills/wox-changelog-update/SKILL.md",".agents/skills/wox-theme-creator/SKILL.md",".agents/skills/wox-test-ensurance/SKILL.md",".agents/skills/wox-visual-style/SKILL.md","AGENTS.md","store-plugin.json",".agents/skills/wox-blog/agents/openai.yaml",".agents/skills/wox-blog/assets/article-template.md",".agents/skills/wox-blog/references/cover-style.md",".agents/skills/wox-blog/references/writing-style.md",".agents/skills/wox-changelog-update/agents/openai.yaml",".agents/skills/wox-commit/agents/openai.yaml",".agents/skills/wox-cpu-debug/agents/openai.yaml",".agents/skills/wox-generate-smoke-test-case/agents/openai.yaml",".agents/skills/wox-i18n/agents/openai.yaml",".agents/skills/wox-memory-debug/agents/openai.yaml",".agents/skills/wox-plugin-creator/references/hotkeys.md",".agents/skills/wox-plugin-creator/references/html_preview_updates.md",".agents/skills/wox-plugin-creator/references/icons.md",".agents/skills/wox-plugin-creator/references/plugin_i18n.md",".agents/skills/wox-plugin-creator/references/plugin_json_schema.md",".agents/skills/wox-plugin-creator/references/plugin_overview.md",".agents/skills/wox-plugin-creator/references/plugin_tools.md",".agents/skills/wox-plugin-creator/references/refinements.md",".agents/skills/wox-plugin-creator/references/scaffold_nodejs.md",".agents/skills/wox-plugin-creator/references/scaffold_python.md",".agents/skills/wox-plugin-creator/references/sdk_nodejs.md",".agents/skills/wox-plugin-creator/references/sdk_python.md",".agents/skills/wox-plugin-creator/references/settings_patterns.md",".agents/skills/wox-plugin-submit2store/agents/openai.yaml",".agents/skills/wox-plugin-submit2store/references/store-plugin-entry.md",".agents/skills/wox-test-ensurance/agents/openai.yaml",".agents/skills/wox-visual-style/agents/openai.yaml",".agents/skills/wox-visual-style/references/visual-style-guide.md","www/docs/guide/plugins/system/application.md","www/docs/guide/plugins/system/backup.md","www/docs/guide/plugins/system/browser-bookmark.md","www/docs/guide/plugins/system/browser.md","www/docs/guide/plugins/system/calculator.md","www/docs/guide/plugins/system/chat.md","www/docs/guide/plugins/system/clipboard.md","www/docs/guide/plugins/system/cloudsync.md","www/docs/guide/plugins/system/color.md","www/docs/guide/plugins/system/converter.md","www/docs/guide/plugins/system/doctor.md","www/docs/guide/plugins/system/emoji.md","www/docs/guide/plugins/system/explorer.md","www/docs/guide/plugins/system/feedback.md","www/docs/guide/plugins/system/file.md","www/docs/guide/plugins/system/folder.md","www/docs/guide/plugins/system/hotkey-overview.md","www/docs/guide/plugins/system/mediaplayer.md","www/docs/guide/plugins/system/query-history.md","www/docs/guide/plugins/system/shell.md","www/docs/guide/plugins/system/sys.md","www/docs/guide/plugins/system/theme.md","www/docs/guide/plugins/system/update.md","www/docs/guide/plugins/system/url.md","www/docs/guide/plugins/system/websearch.md","www/docs/guide/plugins/system/webview.md","www/docs/guide/plugins/system/wpm.md","www/docs/zh/guide/plugins/system/application.md","www/docs/zh/guide/plugins/system/backup.md","www/docs/zh/guide/plugins/system/browser-bookmark.md","www/docs/zh/guide/plugins/system/browser.md","www/docs/zh/guide/plugins/system/calculator.md","www/docs/zh/guide/plugins/system/chat.md","www/docs/zh/guide/plugins/system/clipboard.md","www/docs/zh/guide/plugins/system/cloudsync.md","www/docs/zh/guide/plugins/system/color.md","www/docs/zh/guide/plugins/system/converter.md","www/docs/zh/guide/plugins/system/doctor.md","www/docs/zh/guide/plugins/system/emoji.md","www/docs/zh/guide/plugins/system/explorer.md","www/docs/zh/guide/plugins/system/feedback.md","www/docs/zh/guide/plugins/system/file.md","www/docs/zh/guide/plugins/system/folder.md","www/docs/zh/guide/plugins/system/hotkey-overview.md","www/docs/zh/guide/plugins/system/mediaplayer.md","www/docs/zh/guide/plugins/system/query-history.md","www/docs/zh/guide/plugins/system/shell.md","www/docs/zh/guide/plugins/system/sys.md","www/docs/zh/guide/plugins/system/theme.md","www/docs/zh/guide/plugins/system/update.md","www/docs/zh/guide/plugins/system/url.md","www/docs/zh/guide/plugins/system/websearch.md","www/docs/zh/guide/plugins/system/webview.md","www/docs/zh/guide/plugins/system/wpm.md"],"skills":{".agents/skills/wox-blog/SKILL.md":"---\nname: wox-blog\ndescription: Create or revise Wox blog articles with practical workflows, paired English and Chinese Markdown, and consistent illustrated covers. Use for Wox blog writing and editorial standards, not release changelogs or general documentation.\n---\n\n# Wox Blog\n\nWrite for people using Wox: one concrete task, its useful outcome, and enough detail to reproduce it. Support product stories and engineering articles when requested; practical tips and workflows are the default.\n\n## Establish the facts\n\n- Read relevant feature documentation and implementation before describing commands, setting labels, defaults, or platform support. Distinguish released behavior from development-only changes; do not imply unreleased features are available in the current release.\n- Inspect nearby articles and `www/docs/.vitepress/theme/components/blog.data.mts` for the metadata contract. Do not turn a blog request into an app feature change.\n- For existing articles, preserve the slug, publication date, and useful media unless the request explicitly changes them.\n\n## Write the article pair\n\n- Read [the writing style guide](references/writing-style.md) before drafting or substantially rewriting. It contains the Mole sample analysis, Wox-specific examples, and an editorial review. Borrow explanatory techniques rather than copying an author's voice.\n- Default to English in `www/docs/blog/<slug>.md` and Simplified Chinese in `www/docs/zh/blog/<slug>.md`, using the same slug, date, category, and cover. Honor explicit single-language requests.\n- Use [the article template](assets/article-template.md) for frontmatter and a starting point, replacing every template token. It is not a mandatory outline.\n- Choose a specific title about a task or benefit. Avoid a repeated “Did You Know” / “你知道吗” prefix, exaggerated claims, and generic introductions. The description should add useful context rather than repeat the title.\n- Develop the situation, a concrete example, the reason for consequential settings, and the observable result as needed. Use connected prose for the explanation and steps for actions. Add useful context where an article feels thin; do not pad it with adjectives, repeated benefits, or a mandatory FAQ/conclusion. Keep length and structure proportional to the task.\n- Use a calm, conversational voice with specific nouns and verbs. Do not fabricate personal experience, measured improvements, user quotations, or test results to make the writing lively. Keep card descriptions compact; put the fuller explanation in the body.\n- Translate naturally. Keep commands, setting semantics, platform constraints, and outcomes equivalent across languages. Make frontmatter `title` match the article H1.\n- New articles use the actual publication date in `YYYY-MM-DD`. Use a stable descriptive kebab-case slug; omit the legacy `did-you-know-` prefix for new articles.\n\n## Supply card metadata and a cover\n\nRequired frontmatter: `title`, `description`, `date`, `category`, `cover`, and `coverAlt`.\n\n| Category ID | English label | Chinese label |\n| --- | --- | --- |\n| `workspace` | Windows & apps | 窗口与应用 |\n| `preview` | Files & previews | 文件与预览 |\n| `automation` | Shortcuts & automation | 快捷键与自动化 |\n| `product` | Inside Wox | Wox 动态 |\n\nChoose the closest category. Add a category only when the article genuinely falls outside these themes, updating loader validation and both localized labels in `BlogIndex.vue` together.\n\n- The default cover style is the approved flat illustration family: front-facing 2D shapes, thin charcoal-blue outlines, pale gray backgrounds, muted blue/sage/peach accents, and generous whitespace. Avoid clay-like 3D materials, bevels, thick keys, perspective, and heavy shadows. Use no text or logos in covers.\n- Read [the cover style reference](references/cover-style.md) when creating or replacing a cover. Use the built-in image generation tool for original illustrations; inspect an existing cover as a style reference when useful.\n- Save selected images under `www/docs/public/images/blog/` and reference `/images/blog/<name>.webp` (or the actual image extension). Localize `coverAlt` concisely.\n- Covers express the topic, not evidence of product behavior. Preserve real screenshots and videos in the body. Never substitute generated mock UI for factual screenshots.\n- When a real Wox product screenshot is needed but unavailable, continue drafting with a descriptive text placeholder at the intended position, such as `> Screenshot needed: Wox workspace settings showing the saved window layout on Windows.` Specify the screen, relevant state or action, and what the image should demonstrate; use the article language. Do not create an image link to a nonexistent file. At delivery, notify the user and list the article locations and screenshots they need to supply. These intentional screenshot placeholders may remain in the draft; they do not block completing the text and local validation.\n- If image generation is unavailable, finish text preparation and report the missing cover. Do not leave broken references or silently switch to a different medium.\n- The homepage discovers Markdown automatically and sorts by date, then URL. Do not manually add links to the blog indexes or hard-code cards.\n\n## Verify and deliver\n\n- Run the editorial pass in the writing guide: check that the reader can recognize the situation, follow the example, and tell what success looks like; remove unsupported claims and repeated filler.\n- Check both languages, links, actual asset paths, metadata, and claims against the source feature. Preserve existing URLs when revising.\n- From `www`, run `pnpm docs:build`; run `git diff --check` from the repository root.\n- Verify the article appears on its language homepage with its cover, complete title, and correct date. Inspect article media and the card at desktop and mobile widths.\n- Report article paths and verification limits. Default to local files and local verification; do not commit, push, or deploy unless requested.\n",".agents/skills/wox-cpu-debug/SKILL.md":"---\nname: wox-cpu-debug\ndescription: Measure CPU usage, attribute CPU hotspots, and optimize them without materially increasing Go or native memory in the real single-process Wox Go UI. Use for continuous-query CPU regressions, high idle or hidden CPU, plugin/query hot paths, renderer or native platform activity, background work that continues after hide, and comparisons of Go pprof data with macOS or Windows process samples.\n---\n\n# Wox CPU Debug\n\n## Goal\n\nRun the real Wox debug build with `wox_automation`, warm the same process, replay deterministic queries, and measure query-active and hidden CPU independently. Use Go CPU profiles for Go ownership and OS process/native samples for whole-process behavior. Keep profilers in separate identical runs so one profiler does not distort another.\n\n## Run the Debug Build\n\n### macOS\n\n1. Stop every other Wox instance.\n2. Start the real debug build under Delve:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\nWOX_AUTOMATION_INFO_FILE=/tmp/wox-cpu-automation.json /Users/qianlifeng/go/bin/dlv debug . --build-flags=-tags=sqlite_fts5,wox_automation\n```\n\n3. Run `continue`, wait for startup and plugin initialization, and record the debuggee PID.\n4. Keep this PID alive and running normally for the complete comparison. Never sample Delve or `debugserver` instead of the debuggee.\n\nBuild the automation workload once before measuring so Go compilation is outside every CPU window:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\ngo build -o /tmp/wox-cpu-workload ../.agents/skills/wox-cpu-debug/scripts/run-cpu-workload.go\n```\n\n### Windows\n\nStart Delve headlessly so the real debuggee can run normally while measurements execute from another PowerShell process:\n\n```powershell\ncd D:\\dev\\Wox\\wox.core\nNew-Item -ItemType Directory -Force .tmp\\cpu-debug | Out-Null\n$env:WOX_AUTOMATION_INFO_FILE = \"D:\\dev\\Wox\\wox.core\\.tmp\\cpu-debug\\automation.json\"\n$env:CGO_ENABLED = \"1\"\n$delve = Start-Process -FilePath (Get-Command dlv).Source `\n  -ArgumentList @(\"debug\", \".\", \"--headless\", \"--listen=127.0.0.1:43001\", \"--api-version=2\", \"--accept-multiclient\", \"--continue\", \"--build-flags=-tags=sqlite_fts5,wox_automation\", \"--output=D:\\dev\\Wox\\wox.core\\.tmp\\cpu-debug\\__debug_bin_wox.exe\") `\n  -WorkingDirectory (Get-Location).Path -WindowStyle Hidden -PassThru\n```\n\nWait for `automation.json`, then identify the `__debug_bin_wox.exe` child PID. Never sample either Delve process:\n\n```powershell\nwhile (-not (Test-Path $env:WOX_AUTOMATION_INFO_FILE)) { Start-Sleep -Milliseconds 100 }\nGet-CimInstance Win32_Process |\n  Where-Object { $_.ParentProcessId -eq $delve.Id -and $_.Name -eq \"__debug_bin_wox.exe\" } |\n  Select-Object ProcessId, ParentProcessId, Name, CommandLine\n```\n\nBuild the workload once before warm-up:\n\n```powershell\ngo build -o .tmp\\cpu-debug\\wox-cpu-workload.exe ..\\.agents\\skills\\wox-cpu-debug\\scripts\\run-cpu-workload.go\n```\n\nKeep the same debuggee PID alive through warm-up and every before/after comparison. When finished, stop only the exact debuggee and Delve PIDs created by this run.\n\n## Warm the Process\n\nRun a 15-second mixed-query block, hide the launcher, and wait 10 seconds:\n\n```bash\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode queries -duration 15s -seed 1\nsleep 10\n```\n\nWarm-up absorbs startup, application indexing, font loading, icon decoding, and lazy caches. Restarting Wox after warm-up invalidates the comparison.\n\nOn Windows, use the corresponding `.exe` and PowerShell sleep command:\n\n```powershell\n& .tmp\\cpu-debug\\wox-cpu-workload.exe -info .tmp\\cpu-debug\\automation.json -mode queries -duration 15s -seed 1\nStart-Sleep -Seconds 10\n```\n\n## Measure Query Latency\n\nUse the workload's `latency` mode for query responsiveness. The `queries` mode only\nchecks input updates and drives CPU activity; its fixed waits are not latency samples.\nBuild the workload before measuring, then warm the same process with 40 completed\nqueries and measure a deterministic sequence:\n\n```powershell\n& .tmp\\cpu-debug\\wox-cpu-workload.exe -info .tmp\\cpu-debug\\automation.json -mode latency -query-count 40 -seed 1 -output .tmp\\cpu-debug\\warmup.json\n& .tmp\\cpu-debug\\wox-cpu-workload.exe -info .tmp\\cpu-debug\\automation.json -mode latency -query-count 160 -seed 11 -output .tmp\\cpu-debug\\latency.json\n```\n\nThe report contains raw per-query samples and nearest-rank p50/p95 for input\ndispatch to the first current result in the retained semantics frame, and to the\ncompleted result frame. Polling is every 5 ms plus RPC/scheduling overhead; these\nare client-observed UI-frame timings, not native presentation or icon-decode\ncompletion timings. Queries with no results contribute only to completion latency.\nEach query has a 10-second timeout; a failed run is invalid and must not contribute\npartial samples to the aggregate. Compare query families as well as aggregate p95.\n\n`perf.query_state` correlates the query generation, result ownership, input value,\nand retained row IDs, so an older retained result or completion cannot satisfy the\nmeasurement. `-mode stats` reads PID, effective GOMAXPROCS, Go heap allocation,\nGo retained memory (`Sys - HeapReleased`), stack allocation, and MemProfileRate\nwithout showing Wox or forcing GC.\n\nWhen comparing startup GOMAXPROCS policies, use a fresh process for each arm,\nwith identical isolated settings, warm-up, query sequence, and GOGC. Preserve each\nPID through that run's warm-up and measurements. Alternate arm order across at\nleast three pairs. Do not compile, run tests, or run another profiler during a\nmeasurement window. Collect process CPU in separate `queries` windows, recording\ncompleted query counts, then sample memory at 45 seconds after hide so both staged\nrelease deadlines have passed. Keep private working set, total working set, private\ncommitted bytes, and Go retained memory distinct. Repeat decisive measurements in\nan optimized production-configured build, where development heap profiling is off.\n\n## Capture Continuous-Query Go CPU\n\nTrigger Wox's built-in 30-second `runtime/pprof` action and keep deterministic queries running for that complete window:\n\n```bash\n/tmp/wox-cpu-workload \\\n  -info /tmp/wox-cpu-automation.json \\\n  -mode profile-queries \\\n  -seed 11 \\\n  -output /tmp/wox-cpu-queries.prof\n```\n\nInspect both self time and cumulative ownership:\n\n```bash\ngo tool pprof -top -nodecount=30 /tmp/wox-cpu-queries.prof\ngo tool pprof -top -cum -nodecount=30 /tmp/wox-cpu-queries.prof\n```\n\nOn macOS and Linux, read the profile header's `Duration` and `Total samples` ratio as average effective core use during the 30-second window. Record the top flat and cumulative owners. Use `go tool pprof -list '<pattern>'` for source-level attribution only after a stable owner appears.\n\nOn Windows, do not trust `Total samples / Duration` until it agrees with process CPU sampling. Go profiles can charge time blocked in `runtime.cgocall`, `syscall.syscalln`, `GetMessage`, or `GetQueuedCompletionStatus` as if it were CPU. When these wait paths dominate and the profile ratio contradicts process CPU, treat the ratio and those cumulative wait owners as profiling artifacts. Use the Windows process sampler as the CPU baseline and use application-owned profile paths only as attribution candidates that require reproduction.\n\nRepeat with `-query terminal` or another fixed query when mixed queries need attribution. Compare mixed and fixed runs from the same PID; do not compare a profile captured during startup with a warmed profile.\n\nThe automation client can time out while waiting for semantics during expensive mixed queries. If that happens:\n\n- Mark the complete process window as contaminated; do not average the idle samples after the workload stalled.\n- Check whether the built-in 30-second profile still completed in `~/.wox/cpu.prof` or `%USERPROFILE%\\.wox\\cpu.prof`, but label it partial-workload evidence.\n- Repeat with a safe fixed query such as `-query terminal`. Only use a run that reports its completed query count for the clean baseline.\n- Record the query and transition (`set` or `clear`) that timed out as a separate automation/query diagnostic.\n\n## Measure macOS Query CPU\n\nUse a separate workload-only run for process CPU percentages:\n\n```bash\nready=$(mktemp /tmp/wox-cpu-query.XXXXXX)\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode queries -duration 35s -seed 11 -ready-file \"$ready\" &\nworkload_pid=$!\nwhile [[ ! -s \"$ready\" ]]; do sleep 0.1; done\n/Users/qianlifeng/Projects/Wox/.agents/skills/wox-cpu-debug/scripts/sample-wox-cpu-macos.sh --pid <PID> --samples 30 --interval 1\nwait \"$workload_pid\"\n```\n\nUse `AverageCPUPercent`, `MedianCPUPercent`, and `MaxCPUPercent`. macOS `%CPU` uses one-core units and may exceed 100 when multiple cores are active.\n\nWhen Go pprof does not explain process CPU, repeat the workload in a separate run and capture native stacks:\n\n```bash\nready=$(mktemp /tmp/wox-cpu-query-native.XXXXXX)\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode queries -duration 35s -seed 11 -ready-file \"$ready\" &\nworkload_pid=$!\nwhile [[ ! -s \"$ready\" ]]; do sleep 0.1; done\n/usr/bin/sample <PID> 30 -file /tmp/wox-cpu-queries-native.txt\nwait \"$workload_pid\"\n```\n\nDo not run `sample` and Go CPU profiling together. Attribute CoreText, CoreGraphics, AppKit, image decoding, cgo, and platform event-loop stacks from the native capture.\n\n## Measure Windows Query CPU\n\nUse a separate workload-only run. Start the workload with a unique ready file, wait for readiness, then sample the debuggee with `TotalProcessorTime` deltas:\n\n```powershell\n$ready = Join-Path $env:TEMP (\"wox-cpu-query-\" + [guid]::NewGuid().ToString(\"N\") + \".ready\")\n$workload = Start-Process -FilePath .tmp\\cpu-debug\\wox-cpu-workload.exe `\n  -ArgumentList @(\"-info\", \".tmp\\cpu-debug\\automation.json\", \"-mode\", \"queries\", \"-duration\", \"35s\", \"-seed\", \"11\", \"-query\", \"terminal\", \"-ready-file\", $ready) `\n  -WorkingDirectory (Get-Location).Path -WindowStyle Hidden -PassThru\nwhile (-not (Test-Path $ready)) { Start-Sleep -Milliseconds 100 }\n& ..\\.agents\\skills\\wox-cpu-debug\\scripts\\sample-wox-cpu-windows.ps1 `\n  -ProcessId <PID> -Samples 30 -IntervalSeconds 1 -CsvPath .tmp\\cpu-debug\\query-samples.csv\nWait-Process -Id $workload.Id\n```\n\nWindows CPU percentages also use one-core units and can exceed 100%. One-second samples can quantize around the Windows scheduler/accounting interval, so interpret the median and repeated pattern rather than a single small non-zero value.\n\nWhen Go pprof does not explain measured process CPU, capture ETW sampled CPU stacks with Windows Performance Recorder/Analyzer or another available native profiler in a separate identical run. Filter to the debuggee PID and verify symbols before attributing DirectComposition, Direct2D, DirectWrite, Win32, image decoding, or cgo work. If no native stack profiler is available, report that limitation instead of inferring a native owner from cumulative cgo time.\n\n## Measure Hidden CPU\n\nHide Wox first, signal readiness only after the hide completes, and sample the settled process:\n\n```bash\nready=$(mktemp /tmp/wox-cpu-hidden.XXXXXX)\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode hidden -duration 35s -ready-file \"$ready\" &\nworkload_pid=$!\nwhile [[ ! -s \"$ready\" ]]; do sleep 0.1; done\nsleep 2\n/Users/qianlifeng/Projects/Wox/.agents/skills/wox-cpu-debug/scripts/sample-wox-cpu-macos.sh --pid <PID> --samples 30 --interval 1\nwait \"$workload_pid\"\n```\n\nCapture hidden native stacks in another identical run when median CPU stays above sampler noise or periodic spikes recur:\n\n```bash\nready=$(mktemp /tmp/wox-cpu-hidden-native.XXXXXX)\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode hidden -duration 35s -ready-file \"$ready\" &\nworkload_pid=$!\nwhile [[ ! -s \"$ready\" ]]; do sleep 0.1; done\nsleep 2\n/usr/bin/sample <PID> 30 -file /tmp/wox-cpu-hidden-native.txt\nwait \"$workload_pid\"\n```\n\nUse `profile-hidden` only as a secondary Go-owner check:\n\n```bash\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode profile-hidden -output /tmp/wox-cpu-hidden.prof\n```\n\nThe CPU-profile action must briefly show the launcher to activate itself, so `profile-hidden` contains one-time activation and hide work at the start. Treat a function as a hidden hotspot only when it also appears in the settled OS/native run or consumes enough repeated samples to dominate that one-time transition.\n\nOn Windows, start the same `hidden` workload with a unique ready file, wait two seconds after readiness, and invoke `sample-wox-cpu-windows.ps1` for the debuggee PID. If a large spike appears while the median is near the sampling floor, capture two more settled 30-second windows. Classify it as periodic activity only if the spike or owner recurs.\n\n## Interpret Hotspots\n\nClassify query and hidden phases separately:\n\n- **Expected query work:** plugin query execution, fuzzy matching, file/application lookup, result adaptation, layout, text measurement, image decode, and rendering that stops after hide.\n- **Query hotspot candidate:** one owner repeatedly dominates flat or cumulative samples across identical profiles and scales with query frequency.\n- **No hidden CPU signal:** median settles at sampler noise, occasional spikes do not repeat, and a 30-second native sample has no recurring application stack.\n- **Possible hidden regression:** CPU remains above noise across three settled windows or recurring stacks show timers, animation/frame scheduling, renderer submission, Glance refresh, query cleanup, indexing, GC pressure, or asynchronous reloads after hide.\n- **Strong hidden regression:** the same owner persists in Go and/or native samples, reproduces after another warm run, and disappears when its feature is disabled or its lifecycle ends.\n\nIf process CPU is high but Go pprof is quiet, investigate native or cgo owners before changing Go query code. If Go pprof is high but process samples are low, verify that the profile was captured from the same PID and that activation/transition work did not dominate a mostly idle window.\n\nOn Windows, a high pprof total dominated by blocked Win32 calls is not evidence of high process CPU. Prefer the process sampler for magnitude and use the profile only to locate application work that scales across clean, identical workloads.\n\nDo not edit production code until the workload and owner reproduce. Add targeted `util.GetLogger()` diagnostics only when profiles identify a narrow lifecycle or scheduling path but cannot prove why it remains active.\n\n## Protect Memory While Optimizing CPU\n\nTreat memory as a required guardrail for every CPU optimization:\n\n- Prefer eliminating duplicate work, coalescing invalidations, stopping unnecessary scheduling, and reusing already-owned bounded resources.\n- Do not trade CPU for unbounded caches, duplicate decoded images or pixel buffers, retained render surfaces, longer-lived queues, or state that survives hide/close without a lifecycle reason.\n- Give every new cache, pool, or buffer a hard bound and an explicit release path. Clear window-scoped native resources on hide or close unless retaining them is required and measured.\n- For changes that alter caching, buffering, pooling, object lifetime, image ownership, or native resources, compare warmed before/after process physical footprint and Go retained heap under the same workload. Use `wox-memory-debug` for repeated-cycle attribution when the delta is unclear.\n- Treat a repeatable increase above 10 MiB or 5% of the warmed process footprint as material. Rework or reject the optimization unless the user explicitly accepts the tradeoff.\n\nDo not conclude that memory is unchanged from Go heap data alone. CoreGraphics, AppKit, IOSurface, decoded images, cgo allocations, and plugin hosts can increase process memory without appearing in the Go heap.\n\n## Report\n\nInclude:\n\n- OS, CPU architecture, debug tags, PID, warm-up, query pool or fixed query, and sample duration.\n- Query average/median/max process CPU and Go profile total samples versus duration.\n- Query top flat and cumulative Go owners, plus native owners when captured.\n- Hidden average/median/max process CPU and recurring Go/native stacks.\n- Before/after process footprint and Go retained-heap deltas when the optimization can affect memory ownership, including cache bounds and hide/close release behavior.\n- Whether activation, compilation, indexing, or another limitation contaminated a window.\n- On Windows, whether blocked Win32 calls contaminated pprof totals and whether native ETW stacks were available.\n- Classification for query CPU and hidden CPU, with the exact evidence supporting each.\n",".agents/skills/wox-generate-smoke-test-case/SKILL.md":"---\nname: wox-generate-smoke-test-case\ndescription: Analyze Wox feature code and plugin-exposed settings, recommend high-value native UI smoke scenarios and user flows, then generate focused Go UI smoke test cases using the automation driver and shared-process harness. Use when the user asks to identify smoke coverage for a Wox feature or plugin, or to design, add, write, or generate a smoke case under wox.core/test/smoke.\n---\n\n# Wox Generate Smoke Test Case\n\nUnderstand the feature before choosing coverage. Recommend the smallest high-value real-process smoke flow, then reuse the current smoke harness and product automation surface instead of building test-only paths.\n\n## Discover the Feature\n\n1. Read the repository `AGENTS.md` and relevant `README.md` files. Inspect `git status`, unstaged changes, staged changes, and relevant untracked files without modifying unrelated work.\n2. Locate the feature's real user entry point, then trace the code end to end: UI component, interaction handler, controller or service, persisted state or side effect, visible result, error path, and cleanup. Search every caller of the shared function before deciding where coverage belongs.\n3. Inspect the smoke infrastructure and nearest existing coverage:\n   - `wox.core/test/smoke/harness.go`\n   - `wox.core/test/automationdriver/client.go`\n   - The closest existing case under `wox.core/test/smoke/`\n   - The UI code that owns the relevant automation IDs and actions\n4. Identify the main functional points, platform branches, important state transitions, failure recovery, and existing unit or smoke coverage. Base the list on concrete code paths, not UI labels or assumptions.\n\n### Interpret Settings Semantics\n\nFor every settings smoke case, determine why the setting exists and trace the runtime path that consumes it before writing the test.\n\n1. State a **setting semantic contract** in user terms: changing the setting from a chosen value to another must alter a specific real product behavior, not merely the displayed or persisted control value.\n2. Build deterministic preconditions that make that behavior observable. Ensure the input data crosses the relevant boundary; for example, a maximum-result setting needs more available results than the tested cap.\n3. Drive the setting through its owning Settings section, then exercise the actual user flow that consumes it. Assert the live UI, runtime artifact, platform effect, or persisted product output that proves the semantic contract.\n4. Do not treat a selected value, a reopened control, or persistence alone as sufficient smoke evidence. Those checks may support the flow, but the final assertion must cover the setting's real user-visible effect.\n5. Account for implementation details that can distort naive evidence, such as virtual-list overscan, pagination, debouncing, asynchronous saves, or cached results. Measure the actual user-visible viewport or outcome rather than incidental semantic-tree node counts when they differ.\n\n### Inspect Plugin Settings\n\nWhen the target is a plugin:\n\n1. Find every exposed setting in the plugin metadata `SettingDefinitions`, dynamic setting callbacks, and query/action forms. Record its key, type, default, validators, options, and visibility conditions.\n2. Search every read of each setting, including `GetSetting` calls, initialization, reload callbacks, and persistence code. Map the setting to the behavior it actually changes.\n3. Build a setting coverage matrix with: setting, affected user behavior, important values or boundaries, existing coverage, smoke value, automation feasibility, and recommendation.\n4. Recommend a smoke case when a setting changes query results, actions, enablement, persistence or reload behavior, platform integration, validation or recovery, or another user-visible cross-process boundary.\n5. Skip separate smoke coverage for headings, labels, layout-only fields, equivalent options already covered by one representative value, and branches better protected by unit tests. Avoid a case for every setting or every option.\n6. Group settings into one user flow only when they naturally belong to the same task and failures remain easy to diagnose. Keep independent high-risk behaviors in separate cases.\n7. Never require real secrets, uncontrolled network services, or unavailable hardware. Prefer deterministic missing/invalid configuration and local persistence behavior unless the dependency is explicitly controlled by the test environment.\n\n## Recommend Coverage\n\nWhen the user asks for coverage design, present:\n\n- **Code map:** Name the main source files, functions, and responsibilities.\n- **Functional points:** Summarize the primary user-visible behaviors and important boundaries.\n- **Candidate cases:** Recommend no more than five flows, ordered by value. For each, include priority, user risk, existing coverage gap, prerequisites, actions, observable expected result, and automation feasibility.\n- **Plugin setting matrix:** For plugin requests, show which exposed settings deserve smoke coverage, which do not, and the source-backed reason for each decision.\n- **Recommended first case:** Select the smallest flow that covers the highest-risk real integration boundary and explain briefly why it belongs in smoke rather than a unit test.\n- **Automation gap:** Identify any missing stable automation ID or action required by the recommended flow.\n\nWhen the user already specified the exact flow, keep the pre-edit design brief: present only the code map, one observable behavior contract, and any automation gap. Do not expand an approved flow into an unnecessary candidate list or full setting matrix.\n\nRecommend smoke coverage only for real-process native UI, lifecycle, persistence, plugin integration, platform, accessibility, or rendering boundaries. Prefer unit tests for local pure logic and skip behavior already covered at the same boundary.\n\nIf the user asked only for design, stop after the recommendation. If the user already named or approved an exact flow, continue. Otherwise ask which recommended case to generate before editing product or test code.\n\n## Generate the Case\n\n1. State one observable behavior contract for the selected flow.\n2. Search all smoke packages for an existing helper before adding a local one. Promote a helper to `automationdriver` or `smoke` when a second consumer uses the same interaction contract; keep plugin-specific behavior in the leaf package. Avoid page-object layers or table-editor DSLs until repeated cases justify them.\n3. Reuse existing automation IDs, actions, `smoke.Case`, and helpers. Before driving a control, confirm its semantics expose a stable ID, role, label, current value or checked state, selected state when relevant, and the correct action. If that contract is missing, modify the smallest shared owning UI component to add a stable automation ID or semantic action, then add a focused component test for that contract. The semantic action must follow the real user interaction path; do not add a test-only bypass around product behavior.\n4. Add the case under the owning functional path. Reserve `wox.core/test/smoke/setting/` for Wox's own settings sections, such as `setting/ui/`. Every plugin-owned case must live under `wox.core/test/smoke/launcher/plugin/<plugin>/`, including flows that configure the plugin through its Settings page before exercising Launcher behavior. Classify by product owner rather than the UI route used during the flow; for example, place Calculator coverage under `launcher/plugin/calculator/`. Use the next unused three-digit number without renumbering existing cases:\n   - File: `NNN_descriptive_name_test.go`\n   - Function: `TestNNNDescriptiveName`\n   - Build constraint: `//go:build wox_ui_smoke`\n5. Immediately above every generated `TestNNN...` function, add a concise English doc comment that states the user-visible intent, the ordered UI flow, and the final evidence that proves the behavior. Mention prerequisites or cleanup only when they are part of the contract. Describe product behavior rather than automation implementation details. Use this shape:\n\n   ```go\n   // TestNNNDescriptiveName verifies <user-visible behavior and boundary>.\n   // Flow: <entry> -> <important actions or state transitions> -> <observable result>.\n   // Evidence: <real UI, runtime, persisted artifact, or log assertion that proves success>.\n   func TestNNNDescriptiveName(t *testing.T) {\n   ```\n\n6. Drive the UI through `automationdriver.Client` semantic actions (`Perform`, `PressKey`, `SetValue`) and `client.WaitFor`. Never use fixed sleeps to guess readiness. Use postconditions such as `Selected`, `Checked`, `Value`, status, or disappearance. Do not use mouse clicks, drags, node bounds, pointer coordinates, or screenshot pixels when a semantic action can produce the same transition. A real pointer or OLE drag is allowed only when the behavior under test is that native gesture and no semantic action exists. Even then, do not assert desktop hit-testing: which other HWND became foreground, title-bar or caption-button coordinates, z-order, or that a fixed client point such as a window center stays uncovered. Developer screens and CI desktops overlap differently. Assert Wox's own outcome (visibility, query result, callback, or file artifact). If a point is unavoidable, derive it at runtime from current window rects and keep it off other windows in the case.\n7. Treat query and result state as generation-bound. Setting the same query value may be a no-op, and refreshes may replace dynamic result IDs. Force a real query transition when freshness matters, wait for both the input value and `launcher.results=complete`, and resolve dynamic IDs again after refresh instead of retaining them across generations.\n8. Treat every command executed by a smoke case as interpreter- and platform-dependent input. Confirm the interpreter the case actually selects or inherits on Windows, macOS, and Linux. Prefer the simplest syntax shared by all targeted interpreters; do not assume Bash operators such as `&&`, `export`, Unix paths, or Unix-only tools work in Windows PowerShell. When no shared command exists, select the command with `runtime.GOOS` and, when configurable, the chosen interpreter, while keeping output and side effects equivalent. Normalize path separators and line endings in assertions. If the behavior is intentionally platform-specific, skip it explicitly with the reason instead of waiting for an impossible state.\n9. Let `smoke.Case` own before/after reset and the shared client, but do not assume reset restores plugin settings or desktop side effects. Explicitly restore changed settings and clean external state. Reopen settings or inspect persisted data before exercising runtime behavior; a locally updated control does not prove an asynchronous save completed.\n10. Keep assertions user-visible and deterministic. Prefer evidence in this order: real runtime artifact or fresh log slice, reloaded persisted value, then live semantic state. Treat relevant snapshot diagnostics as failures. Do not weaken assertions or add retries merely to hide a race.\n11. Do not launch another Wox process or create a second data directory inside a case. Use `automationdriver.SharedDataDirectoryEnvironment` only when the behavior must inspect real persisted output, and poll artifacts independently of UI generation changes.\n12. Format every touched Go file with the repository formatter. Run the new case from the repository root:\n\n   ```text\n   make smoke <functional/path/NNN>\n   ```\n\n13. After the targeted case passes, run `make smoke` to catch leaked state and shared-process cleanup failures. If the full suite fails in an existing case, distinguish that baseline failure from the new selector instead of attributing it to the new coverage. If execution is blocked by the environment, report the exact blocker and do not claim runtime coverage.\n\n## Failure Handling\n\n- Start from the exact command output, logs, snapshot, and failing state.\n- On a wait failure, capture the current values, checked states, status nodes, diagnostics, and relevant fresh log or artifact contents. Report the observed boundary instead of only the timeout.\n- Fix the shared product or automation boundary when that is the root cause; do not patch every case around it.\n- Add diagnostic logging only when the failure path cannot be identified with certainty, then use the new evidence before changing behavior.\n- Preserve unrelated worktree changes and keep the diff limited to the case plus any strictly required automation exposure.\n\n## Completion\n\nReport the behavior covered, the created case selector, every production or automation file changed to support it, and the exact verification commands with pass or failure status.\n",".agents/skills/wox-plugin-submit2store/SKILL.md":"---\nname: wox-plugin-submit2store\ndescription: Submit a Wox plugin to the official store by ensuring the user has a reusable fork of Wox-launcher/Wox, checking whether the plugin ID already exists in store-plugin.json, adding a new store entry when missing, and preparing a pull request to Wox-launcher/Wox. Single-file SDK plugins should be hosted on a public GitHub gist. Do not open the store pull request unless ScreenshotUrls contains at least one public screenshot of the plugin running in 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.\n---\n\n# Wox Plugin Submit2store\n\n## Overview\n\nSubmit a plugin 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. A store entry requires at least one public screenshot. Do not submit with an empty or omitted `ScreenshotUrls`, and do not open a PR that says a screenshot will be added later.\n\nFor **single-file SDK plugins**, host the plugin on a public GitHub gist. That is the simplest store delivery. Do not require a GitHub repository, `plugin.json`, or a `.wox` package. Example: https://gist.github.com/qianlifeng/04a9609de66eaa582a473f5852450ede\n\n## Workflow\n\n1. Ensure the user already has a fork of `Wox-launcher/Wox`, or create one.\n2. Read the current plugin (packaged repo, or the single-file `.js`/`.py` header) before touching the store repo.\n3. Validate that the plugin has enough public metadata and release assets for a store entry, including at least one public screenshot of the plugin running in Wox.\n4. Clone the user's fork into a temporary directory and add `upstream` for `https://github.com/Wox-launcher/Wox`.\n5. Check upstream `store-plugin.json` for the current plugin ID.\n6. Stop and tell the user not to submit when the ID already exists.\n7. Add the new store entry when the ID is absent.\n8. Commit on a branch in the fork and open a PR to `Wox-launcher/Wox`.\n\n## Ensure A Fork Exists First\n\nTreat fork setup as the first gate. Do not clone or edit a working copy until one of these is true:\n\n- the user already has a fork of `Wox-launcher/Wox`\n- the current authenticated GitHub user can create one now\n\nUse this order:\n\n1. Check whether the user already has a fork and reuse it when present.\n2. If `gh` is available and authenticated, create the fork from the CLI.\n3. If `gh` is unavailable, unauthenticated, or fails, send the user to the web fork flow and continue only after the fork exists.\n\nFor CLI-driven fork handling:\n\n- prefer reusing an existing fork instead of creating a new one\n- if a fork is missing, create it with GitHub CLI\n- after the fork exists, treat the fork as `origin` and the official repo as `upstream`\n\nFor web fallback:\n\n- direct the user to `https://github.com/Wox-launcher/Wox/fork`\n- wait for the user to confirm the fork is ready\n- continue by cloning the fork repository, not the upstream repository\n\nWhen the user has direct write access to `Wox-launcher/Wox`, a fork is not required. Otherwise, do not assume direct push access.\n\n## Read Local Metadata First\n\nFor a **single-file SDK plugin**, read the JSON metadata header in the live `.js` or `.py` file (usually `~/.wox/wox-user/plugins/single-file/Wox.Plugin.<Name>.js`). Prefer a public gist as `Website` / `DownloadUrl`. Upload the screenshot and icon to GitHub and use `https://gist.github.com/user-attachments/assets/<id>` URLs for `IconUrl` and `ScreenshotUrls`.\n\nFor a **packaged SDK plugin**, read at least:\n\n- `plugin.json`\n- `package.json` when version information needs confirmation\n- local screenshots or icon files when URLs need to be derived\n- git remotes to determine the GitHub repository URL\n\nExtract or derive these values:\n\n- plugin `Id`\n- `Name`\n- `Author`\n- `Version`\n- `MinWoxVersion`\n- `Runtime`\n- `Description`\n- `Website` (gist HTML URL, or GitHub repository URL)\n- `DownloadUrl` (gist raw `.js`/`.py` URL, or `.wox` release asset)\n- public icon URL\n- required screenshot URLs: at least one public image of the plugin running in Wox\n- supported operating systems\n\nStop and ask the user to fix the source first when any of these conditions hold:\n\n- metadata still contains template placeholders such as `{{.Id}}` or `{{.Name}}`\n- a single-file plugin has no public gist whose raw URL path ends with `.js` or `.py`\n- a packaged plugin has no public repository URL or no installable `.wox` release asset\n- there is no screenshot, `ScreenshotUrls` would be empty or omitted, or the only screenshot is local and has no stable public URL\n- the icon is only local and no stable public URL can be formed\n\n## Clone The Fork And Check For Duplicates\n\nClone 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`.\n\nInspect `store-plugin.json` from the current upstream default branch and search by the exact plugin ID from the local metadata.\n\nWhen the ID already exists:\n\n- do not modify `store-plugin.json`\n- tell the user that the plugin is already listed\n- include the existing matching entry or its location so the user can verify it quickly\n\nWhen the ID does not exist:\n\n- continue to create a new entry\n- preserve the file's existing formatting and ordering style\n\n## Build The Store Entry\n\nUse the field template and sourcing rules in [references/store-plugin-entry.md](./references/store-plugin-entry.md).\n\nApply these rules while building the JSON object:\n\n- Keep `Id`, `Name`, `Author`, `Version`, `MinWoxVersion`, and `Runtime` aligned with local plugin metadata.\n- Prefer a plain `Description` string when no i18n payload exists.\n- Add `I18n` only when the repository already has trustworthy localized copy.\n- Convert local OS names to the store style: `Windows`, `Darwin`, `Linux` (`Macos` in plugin headers becomes `Darwin`).\n- Set `DateCreated` and `DateUpdated` to the current local timestamp in `YYYY-MM-DD HH:MM:SS`.\n- For a gist-hosted single-file plugin: `Website` is the gist HTML URL, `DownloadUrl` is the gist raw URL including the `.js` or `.py` filename, and `IconUrl` / `ScreenshotUrls` are `https://gist.github.com/user-attachments/assets/<id>` links. Runtime is lowercase `nodejs` or `python`.\n- For a packaged plugin: use the canonical repository URL for `Website`, the latest `.wox` release asset for `DownloadUrl`, and public raw image URLs for `IconUrl` / `ScreenshotUrls`.\n- `ScreenshotUrls` must contain at least one public URL. Do not omit the field, submit `[]`, or continue while telling the user that no screenshot is included yet. Ask for a screenshot and stop until one is uploaded. Use a cropped Wox launcher screenshot that shows the query and the plugin's real results, like https://raw.githubusercontent.com/Wox-launcher/Wox.Plugin.ColorPicker/main/images/screenshot1.png. Do not submit an icon, a README image, source code, or a full-desktop capture.\n\nBefore editing `store-plugin.json`, re-check that the generated URLs and filenames match the gist file name or the packaged repository layout.\n\n## Prepare The PR\n\nAfter editing the cloned fork workspace:\n\n1. Create a branch such as `codex/add-<plugin-name>-store-entry`.\n2. Commit only the `store-plugin.json` change.\n3. Push to the user's fork.\n4. Open a PR targeting `Wox-launcher/Wox`.\n\nUse a concise PR title such as `Add <Plugin Name> to store`.\n\nUse a PR body that includes:\n\n- what plugin was added\n- the gist or repository URL\n- the download URL\n- every public screenshot URL. Stop instead of opening the PR when this list is empty\n\n## Report Back To The User\n\nAlways end with one of these outcomes:\n\n- `Already listed`: explain that no submission is needed.\n- `Ready to submit`: summarize the new store entry and PR URL.\n- `Waiting for fork`: tell the user to finish the web fork flow before continuing.\n- `Blocked`: list the missing metadata or missing public assets that prevented submission.\n",".agents/skills/wox-commit/SKILL.md":"---\nname: wox-commit\ndescription: Generate a repository-style commit message from the current Wox working tree without modifying the repository. Use when the user asks for a commit message or explicitly invokes `$wox-commit`.\n---\n\n# Wox Commit Message\n\n## Contract\n\nTreat explicit invocation as permission to inspect the current Wox diff and generate a commit message only. Do not stage, commit, amend, push, or otherwise modify the repository.\n\n## Workflow\n\n1. Read the repository instructions and inspect `git status --short`, the unstaged and staged diffs, and relevant untracked files.\n2. Infer every distinct behavior change from the actual diff and recent commit style. Do not ask the user to pick one feature when several unrelated changes are present.\n3. Prefer `type(scope): imperative summary` for normal code changes; use the repository's established wording for automated, release, or store updates.\n4. Always return both a subject and a body in one copy-ready block.\n\n## Message Rules\n\n- Describe the reason or behavior change, not a file list.\n- Keep the subject specific, imperative, and free of trailing punctuation.\n- Choose the narrowest accurate scope already used by nearby commits. When the tree spans unrelated areas, omit a misleading narrow scope rather than picking one feature.\n- Use `feat`, `fix`, `refactor`, `docs`, `test`, `build`, or `chore` only when it matches the diff.\n- Cover every distinct change in the same message. Unrelated features still belong in one subject-plus-body: name each behavior so a reviewer can see all of them without reading the file list.\n- When one change dominates, put it in the subject and name the others in the body. When two or more are peer features, name both in the subject if they fit; otherwise use a broader subject and give each change its own sentence in the body.\n- Always write a body that expands the why or the non-obvious behavior. One or two sentences is enough for a single change; use one short sentence per distinct change when the tree contains more than one. Do not leave the body empty.\n- Do not run formatting, tests, hooks, or other validation; the caller has already completed validation before requesting the message.\n\n## Completion\n\nReturn exactly one fenced text block the user can copy as a full commit message: subject, a blank line, then the body. After the block, add a brief note only if the diff is empty. Do not claim that a commit was created.\n\n```text\ntype(scope): imperative summary\n\nBody that explains the why or the non-obvious behavior.\n```\n",".agents/skills/wox-i18n/SKILL.md":"---\nname: wox-i18n\ndescription: Add a new Wox language or complete and improve an existing Wox translation. Use for Wox-owned locale registration, translation parity, wording quality, and placeholder-safe updates based on wox.core/resource/lang/en_US.json.\n---\n\n# Wox I18n\n\nUse `wox.core/resource/lang/en_US.json` as the authoritative source for keys, meaning, structure, and placeholders. Work on one requested locale at a time unless the user explicitly asks for several.\n\n## Shared rules\n\n- Read the repository `AGENTS.md` and the relevant locale files before editing.\n- Preserve every placeholder exactly, including `{name}`, Wox placeholders such as `{wox:selected_text}`, printf verbs such as `%s` and `%02d`, newlines, and other formatting tokens. Reordering placeholders is allowed only when the format mechanism supports it and the target language requires it.\n- Resolve ambiguous English by searching for the key's call sites and neighboring translations. Translate the UI meaning, not the key name in isolation.\n- Keep product names, commands, file paths, URLs, keyboard shortcuts, and technical identifiers unchanged when they are proper names or literal input.\n- Match the tone and terminology already used by the target locale. Prefer natural, concise UI text over literal translation.\n- Keep JSON valid, formatted with two-space indentation and a final newline. Preserve English key order; insert missing entries beside their English counterparts instead of reordering unrelated entries.\n- Do not put Wox-owned translations in Go maps. Keep them in `wox.core/resource/lang/*.json` and reference them with `i18n:` keys, as required by the repository instructions.\n- Do not blanket-translate third-party entries in `store-plugin.json`; their translations belong to their authors. Wox-owned catalogs such as `store-ai-command.json` are in scope when they contain the target locale.\n\n## Choose the workflow\n\n### Add a new language\n\nUse commit `0cfb2a346af4278c5cd385aa649cb9ddb641f461` as a concrete checklist, but follow the current tree when it has evolved:\n\n```powershell\ngit show --stat 0cfb2a346af4278c5cd385aa649cb9ddb641f461\ngit show 0cfb2a346af4278c5cd385aa649cb9ddb641f461 -- wox.core/i18n/lang.go store-ai-command.json wox.core/ui/launcher/view/form_table_view_test.go www/docs/.vitepress/theme/components/pluginStore.ts www/docs/development/plugins/specification.md www/docs/zh/development/plugins/specification.md AGENTS.md\n```\n\nThen make the smallest complete current-tree change:\n\n1. Confirm the locale code, English language name, and native display name.\n2. Create `wox.core/resource/lang/<locale>.json` with every key from `en_US.json`, in the same order, fully translated.\n3. Register the `LangCode` and native display name in `wox.core/i18n/lang.go`.\n4. Add the locale to Wox-owned locale maps, currently including `store-ai-command.json`, and to website locale mapping where applicable.\n5. Update current supported-language documentation and any tests that explicitly enumerate languages or translated labels.\n6. Search for the existing locale codes to find registration surfaces added after the reference commit. Update only surfaces whose behavior depends on the complete supported-language list.\n\nDo not create a translated documentation site merely because the app gains a locale; add one only when the user requests and supplies that scope.\n\n### Complete or improve an existing language\n\n1. Run the checker to identify missing, extra, empty, identical-to-English, and placeholder-mismatched values.\n2. Add every missing English key and translate it from the English value. Treat identical values as review candidates, not automatic errors: names and technical terms may legitimately remain English.\n3. For requested quality improvements, inspect awkward or stale values in related groups and their call sites. Change only wording you can improve confidently.\n4. Remove an extra key only after confirming that it is absent from `en_US.json` and unused; otherwise report it for review.\n5. Check Wox-owned auxiliary catalogs, especially `store-ai-command.json`, for missing target-locale entries when the request is to complete the language across Wox.\n\nAvoid replacing the whole locale file when a focused insertion or wording edit produces a clear diff.\n\n## Verification\n\nRun from the repository root:\n\n```powershell\npython .agents/skills/wox-i18n/scripts/check_locale.py <locale>\ngit diff --check\n```\n\nThe checker must pass without missing keys, extra keys, empty values, or placeholder mismatches. Review its identical-value warnings manually.\n\nIf language registration or enumerating tests changed, run the focused Go tests from `wox.core`:\n\n```powershell\ngo test ./i18n ./ui/launcher/view\n```\n\nFinish by reviewing the diff for accidental English fallback text, placeholder damage, unrelated rewrites, and omissions from the reference-commit checklist.\n",".agents/skills/wox-memory-debug/SKILL.md":"---\nname: wox-memory-debug\ndescription: Diagnose memory leaks in the current single-process Wox Go UI by launching the real debug build with its automation endpoint enabled, replaying representative launcher searches and settings-window open/close cycles, sampling the same process across repeated workload blocks, and comparing Go heap profiles when retained memory keeps growing. Use for Wox memory-leak checks, search-result retention, settings cleanup, Go UI memory growth, or repeated UI lifecycle regressions on Windows or macOS.\n---\n\n# Wox Memory Debug\n\n## Goal\n\nRun the real Go UI in debug mode with the `wox_automation` endpoint, exercise normal launcher searches and the independent settings-window lifecycle through the semantics tree, and decide whether memory settles after warm-up or grows with repeated work. Treat Wox as one Go process and use post-warm-up growth rather than an absolute memory budget as the leak criterion.\n\n## Run the Debug Build\n\n1. Stop other Wox instances so sampling cannot select the wrong process.\n2. Start the real Wox debug build under Delve with both production dependencies and the automation endpoint enabled:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\nWOX_AUTOMATION_INFO_FILE=/tmp/wox-memory-automation.json /Users/qianlifeng/go/bin/dlv debug . --build-flags=-tags=sqlite_fts5,wox_automation\n```\n\n3. At the Delve prompt, run `continue`.\n4. Wait until startup and plugin initialization finish, then wait for `WOX_AUTOMATION_INFO_FILE` to be written.\n5. Record the debuggee PID from the debugger. Always pass this PID to the sampler because debugger-built executables may have temporary names.\n\nKeep the debugger running normally. Do not pause at breakpoints while collecting memory samples. This uses the real Wox process with only the automation server compiled in; do not launch the separate Go UI smoke-test runner.\n\n## Establish a Warm Baseline\n\nUse the bundled automation workload driver against the real launcher:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\ngo run ../.agents/skills/wox-memory-debug/scripts/run-query-workload.go -info /tmp/wox-memory-automation.json -mode queries -count 20 -seed 1\n```\n\n1. Run two warm-up blocks before recording the baseline.\n2. In each block, replay 20 queries drawn repeatedly from these safe categories:\n   - Calculator, such as `1+1`.\n   - System command lookup, such as `settings`.\n   - Application or general search, such as `wox`.\n   - File-oriented search, such as `readme`.\n3. Use a different deterministic seed for each block so the workload is reproducible while still varying result types.\n4. The driver waits for the query value, allows results to settle, records the visible result count and semantics generation, clears the query, and continues. It does not execute results or commands.\n5. At the end of the block, the driver hides the launcher. Wait 10 seconds so every checkpoint uses the same idle state.\n\nTake the warm baseline only after these blocks. Initial startup growth, lazy font loading, icon decoding, and cache creation are expected and are not leak evidence.\n\n## Sample the Same Process\n\n### macOS\n\n```bash\n/Users/qianlifeng/Projects/Wox/.agents/skills/wox-memory-debug/scripts/sample-wox-memory-macos.sh --pid <PID> --samples 3 --interval 2\n```\n\nUse `PhysicalFootprintMB`. Absolute debug memory is not the leak criterion.\n\n### Windows\n\n```powershell\npowershell -ExecutionPolicy Bypass -File C:\\dev\\Wox\\.agents\\skills\\wox-memory-debug\\scripts\\sample-wox-memory.ps1 -Pids <PID> -Samples 3 -IntervalSeconds 2\n```\n\nUse `PrivateWorkingSetMB`.\n\nDo not compare macOS physical footprint with Windows private working set. Compare checkpoints from the same PID, OS, debug session, workload, and idle state.\n\n## Run the Measured Query Workload\n\n1. Record the warm baseline.\n2. Run five measured blocks of 10 or 20 queries using distinct seeds and the same query pool.\n3. After each block, clear the query, hide the launcher, wait 10 seconds, and sample the same PID three times.\n4. Record the median of each three-sample checkpoint to reduce sampler noise.\n5. Report cumulative query count, median memory, change from the warm baseline, and the observed shape of the series.\n\nUse more blocks only when the trend is ambiguous. Keep the process alive for the whole run; restarting Wox invalidates the comparison.\n\n## Test Settings Window Cleanup\n\nRun this lifecycle check after the query workload. It opens settings through the real `Open Wox Settings` result, waits for the independent settings semantics host, closes the settings window, waits until the launcher host owns automation again, and clears the opening query:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\ngo run ../.agents/skills/wox-memory-debug/scripts/run-query-workload.go -info /tmp/wox-memory-automation.json -mode settings -count 1\n```\n\n1. Run one settings cycle as warm-up. Wait 10 seconds and record the closed-settings baseline.\n2. Run at least three measured blocks of five open/close cycles:\n\n```bash\ngo run ../.agents/skills/wox-memory-debug/scripts/run-query-workload.go -info /tmp/wox-memory-automation.json -mode settings -count 5\n```\n\n3. After each block, keep both launcher and settings closed, wait 10 seconds, and sample the same PID three times. Record the median.\n4. Confirm every cycle reports both an `opened_generation` and `closed_generation`. The driver considers close complete only after `settings-search-field` disappears and `launcher.query.input` returns, which means `settingsView` and `settingsHost` have left the active automation surface.\n5. Compare measured block medians with the post-warm-up closed-settings baseline. Repeat one identical five-cycle block after a 30-second idle checkpoint when the trend is ambiguous.\n\nThe first settings open may retain shared fonts, icons, and reusable renderer caches. Do not require the process to return to its pre-first-open value. Window-scoped settings state and native resources must not accumulate across later cycles: after warm-up, closed-settings checkpoints should plateau within sampler jitter instead of growing with cumulative open/close count.\n\n## macOS Debug Reference\n\nUse the August 10, 2026 macOS arm64 run as a comparison point for the current settings cleanup behavior, not as an absolute budget. The run used macOS 26.5.2, Go 1.26.2, Delve 1.26.2, the `sqlite_fts5,wox_automation` build tags, real Wox data, one PID, a 10-second hidden/closed wait, and three `PhysicalFootprintMB` samples at two-second intervals.\n\nThe query baseline was recorded after two 20-query warm-up blocks. The settings baseline was recorded after one complete warm-up open/close cycle:\n\n| Checkpoint | Median PhysicalFootprintMB | Change from closed-settings baseline |\n| --- | ---: | ---: |\n| Hidden after 40 warm-up queries | 89.1 MB | N/A |\n| Settings closed warm baseline | 99.5 MB | 0.0 MB |\n| 5 measured settings cycles | 100.9 MB | +1.4 MB |\n| 10 measured settings cycles | 101.4 MB | +1.9 MB |\n| 15 measured settings cycles | 101.7 MB | +2.2 MB |\n| 30-second idle confirmation | 102.3 MB | +2.8 MB |\n\nClassify this series as `no leak signal`: the closed-settings checkpoints remained around 100-102 MB, and the 30-second confirmation stayed within observed sampler and allocator variation. `vmmap` reported no resident IOSurface memory after close; CoreGraphics and IOAccelerator residency was negligible. A Go heap comparison captured during the investigation showed only about 15 KB of retained delta, which redirected attribution to native window ownership rather than Go settings state.\n\nPreserve these cleanup contracts when investigating a regression:\n\n- Keep at most one live `wox.settings` window, while still treating each close/reopen as a new native lifetime.\n- Release settings-only plugin catalogs, search indexes, forms, and application candidates on close, and invalidate in-flight loads so they cannot refill released caches.\n- Load the plugin store and application candidates only when their UI needs them.\n- Release the macOS `NSWindow`, view, and delegate hierarchy synchronously on close. Do not defer them to the application-lifetime autorelease pool.\n\nBefore the native close fix, a separate same-shape debug run rose from 104.8 MB after the warm settings close to 112.8 MB after 15 measured cycles. Treat a return of that cumulative, window-count-scaled shape as a regression even when the absolute starting footprint differs.\n\n## Windows Debug Reference\n\nUse the September 22, 2026 Windows run as a comparison point for hidden idle memory, not as a budget. The run used a dev build with `sqlite_fts5,wox_automation`, real Wox data, two 20-query warm-up blocks, and three `PrivateWorkingSetMB` samples 45 seconds after hide, when both the 10-second and 30-second release stages had run:\n\n| Checkpoint | Median PrivateWorkingSetMB | Live Go heap |\n| --- | ---: | ---: |\n| Staged trims plus prepared search text and pinyin release | 63.8 MB | 17.2 MB |\n| Shared plugin logger and shared fsnotify watcher | 60.8 MB | 15.2 MB |\n| Live-object reductions (`wox.core/ui/README.md`, \"Hidden-state ownership rules\") | 55.4 MB | 11.0 MB |\n\nHidden memory drops in two steps: about 2-4 MB at 10 seconds and about 40 MB at 30 seconds, so sampling before 45 seconds compares different lifecycle states. When attributing what remains, use Delve `goroutines -group userloc` for goroutine ownership and the `woxmemory go` / `woxmemory native` commands for the Go-versus-native split; the largest native owners are NT heap fragmentation from show/hide churn and renderer objects that survive hide.\n\n## Decide Whether Memory Leaks\n\nInterpret the post-warm-up series, not a single number:\n\n- **No leak signal:** memory rises during warm-up and then plateaus, oscillates within a stable range, or drops after an idle checkpoint.\n- **Possible leak:** the settled checkpoint median keeps increasing across at least three consecutive measured blocks and the increase is materially larger than sampler jitter.\n- **Strong leak signal:** retained growth continues after another identical workload, scales with cumulative query or settings-cycle count, and does not settle during a longer 30-60 second idle checkpoint.\n\nApply the same classification independently to cumulative queries and cumulative settings cycles. A stable query series does not rule out a settings-window lifecycle leak.\n\nGo may retain heap arenas after objects become unreachable, so a high or non-decreasing process footprint alone is not proof. Report the result as `no leak signal`, `possible leak`, or `strong leak signal`, together with the measurements that support it.\n\n## Attribute Persistent Growth\n\nOnly profile after the repeated-query or settings-lifecycle run shows a possible or strong leak signal.\n\n1. Trigger the Wox Memory plugin's `woxmemory profile ` command through the automation driver after warm-up:\n\n```bash\ngo run ../.agents/skills/wox-memory-debug/scripts/run-query-workload.go -info /tmp/wox-memory-automation.json -mode profile\n```\n2. Copy the generated profile immediately because the next capture overwrites it:\n\n```bash\ncp ~/.wox/memory.prof /tmp/wox-memory-before.prof\n```\n\nOn Windows, copy `%USERPROFILE%\\.wox\\memory.prof` to a distinct temporary file instead.\n\n3. Repeat the measured workload, run the command again, and copy the second profile:\n\n```bash\ncp ~/.wox/memory.prof /tmp/wox-memory-after.prof\n```\n\n4. Compare retained Go heap growth from `wox.core`:\n\n```bash\ngo tool pprof -top -base /tmp/wox-memory-before.prof /tmp/wox-memory-after.prof\n```\n\nIf process memory grows but the Go heap delta stays small, inspect Go UI native owners next: GPU textures and image caches, decoded result icons, preview resources, platform window allocations, and query-result cleanup. For settings-only growth, inspect `settingsView`, `settingsHost`, settings editors/forms, theme wallpaper previews, cloud/model state, asynchronous reloads, and native window/renderer destruction. On macOS, compare `vmmap <PID> -summary` checkpoints and pay particular attention to `IOAccelerator` and `IOSurface`. If repeated identical queries still grow, inspect lazy-image cache identity, per-draw Metal texture creation, and drawable-size churn before attributing growth to unique query strings.\n\nUse `-query terminal` with query mode for an identical-query control only when the mixed workload needs further attribution.\n\n## Report\n\nInclude:\n\n- OS, debug configuration, PID, workload, and checkpoint timing.\n- A checkpoint table with cumulative queries and median process memory.\n- A separate closed-settings checkpoint table with cumulative open/close cycles and median process memory.\n- The trend classification and whether a longer confirmation block was needed.\n- Go heap delta owners only when profiling was necessary.\n- Any limitation that prevented consistent UI automation or reliable sampling.\n\nDo not edit production code until the measurements identify a reproducible trend and a likely owner.\n",".agents/skills/wox-plugin-creator/SKILL.md":"---\nname: wox-plugin-creator\ndescription: Create, scaffold, implement, and package Wox plugins (nodejs, python, singlefile-python, singlefile-nodejs). Use when cloning official SDK templates, generating single-file SDK plugin templates, editing plugin.json metadata, defining SettingDefinitions and validators, wiring i18n, implementing plugin APIs, QueryResponse refinements, refinement and action hotkeys, structured query slots, Plugin Tools (RegisterPluginTool / InvokePluginTool), 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.\n---\n\n# Wox Plugin Creator\n\n## Quick Start\n\n- Scaffold a Node.js plugin (clones template repo):\n  - `python3 scripts/scaffold_wox_plugin.py --type nodejs --output-dir ./MyPlugin --name \"My Plugin\" --trigger-keywords my`\n- Scaffold a Python plugin (clones template repo):\n  - `python3 scripts/scaffold_wox_plugin.py --type python --output-dir ./MyPlugin --name \"My Plugin\" --trigger-keywords my`\n- Scaffold a single-file SDK plugin (uses local templates; plugin-id auto-generated; writes **one** file into the live user plugin directory so a running Wox instance can load it immediately). Omit `--output-dir`; default is `~/.wox/wox-user/plugins/single-file/` (Windows: `%USERPROFILE%\\.wox\\wox-user\\plugins\\single-file\\`):\n  - Auto-detect this machine: `python3 scripts/scaffold_wox_plugin.py --type singlefile --name \"Weather\" --trigger-keywords weather`\n  - Explicit Node.js: `python3 scripts/scaffold_wox_plugin.py --type singlefile-nodejs --name \"Weather\" --trigger-keywords weather`\n  - Explicit Python: `python3 scripts/scaffold_wox_plugin.py --type singlefile-python --name \"Weather\" --trigger-keywords weather`\n\n## Choose a plugin type\n\n- **Single-file SDK plugin**: one `.py` or CommonJS `.js` file with full Public API, loaded into the existing Python/Node runtime host. No extra process per query. Create and edit **only** `~/.wox/wox-user/plugins/single-file/Wox.Plugin.<Name>.js` (or `.py`); Wox watches that directory and reloads on save. Requires Wox 2.4.2+; header `MinWoxVersion` must be `\"2.4.2\"`.\n- **SDK plugin (`.wox`)**: multi-file package with dependencies, resources, TypeScript, and `plugin.json`.\n\nNode.js first version must stay CommonJS (`module.exports.plugin`) and must not import `@wox-launcher/wox-plugin`.\n\n## Choose a runtime language\n\nHonor an explicit Python or Node.js request from the user, including a `.py` or `.js` output filename.\n\nWhen the user does not specify a language, detect this machine before scaffolding. Do not default to Python.\n\n1. Run `python3 scripts/detect_local_runtime.py` (use `python` if `python3` is missing). It prints `nodejs`, `python`, or `none`.\n2. If that script cannot run, check the floors yourself: `node --version` for Node.js 20+, and `python3 --version` for Python 3.10+. On Windows also try `py -3 --version` and `python --version`.\n3. Decision:\n   - Only one runtime meets the floor → use that runtime\n   - Both meet the floor → use Node.js\n   - Neither meets the floor → ask the user which language they want\n4. Map the choice to `--type`: `singlefile-nodejs` / `singlefile-python`, or `nodejs` / `python`. `--type singlefile` applies the same detection inside the scaffold.\n\n## Workflow\n\n### 1) Scaffold plugin files\n\n- Use `scripts/scaffold_wox_plugin.py` for `nodejs`, `python`, `singlefile`, `singlefile-python`, or `singlefile-nodejs`.\n- Pass `--name` and `--trigger-keywords` for every runtime. The scaffold exits without them. `--output-dir` is required for packaged SDK plugins; omit it for single-file SDK plugins so the file lands in `~/.wox/wox-user/plugins/single-file/`.\n- For Node.js and Python packages, the scaffold clones the official template repos and replaces placeholders like `{{.ID}}`, `{{.Name}}`, `{{.Description}}`, `{{.TriggerKeywordsJSON}}`, `{{.Author}}`.\n- Before starting work in a new SDK plugin project, run `make init` in the project root when the project has not been initialized yet.\n- Single-file SDK plugins are **single-file** host-loaded plugins. Prefer filenames like `Wox.Plugin.<Name>.js` or `Wox.Plugin.<Name>.py`.\n- **Single-file SDK destination**: create and implement the plugin as one file in `~/.wox/wox-user/plugins/single-file/` (Windows: `%USERPROFILE%\\.wox\\wox-user\\plugins\\single-file\\`). That directory is what a running Wox instance loads; saving reloads after about 500ms, so the user can query the trigger keyword immediately. Omit `--output-dir` when using the scaffold, or write the file there directly from `assets/single_file_plugin_templates/`. Do not also create a copy under the current repository (`plugins/`, workspace root, or a new folder). Pass `--output-dir` only when the user asks for a different path.\n- Do not put companion files (`*.test.js`, README, extra modules) in the live directory. Wox loads every `.js` and `.py` there as a plugin.\n- Single-file SDK plugins must set header `MinWoxVersion` to `\"2.4.2\"`. The scaffold applies this default when `--min-wox-version` is omitted. Do not lower it; Wox 2.4.2 is the first release that can load this plugin type, and store/CI reject older floors.\n- For single-file SDK plugins, the scaffold copies templates from `~/.wox/ai/skills/wox-plugin-creator/assets/single_file_plugin_templates/` (or the repo `.agents/skills/wox-plugin-creator/assets/single_file_plugin_templates/` fallback).\n- Prefer standard library features; avoid third-party dependencies unless absolutely necessary. Single-file SDK plugins cannot use pip/npm packages.\n- For SDK usage and API details, read `references/sdk_nodejs.md` or `references/sdk_python.md`.\n- For plugins declaring `querySelection`, return results only for selection types and content the plugin can process. Return an empty results list for unsupported, missing, or empty selection data instead of showing usage or help rows for unrelated selections.\n- Keep a result on the row. `Title` is the name to scan. `SubTitle` is one short identity line, such as a code, place, or source. `Tails` are the few facts that must stay visible, such as a price and its change. Use at most three tail tags on one result. A fourth tag can be clipped, so part of a tag is not shown. Put any further fact in the subtitle, the copied text, or a preview. Do not add `Preview` for a quote, status, short record, or anything that fits on that row.\n- A durable result must set `IdentityKey` (Python `identity_key`, script JSON `identity_key`). Wox uses it for usage history, query pins, and MRU. The value must identify that one result and no other result from the plugin, and it must stay the same when the title, subtitle, translation, score, or query text changes. Use the item's own id, such as a path, URL, note id, command id, or record id. Do not use the visible title, a translated string, the current query, a random id, or one shared key for a whole list. The same item returned from search and from MRU restore must use the same key. `score_key` / `ScoreKey` is only the older name. Omit `IdentityKey` on a temporary result: a prompt, an empty or error state, a one-time status, or a row that exists only for the current selection or query and will not be pinned or restored.\n- A text tail already has a theme-aware rounded container. Use an SVG image tail only when that tag must also contain an icon. Match the launcher metrics below, and see [Simulated tail tags](#simulated-tail-tags).\n- Refresh a visible row in place with `UpdateResult` / `update_result`. Remember the results returned by the latest `query()`. Replace that list on the next query. When a background refresh or an action changes a row that is still on screen, call `UpdateResult` with the same result `Id` and only the fields that changed (`Title`, `SubTitle`, `Icon`, `Tails`, `Actions`). The query text stays put and the list does not reload. Use `RefreshQuery` / `refresh_query` only when rows must be added or removed and `UpdateResult` cannot express that. Do not use `ChangeQuery` to redraw results.\n- Add `Preview` only for a large body that cannot fit the row: a long document, many fields, a chart, a gallery, or syntax highlighting. When a preview is required, use `markdown` for prose, lists, links, and images. Use `text` or `image` when that is the whole preview. Use `webview` HTML only after markdown cannot express it, such as syntax highlighting, folding, or an interactive layout. HTML is the last option because the webview can steal query focus, miss launcher theme colors, and hit layout bugs. There is no separate `html` preview type; HTML uses `webview` with a JSON-encoded `html` field and no local HTTP server. See the HTML preview examples in the SDK references.\n- For dynamic updates to an existing HTML WebView, prefer script-mode `UpdateResult` / `update_result` with `{\"updateMode\":\"script\",\"script\":\"...\"}` instead of repeatedly replacing the full HTML. Update existing DOM nodes to preserve scrolling, text selection, and animations. This does not change the rule that HTML is the last preview option. Read [HTML preview updates](references/html_preview_updates.md) for the contract, lifecycle, safe serialization, and Python/Node.js examples.\n- Do not rasterize documents as SVG/`image` previews; those scale as pictures, cannot select text, and do not follow theme colors.\n- When HTML is required, follow the current Wox theme. Call `GetThemeColors` / `get_theme_colors` (Wox >= 2.4.5) when building the HTML and paint opaque `Background`, `Text`, `SecondaryText`, `Border`, `Accent`, `AccentText`, and `Selection`. Use `Dark` to choose a light or dark syntax palette. Do not hardcode only a dark page, and do not rely on `transparent` or `prefers-color-scheme` as a substitute for the launcher palette. Include a theme color in `cacheKey` so the preview refreshes after a theme change. If the API is missing, fall back to a dark and a light default.\n- For inline command arguments or atomic query blocks, read [QueryHint](#queryhint). Command declarations contain suffix templates; `ChangeQuery` contains a complete instance. Keep legacy text parsing when structure is absent.\n- For query-scoped filters or sort controls, return `QueryResponse.Refinements` and read [references/refinements.md](references/refinements.md).\n- Before assigning refinement or result action hotkeys, read [references/hotkeys.md](references/hotkeys.md). Prefer defaults that avoid Wox window commands, launcher bindings, focused-editor commands, and shortcuts for the plugin's preview type. Check refinements and actions together for duplicates; choose another chord or leave `Hotkey` empty when it conflicts. Do not assume adding Shift makes a built-in chord available.\n- For `plugin.json`, `SettingDefinitions`, `QueryRequirements`, validators, dynamic settings, and feature flags, read `references/plugin_json_schema.md` first.\n- When implementing an SDK or single-file SDK plugin, also register Plugin Tools in `init()` for capabilities other plugins should be able to call. Query results and actions stay for the user; tools expose the same work as structured operations. Read `references/plugin_tools.md` first. Requires Wox >= 2.4.5 (`MinWoxVersion` `\"2.4.5\"` or newer). Do not declare tools in `plugin.json`.\n- SDK and single-file SDK plugins should support MRU unless the plugin is clearly unsuitable. Declare the `mru` feature with `HashBy` `identityKey`, put restore identity on action `ContextData`, and register `OnMRURestore` / `on_mru_restore` in `init()`. The restored result must use the same `IdentityKey` as the original result. The restore callback must return immediately from memory or local cache. Wox waits 300ms for each start-page MRU restore, then discards that item, logs the timeout, and shows the next MRU item. Do not fetch, scan disk, or call host APIs inside the callback. Skip MRU only for context-dependent, one-shot, diagnostic, or inbox-style plugins, and say why in the implementation notes.\n- Persist user settings through the Public API (`GetSetting` / `SaveSetting` / `SetSetting` / `OnSettingChanged`, or Python `get_setting` / `save_setting` / `set_setting` / `on_setting_changed`). A normal setting write is cloud-synced and follows the user across machines. Use these APIs for preferences, API keys, favorites, and account configuration.\n\n### Cache stays out of the settings API\n\nAnything the plugin can rebuild is cache: fetched JSON, subject or entity snapshots, search indexes, downloaded files, and thumbnails. Write that data under the plugin cache folder. Do not pass it to `SaveSetting`, `SetSetting`, `save_setting`, or `set_setting`.\n\nPlugin settings are cloud-synced. Each settings write becomes a sync record and is copied to the user's other devices, including a hidden key that is absent from `SettingDefinitions`. A cache blob stored this way is uploaded on every refresh and fills sync history. `IsPlatformSpecific` still syncs; it only keeps a separate value per operating system. `IsLocal` / `is_local` is for a small machine-local preference that must remain in the settings store, such as a window position. It is not a place for cache.\n\n- Call `GetCacheFolder(ctx)` / `get_cache_folder(ctx)` once in `init()`, keep the path, and write cache files under it.\n- The folder is `~/.wox/cache/plugins/<plugin-id>/`. Wox creates it and deletes it when the plugin is uninstalled.\n- Do not invent a `cache/`, `tmp/`, `downloads/`, or `data/` directory beside the plugin file, under user data, or under a hardcoded name.\n- When authoring `SettingDefinitions`, always decide whether each setting is platform-specific before shipping it. Wox cloud sync replicates normal plugin settings across devices, so local paths, executable paths, shell commands, hotkeys, system integrations, browser profiles, and application paths should usually set `IsPlatformSpecific: true`. Account IDs, API keys, remote service hosts, and cross-platform user preferences should usually keep `IsPlatformSpecific: false`.\n- Use `DisabledInPlatforms` only to disable a setting on selected platforms. It does not isolate stored values; use `IsPlatformSpecific` when the value must differ per platform after cloud sync.\n- When a plugin cannot run a query without required settings such as access keys, declare those requirements in metadata `QueryRequirements` instead of returning ad hoc setup results from `query()`.\n- Query refinements (type filters, sort modes, and similar query-scoped chips) belong on `QueryResponse.Refinements`, not in command syntax. When assigning a refinement `Hotkey`, use the platform primary modifier: `cmd+<key>` on macOS and `ctrl+<key>` on Windows/Linux. Detect the OS at runtime and emit the matching string; omit the binding if no suitable chord is available.\n- For ready-to-copy patterns such as validated textbox/select fields, editable tables, AI model selectors, and dynamic preview settings, read `references/settings_patterns.md`.\n- For Python settings APIs, note that helper builders are limited; advanced settings are often created by constructing `PluginSettingDefinitionItem` and value objects directly.\n\n### 2) Author result and action icons\n\n- Read `references/icons.md` before choosing any glyph. Result-row and plugin-identity icons may be colorful; Action Panel leading icons must not.\n- Scaffold templates use inline SVGs for the default plugin and result icons. Keep those defaults as SVG; use emoji or other formats only when deliberately choosing a result identity icon.\n- Prefer a bundled monochrome verb from `assets/iconify/action/` (copy, open, execute/lightning, delete, edit, paste, add, search, settings). These SVGs already use `var(--wox-theme-icon-color)` so the Action Panel can tint them to the row label.\n- Do not use emoji, brand logos, the plugin mark, or mixed-color result art as the leading action icon. The panel only tints SVGs that contain the theme variable; anything else stays authored and looks inconsistent next to system actions.\n- Execute actions use the lightning verb (`action/execute.svg`), not a gear or play triangle. Settings actions use the gear.\n- For a new action metaphor, fetch a monochrome Iconify outline with `scripts/search_iconify.py` (it rewrites `currentColor` to the theme variable by default). Use `--no-wox-theme` only for colorful **result** icons.\n- Single-file SDK plugins cannot use relative image paths. Inline the SVG for actions; emoji/URL/base64 are acceptable for result identity only.\n\n### 3) Package and submit plugin\n\n- For SDK plugins cloned from templates, run `make package` inside the template repo.\n- Single-file SDK plugins embed JSON metadata in the file header. Keep `MinWoxVersion` as `\"2.4.2\"`.\n- **Publish a single-file SDK plugin** on a public GitHub gist. That is the simplest store host. Reference: https://gist.github.com/qianlifeng/04a9609de66eaa582a473f5852450ede\n  1. Create one public gist file named `Wox.Plugin.<Name>.js` or `Wox.Plugin.<Name>.py`. The store `DownloadUrl` path must end with `.js` or `.py` (a gist URL without that suffix will not install). Example: `gh gist create --public --desc \"Wox.Plugin.YouTube\" Wox.Plugin.YouTube.js`\n  2. A screenshot of the plugin running in Wox is required. If the user has not provided one, stop and ask for it; do not continue the store submission without it. Use a cropped Wox launcher screenshot that shows the query and the plugin's real results, like https://raw.githubusercontent.com/Wox-launcher/Wox.Plugin.ColorPicker/main/images/screenshot1.png. Do not submit an icon, a README image, source code, or a full-desktop capture. Upload the screenshot and icon to GitHub (drag them onto the gist page or a gist comment). Copy the resulting `https://gist.github.com/user-attachments/assets/<id>` URLs, for example `https://gist.github.com/user-attachments/assets/7502acdc-1ea5-4ef6-a3fb-31875353dabe`.\n  3. Then follow `wox-plugin-submit2store`: clone Wox and add a `store-plugin.json` entry. `Website` is the gist HTML URL, `DownloadUrl` is the gist raw URL including the filename (`https://gist.githubusercontent.com/<user>/<gist-id>/raw/Wox.Plugin.<Name>.js`), `IconUrl` and `ScreenshotUrls` are the user-attachments URLs. Runtime is `nodejs` or `python`. Do not ship a `.wox` for this plugin type.\n- For packaged SDK plugins, use `wox-plugin-submit2store` with a GitHub repository and `.wox` release. Ask the user before submitting to the store. The store entry still requires at least one public screenshot; do not submit while `ScreenshotUrls` is missing or empty.\n\n## Simulated tail tags\n\nPrefer a native `text` tail whenever the label is only text. Wox draws compact rounded rectangles and owns theme, selected-row colors, font rendering, and density scaling. Use at most three tails on one result; additional facts belong in the subtitle, copied text, or a preview.\n\nUse an SVG `image` tail only when an icon and label must share one tag. Match the current native text-tail geometry; do not reuse the old pill shape or outlined capsule examples. At normal density, the logical dimensions are:\n\n| Property | Value |\n| --- | --- |\n| Height | 22 |\n| Corner radius | 4 (`rx=\"4\"`), not half the height |\n| Side inset | 7 on each side; text-only width is measured text width plus 14 |\n| Font | 11, regular weight |\n| Border | None; omit `stroke` |\n| Default | Row foreground text; background uses the same RGB at alpha 13/255, or 24/255 when selected |\n| Success | Fill `#027A48`, label `#FFFFFF` |\n| Danger | Fill `#B42318`, label `#FFFFFF` |\n| Warning | Fill `#B54708`, label `#FFFFFF` |\n\nUse native `TextCategory` / `text_category` for semantic text tails. Status fills remain solid; ordinary metadata has a subtle background. Do not make every secondary fact a status badge just to add color.\n\nFor an icon-and-label SVG, width is `7 + icon width + gap + measured label width + 7`. Set `ImageWidth` to that width and `ImageHeight` to 22, or the launcher defaults to a 20px image slot. For example, a 90-unit tag starts with `<svg viewBox=\"0 0 90 22\" ...><rect width=\"90\" height=\"22\" rx=\"4\" fill=\"#027A48\"/>...`, with no stroke. Keep the image-tail corners consistent with adjacent native tags.\n\nImage tails keep their authored colors; Wox does not automatically apply text-tail selection or theme styling to them. For neutral metadata, prefer native text instead of hardcoding white text on a transparent SVG. If a custom image is necessary, use `GetThemeColors` / `get_theme_colors` to choose readable light/dark colors and include those colors in its cache key. Avoid claiming an SVG matches selected-row styling when the plugin has no selection state.\n\nDraw side-by-side icon labels as filled glyph paths inside the SVG. The SVG rasterizer does not draw general `<text>`. One `<text text-anchor=\"middle\">` whose `x` is the viewBox center is extracted and painted centered on the whole image; it is unsuitable for a label beside an icon because that shifts the intended spacing.\n\n## QueryHint\n\n`QueryHint` is optional semantic background guidance for `input` queries. It can\ncarry actual argument values, but must never turn continuous input into a mandatory\nform. Preserve normal caret movement, cross-element selection, deletion, clipboard,\nundo and IME behavior. Tab is optional. When editing invalidates a semantic boundary,\nkeep the user's text and discard unreliable metadata rather than blocking input.\n\n- Declare suffix elements in `Commands[].QueryHint`; `Aliases` use the same trigger.\n  Wox inserts the matched command prefix with reserved ID `command`. Static metadata\n  and `RegisterQueryCommands` / `register_query_commands` use the same model.\n- `ChangeQuery` always requires `QueryType` and complete `QueryText` for input,\n  or complete `QuerySelection` for selection. `QueryHint` is optional visual\n  enhancement, never a replacement for query content. An input hint must describe\n  exactly the supplied text, including trigger keyword, command, separators and values.\n  An invalid or mismatching hint is ignored; the supplied `QueryText` is used unchanged. Explicit `QueryText: \"\"` remains valid for clearing.\n  Python uses `ChangeQueryParam(query_type=QueryType.INPUT, query_text=\"set volume 50\",\n  query_hint=QueryHint(elements=[...]))`; `QueryHint` and `QueryElement` are SDK exports.\n- Elements have nonempty, unique `Id` values. `text` uses `Text` (including explicit\n  separators); `argument` uses `Value`, optional `Placeholder` and `Required`;\n  `block` uses atomic `Value`. A highlighted argument remains freely editable.\n- Placeholders support `i18n:` and never enter the query value or clipboard.\n  `Required` is descriptive: validate empty values and business constraints before\n  offering or executing actions. Querying itself must not perform the action.\n- Read values by ID from `query.QueryHint.Elements` (Node.js) or\n  `query.query_hint.elements` (Python). Keep legacy `Search` / `search` parsing when\n  the hint is absent; an empty argument is not an absent hint. Wox supplies a lossy\n  plain-text projection in existing query fields; do not reconstruct boundaries from it.\n- Complete commands preview hints; space or Tab activates the template. Whole-command\n  paste into ordinary text is not parsed into arguments. Reopening selects the entire\n  query for replacement; undo and history preserve hints when possible.\n- Keep the list flat; no nested elements, dropdowns, custom rendering or inline markup.\n  Hints never carry plugin identity or create a scope. Routing uses the normal query\n  text and explicit `QueryScope`; complete instances must include the trigger keyword\n  when needed (for example `gh issues `). If both text and a hint are passed to `ChangeQuery`,\n  the explicit query text remains authoritative; the hint must match it.\n- Use SDK or single-file SDK APIs. Verify the first supporting Wox/SDK release before setting\n  distribution requirements; the single-file runtime version floor alone is insufficient.\n- Validate blank/valid/invalid arguments, multiple arguments, whole-query replacement\n  after reopen, undo and the legacy path. Set Volume is the first built-in example.\n\nExample command suffix (Wox adds the command text):\n\n```json\n{\n  \"Command\": \"set-volume\",\n  \"Aliases\": [\"set volume\", \"volume\"],\n  \"QueryHint\": {\n    \"Elements\": [\n      { \"Id\": \"volume\", \"Kind\": \"argument\", \"Placeholder\": \"Volume (0–100)\", \"Required\": true }\n    ]\n  }\n}\n```\n\n## Runtime Requirements\n\nWox enforces the same interpreter floors for SDK plugins and single-file SDK plugins. Store install fails, and queries show a setup result, when the machine is below these versions:\n\n- **Python**: 3.10 or later\n- **Node.js**: 20 or later\n\nDo not target older interpreters. Single-file SDK plugins run inside Wox's existing Python/Node runtime host and require **Wox 2.4.2 or later** (`MinWoxVersion`: `\"2.4.2\"`).\n\n## Resources\n\n- scripts: `scripts/scaffold_wox_plugin.py`, `scripts/detect_local_runtime.py`, `scripts/search_iconify.py`\n- references: `references/plugin_overview.md`, `references/scaffold_nodejs.md`, `references/scaffold_python.md`, `references/sdk_nodejs.md`, `references/sdk_python.md`, `references/plugin_json_schema.md`, `references/settings_patterns.md`, `references/plugin_i18n.md`, `references/icons.md`, `references/refinements.md`, `references/hotkeys.md`, `references/plugin_tools.md`\n- assets: `assets/single_file_plugin_templates/`, `assets/iconify/action/`\n",".agents/skills/wox-changelog-update/SKILL.md":"---\nname: wox-changelog-update\ndescription: Update Wox CHANGELOG.md and CHANGELOG.zh_CN.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.\n---\n\n# Wox Update Changelog\n\n## Overview\n\nUpdate `CHANGELOG.md` and `CHANGELOG.zh_CN.md` from the latest released version to `HEAD` and keep wording, section order, and markdown style consistent with existing entries. The two files must describe the same release with the same structure; only the language of user-facing prose changes.\n\n## Workflow\n\n1. Identify the release boundary.\n\n- Read the top of `CHANGELOG.md` and `CHANGELOG.zh_CN.md` and detect the target section (usually newest version at the top).\n- Detect the last released tag with `git tag --sort=-creatordate`.\n- Use commit range `last_release_tag..HEAD` by default.\n- If changelog heading and git tag disagree, prefer changelog context and state the assumption.\n\n2. Collect candidate changes.\n\n- Run `git log --oneline --no-merges <range>`.\n- Open key commits with `git show --stat --oneline <sha>` to classify user-facing impact.\n- Check whether each included change came through a pull request. Inspect merge commits as well as the non-merge log, and use GitHub's commit-to-PR lookup or PR metadata for squash/rebase merges or unclear local history. Record the PR URL and the contributor's verified GitHub login; use the PR author, not the person who merged it. Do not infer a login from a commit display name or email. If attribution cannot be verified, report that gap instead of guessing or silently omitting it.\n- Ignore pure build/version bump commits unless they change user-visible behavior.\n- Collect store catalog additions separately from app/core commits. Compare `store-plugin.json` and `store-theme.json` at `last_release_tag` vs `HEAD`. A store item is new only when its `Id` (plugin) or `ThemeId` (theme) is absent from the last release file. Ignore version bumps, field edits, and other updates to existing store entries. Ignore bundled script plugin version bumps.\n- Do not put third-party store catalog changes in `Add`, `Improve`, or `Fix`. List only newly added store plugins and themes in `Store`.\n\n3. Classify into changelog buckets.\n\n- `Add`: major, clearly new user-visible capabilities, workflows, plugins, or standalone feature areas.\n- `Improve`: behavioral or UX improvements without new core capability.\n- `Fix`: user-facing bug fixes/regressions.\n- `Store`: plugins and themes newly listed in the Wox store during this range.\n- Omit the `Add` section when the release does not contain a substantial new feature. Prefer `Improve` for additions that extend an existing feature area rather than creating a new user workflow.\n- Omit the `Store` section when no new store plugin or theme IDs appeared in range.\n- Treat platform-specific implementations, provider additions, runtime dependency checks, searchable metadata, theme overrides, and similar support for existing systems as `Improve` unless the commit introduces a large new user-facing feature.\n- Exclude internal refactors/tests/docs/chore unless directly user-visible.\n- Exclude tiny UI-only polish by default (for example spacing, alignment, minor color/wording tweaks) unless it fixes a functional UX issue or the user explicitly asks to include small UI changes.\n\n4. Write changelog entries in repository style.\n\n- Preserve header pattern exactly (for example: `## v2.0.1 -`). Use the same heading, date, screenshots, issue links, and section keys in both files.\n- Keep section titles in English in both files: `- Add`, `- Improve`, `- Fix`, `- Store`. The client already localizes these labels.\n- Add a short highlight paragraph directly below every release heading you create or update, before screenshots and `Add`/`Improve`/`Fix`/`Store` sections. Follow the `v2.4.4` style: one or two short everyday sentences about the visible change, not the implementation. Example: a new Jade theme and Liquid Glass on macOS 26; Settings keep their own look so themes no longer change that window.\n- Write for ordinary users, not developers or reviewers. Describe what someone sees or can do after updating. Do not explain schemas, APIs, caches, indexes, host restarts, platform variants, or other internals unless that is the user-facing name of the feature (for example Liquid Glass, `cb paste`, `.wox`).\n- Prefer plain words over implementation labels: say \"Settings keep their own look\" instead of \"independent chrome\", \"every word must match\" instead of \"AND matching\", \"theme previews match the launcher\" instead of \"schema v2 sparse authoring\".\n- Keep section order: `Add`, `Improve`, `Fix`, `Store`.\n- Use bullet nesting style already used in file.\n- Keep wording concise, everyday, and factual. If a sentence needs a term a typical user would not know, rewrite it or drop that detail.\n- Match wording to the bucket. English `Improve` entries should say \"Improve\", \"Expand\", \"Support\", or similar, not \"Add\", unless the entry is intentionally describing a small added option inside an improvement.\n- For new `Add` features, explain what the feature is for and why a user would use it. Do not reduce major features to one terse implementation phrase.\n- Keep the same feature in one bullet whenever possible. For example, combine Screenshot scrolling capture, pinning, and plugin API changes into one `[`Screenshot`]` bullet instead of splitting them into separate bullets.\n- If a new feature needs screenshots but the images are not available yet, leave clearly named screenshot placeholder image lines in the same bullet so the screenshots can be added later.\n- Prefer plugin/module prefix when clear, e.g. ``[`Shell`]`` or ``[`Clipboard`]``.\n- Write issue references as Markdown links, e.g. `[#4339](https://github.com/Wox-launcher/Wox/issues/4339)`. Do not leave a bare `#4339` for the preview to rewrite later.\n- Every changelog item originating from a PR must credit its contributor with `[@username](https://github.com/username)` and link the PR as `[#1234](https://github.com/Wox-launcher/Wox/pull/1234)`. Apply this to `Add`, `Improve`, `Fix`, and `Store`, with identical attribution in both languages. When a bullet combines contributions from several PRs, credit each relevant PR author once. Keep store author credits; if that author is also the PR contributor, reuse the existing mention, otherwise append the PR contributor separately. For example: ``  - [`Notes`] Fix typing `- [ ] ` not creating a task. [#4618](https://github.com/Wox-launcher/Wox/pull/4618) [@lmgarret](https://github.com/lmgarret)``.\n- Keep existing screenshots. Add new screenshot lines when screenshots already exist, or when a user explicitly asks to reserve screenshot positions for upcoming images.\n- Write `Store` as two nested groups, omitting an empty group: `Plugin` then `Theme`. Each item is already-clickable Markdown: `[Name](page_url) Description [@github_username](https://github.com/github_username)`. Resolve `i18n:` names and descriptions from `I18n.en_US` in `CHANGELOG.md` and from `I18n.zh_CN` in `CHANGELOG.zh_CN.md` (`plugin_name`, `plugin_desc` or `plugin_description`). If a locale is missing, fall back to `en_US`, then `Name` / `Description`. Use `ThemeName` and `Description` for themes. Link the name to `Website` (plugin) or `ThemeUrl` (theme). If that URL is empty, write the plain name without a link. Append the author as a GitHub profile link. Prefer the username from a `github.com` / `gist.github.com` `Website` or `ThemeUrl`; otherwise use `Author` or `ThemeAuthor` when it is a single handle. Skip the author link when the author is only a display name. Do not add store screenshots, download URLs, or version numbers.\n\n  ```markdown\n  - Store\n    - Plugin\n      - [Color Picker](https://github.com/author/wox-plugin-color) Wox plugin to pick colors [@author](https://github.com/author)\n      - [Strava](https://github.com/author/wox-plugin-strava) A plugin to interact with Strava workouts [@author](https://github.com/author)\n    - Theme\n      - [Wox Dracula](https://github.com/author/wox-theme-dracula) Wox theme inspired by the Dracula color scheme [@author](https://github.com/author)\n  ```\n\n- Write the English file first, then produce the Chinese file as a line-for-line counterpart. Do not add or drop bullets in only one language.\n- Both files now contain the full version history. Keep new headings in both files and do not leave a new release in only one language.\n\n5. Keep README in sync only when the latest **stable** heading changes.\n\n- Update the line next to the Release badge to `Latest: vX.Y.Z · Mon YYYY`, matching that heading (for example `Latest: v2.4.3 · Sep 2026`). GitHub README is not generated.\n- Skip this when you only add bullets under an existing heading, or when the newest heading is a beta (`vX.Y.Z-beta.N`).\n- Do not hand-edit `www/docs`. Homepage version text, compare stamps, and `/changelog/*` pages are generated from `CHANGELOG.md` and `CHANGELOG.zh_CN.md` during `docs:dev` / `docs:build`.\n\n6. Validate before finishing.\n\n- Ensure no duplicate bullets.\n- Ensure every `Add`/`Improve`/`Fix` bullet maps to at least one commit in range.\n- Ensure every PR-derived item includes its PR link and verified contributor mention in both languages, including when the same feature combines direct commits and PR contributions. Check merge history or GitHub associations so `--no-merges` does not hide attribution.\n- Ensure every `Store` bullet maps to a plugin `Id` or theme `ThemeId` that is new since `last_release_tag`.\n- Ensure every release section you create or update has a biggest-highlight paragraph under the version heading in both files, written in everyday language a typical user can understand.\n- Reread new bullets as a user: drop leftover implementation terms such as schema, chrome, prefetch, incremental index, DirectWrite, overlay, conversion mode, or host restart unless they are the feature name.\n- Ensure English and Chinese newest sections have the same headings, screenshots, issue links, and bullet count.\n- If the latest stable heading is new or its date changed, ensure README contains `Latest: vX.Y.Z · Mon YYYY` matching it (`docs:build` fails if this line is missing).\n- Ensure markdown renders cleanly and section spacing matches nearby versions.\n- Avoid rewriting old release sections unless explicitly requested.\n- If a commit set only contains tiny UI-only polish, keep it out of changelog by default.\n\n## Command Reference\n\n```bash\ngit tag --sort=-creatordate | head -n 20\nsed -n '1,120p' CHANGELOG.md\nsed -n '1,120p' CHANGELOG.zh_CN.md\ngit log --oneline --no-merges <last_tag>..HEAD\ngit log --oneline --merges <last_tag>..HEAD\ngit show --stat --oneline <sha>\ngit show <last_tag>:store-plugin.json\ngit show <last_tag>:store-theme.json\ngit diff -- CHANGELOG.md CHANGELOG.zh_CN.md\n```\n\nCompare store catalogs by ID, not by file diff hunks. Example:\n\n```bash\npython -c \"\nimport json, subprocess, sys\ntag = sys.argv[1]\ndef load(rev, path):\n    return json.loads(subprocess.check_output(['git', 'show', f'{rev}:{path}']))\nold_p = {p['Id'] for p in load(tag, 'store-plugin.json')}\nnew_p = json.load(open('store-plugin.json', encoding='utf-8'))\nfor p in new_p:\n    if p['Id'] not in old_p:\n        print('plugin', p.get('Name'), p.get('Description'), p.get('Author'), p.get('Website'), p.get('I18n'))\nold_t = {t['ThemeId'] for t in load(tag, 'store-theme.json')}\nnew_t = json.load(open('store-theme.json', encoding='utf-8'))\nfor t in new_t:\n    if t['ThemeId'] not in old_t:\n        print('theme', t.get('ThemeName'), t.get('Description'), t.get('ThemeAuthor'), t.get('ThemeUrl'))\n\" <last_tag>\n```\n\n## Output Rules\n\n- Edit `CHANGELOG.md` and `CHANGELOG.zh_CN.md` together.\n- If the latest stable heading changed, also update the README `Latest: vX.Y.Z · Mon YYYY` line. Do not edit `www/docs` changelog pages or homepage copy.\n- Keep final response short: what section was updated and what categories were changed, including `Store` plugin/theme counts when present.\n- If commit intent is ambiguous, state the assumption briefly in the final response.\n",".agents/skills/wox-theme-creator/SKILL.md":"---\nname: wox-theme-creator\ndescription: Design, create, and refine Wox theme JSON files, including schema v2 base colors, optional styles, transparency, platform overrides, and local debugging. Use for authoring themes or converting an existing theme while preserving its appearance.\n---\n\n# Wox Theme Creator\n\nCreate a deliberately designed theme with a coherent palette, readable states, and a valid authored JSON document. Prefer schema v2 for new themes. Preserve the requested output location and existing theme identity when editing; generate a fresh UUID for a new theme.\n\n## Embedded theme editor\n\nWhen invoked by Wox's theme editor, work on the supplied current draft and editable property list. These are the authoritative available fields. Apply the design guidance below; return only the requested JSON patch of changed properties, preserving unrelated values and theme identity. Do not require repository access, filesystem tools, or a new theme file. The editor validates the patch and handles preview, undo, and saving. A normal AI Chat or repository authoring session continues to use the document workflow below.\n\n## Source of truth\n\nPaths below are relative to the Wox repository root. Read the current implementation before choosing fields; do not invent theme tokens or copy resolved runtime values into a new theme.\n\n- `wox.core/common/theme_schema_v2.go`: complete v2 document, accepted fields, color/geometry defaults, validation, and platform resolution.\n- `wox.core/resource/themes/`: built-in themes as working examples.\n- `wox.core/common/theme_surfaces.go` and `theme_package.go`: image surface declarations, resource validation, and package parsing.\n- `wox.core/common/theme_schema_v1.go`: legacy wire format and behavior, needed when converting an old theme.\n- `wox.core/common/theme_runtime.go` and `theme.go`: independent runtime representation, schema dispatch, and Wox version checks. These are not the authored JSON schema.\n\nEach schema owns its complete document and parser. Missing `SchemaVersion` or historical zero means v1. Loading must not rewrite old files. Changing v2 default semantics would change sparse themes; a new format belongs in a separately registered schema, not a retrofit of v1 or v2.\n\n## Image-backed themes\n\nWox 2.4.4 adds optional image surfaces to schema 2. Existing v1/v2 JSON files,\ncolor defaults, window materials, and Action Panel placement are unchanged.\nUse `MinWoxVersion: \"2.4.4\"` when publishing a theme using these fields.\n\n### Package layout\n\nA `.wox-theme` file is a ZIP archive with `theme.json` at its root, not inside\nan enclosing folder:\n\n```text\nming.wox-theme\n  theme.json\n  assets/lacquer.png\n  assets/palace-frame.png\n  assets/crest.png\n```\n\nOpen the package with Wox, or select the file and invoke Wox's selection query.\nThe installer shows its name and an Install action. Installation validates all\nentries before replacing `<theme-directory>/<ThemeId>/`; failed staging leaves\nthe previous package intact. Plain `<ThemeId>.json` themes remain supported.\nResource-backed themes are excluded from Cloud Sync.\nTheme editor color changes and Save As retain the image declarations and assets.\n\nThe package accepts PNG and JPEG images. Paths are case-sensitive, slash-separated,\nrelative to the package root. Absolute paths, traversal, symlinks, Windows device\nnames, and case-colliding archive entries are rejected. Limits are 128 archive\nentries, 32 MiB uncompressed data, and 16 megapixels across all images. Nine-slice\nsource cuts must leave a nonempty center. Assets for inactive platforms must also\nbe included. No network image URLs or executable theme code are supported.\n\n### Example theme.json\n\n```json\n{\n  \"SchemaVersion\": 2,\n  \"MinWoxVersion\": \"2.4.5\",\n  \"ThemeId\": \"6cf090bd-ef04-44e9-aa61-cbe0e1dc2275\",\n  \"ThemeName\": \"明\",\n  \"BaseBackgroundColor\": \"#721D16\",\n  \"BaseTextColor\": \"#FFF0CA\",\n  \"BaseAccentColor\": \"#F4C453\",\n  \"AppBackgroundColor\": \"transparent\",\n  \"OverlayBackgroundColor\": \"#721D16\",\n  \"OverlayFontColor\": \"#FFF0CA\",\n  \"Surfaces\": {\n    \"App\": {\n      \"ContentInsets\": {\"Top\": 110, \"Right\": 48, \"Bottom\": 32, \"Left\": 48},\n      \"Background\": {\n        \"Source\": \"assets/lacquer.png\",\n        \"Mode\": \"tile\",\n        \"Size\": {\"Width\": 128, \"Height\": 128}\n      },\n      \"Frame\": {\n        \"Source\": \"assets/palace-frame.png\",\n        \"Mode\": \"nineSlice\",\n        \"Slice\": {\"Top\": 160, \"Right\": 96, \"Bottom\": 96, \"Left\": 96},\n        \"Insets\": {\"Top\": 80, \"Right\": 48, \"Bottom\": 48, \"Left\": 48}\n      },\n      \"Decorations\": [{\n        \"Source\": \"assets/crest.png\",\n        \"Anchor\": \"topCenter\",\n        \"Offset\": {\"X\": 0, \"Y\": 0},\n        \"Size\": {\"Width\": 120, \"Height\": 110}\n      }]\n    },\n    \"ActionContainer\": {\n      \"Background\": {\"Source\": \"assets/lacquer.png\", \"Mode\": \"tile\"}\n    }\n  }\n}\n```\n\n### Surface contract\n\n`InnerShadow` optionally shades inward over child fills to make a panel appear\nrecessed into its frame. It accepts `Color`, `Width` (0..64 logical units),\n`Radius` and `Insets` (each 0..4096). Insets locate the inner panel relative to\nthe surface; match App ContentInsets and AppContentBorderRadius for an inset\nlauncher. For example: `\"InnerShadow\": {\"Color\":\"rgba(25,42,55,0.25)\",\n\"Width\":7,\"Radius\":10,\"Insets\":{\"Top\":29,\"Right\":29,\"Bottom\":29,\"Left\":29}}`.\nThe shadow fades to transparent inward, follows display density, and allocates\nno image cache. Keep its width within the content padding so text stays clear.\nIt paints after children, unlike image layers; omit it to preserve existing\nappearance. This optional schema 2 extension requires Wox 2.4.5.\n\nThe supported regions are `App`, `QueryBox`, `ResultItemActive`,\n`ActionContainer`, `Preview`, and `Toolbar`. Each accepts the same optional\n`Background`, `Frame`, and `Decorations` declarations. The generic preview shell\nis supported; embedded web/native content and specialized previews still own\ntheir inner rendering.\n\nLayers draw in this order: existing color/material, Background, Frame,\nDecorations, existing borders, interactive contents. Images do not introduce\nhit targets. Transparent image pixels reveal the underlying fill; they do not\nerase it. Author a transparent App background and custom chrome explicitly when\nneeded. AppBorder fields still disable the OS material as before. Native\narbitrary-shape input regions are not part of this extension.\n\n`Background` and `Frame` accept these modes:\n\n| Mode        | Geometry                                                                                             |\n| ----------- | ---------------------------------------------------------------------------------------------------- |\n| `stretch`   | Scale the image to the surface bounds.                                                               |\n| `tile`      | Repeat at `Size` logical units; if absent, use the image's pixel dimensions as logical units.        |\n| `nineSlice` | Cut at `Slice` source pixels, draw borders at `Insets` logical units, stretch the remaining regions. |\n\nStretch and tiled images follow the surface corner radius. Nine-slice images\nretain their authored alpha silhouette; put rounded corners in the asset.\nFour corners retain their destination size unless the surface is too small,\nin which case opposing borders shrink proportionally. A frame's center is\nalso drawn, so use a transparent center when only an outline is wanted.\nTiled backgrounds retain only their latest raster size, at the active display's\nphysical pixel density, capped by the asset's authored density. Moving between\ndisplays rebuilds this cache; `Size` remains in logical units. The limit is 16\nmegapixels per background; larger requests use the existing color fallback.\nNine-slice textures are likewise derived at display density from the shared\ndecoded source: borders and repeated tiles are downsampled to their logical\nsize times the display scale (never upsampled), while an axis that stretches\nto the surface keeps its source pixels. Only the latest display scale is\ncached per surface.\nReuse the same `Source` for shared textures: decoded pixels are shared across\nsurfaces, while each surface keeps its own size cache. PNG file size is not its\nmemory cost: decoded RGBA uses roughly width × height × 4 bytes, plus raster\nand native renderer caches. Use reasonably sized texture tiles.\n\nDecorations require `Source`, `Anchor`, and a positive logical `Size`; `Offset`\ndefaults to zero. Anchors are `topLeft`, `topCenter`, `topRight`, `centerLeft`,\n`center`, `centerRight`, `bottomLeft`, `bottomCenter`, and `bottomRight`.\nOffsets are in logical units and decorations stay clipped to their owner.\nDecorations are static and do not change control layout.\n\nOnly `App` accepts `ContentInsets`. These add to the existing uniform\n`AppContentInset`, outside the inner content panel and existing `AppPadding`.\nThey reserve space for the entire launcher body, including the Toolbar and\nAction Panel. Frame insets do not implicitly add layout padding.\n\nPlatform and variant `Surfaces` objects merge **by region**. A supplied region\nreplaces that region's whole declaration; omitted regions inherit. Set a region\nto `null` to remove it, or `Surfaces: null` to remove every inherited surface.\nExisting scalar platform override semantics are unchanged.\n\n```json\n{\n  \"windows\": {\"Surfaces\": {\"Toolbar\": null}},\n  \"linux\": {\"Surfaces\": null}\n}\n```\n\nThere is no separate package format version; the schema version belongs to\n`theme.json`.\n\nFloating overlays (text notifications, tooltips, image preview, timer, dictation,\nand permission prompts) are not the launcher window. When `Surfaces` uses an\nimage, set `OverlayBackgroundColor` and `OverlayFontColor` explicitly.\nImage-backed themes usually leave `AppBackgroundColor` transparent so the frame\nasset is the window; overlays have no frame, so that transparent color lets the\ndesktop show through and the text becomes unreadable. Use an opaque fill that\nmatches the readable content surface, and a text color that contrasts with it.\nDo not copy the transparent window color. Omitted overlay colors follow the\neffective `AppBackgroundColor` and `ActionItemFontColor`, which is correct only\nfor themes whose window fill is already a readable wash. These fields do not\nrecolor the launcher, Notes, or WebView windows. Authoring them requires Wox\n2.4.5.\n\n## Author the document\n\n### Localized name and description\n\nSchema v2 supports optional inline `I18n`, using the same locale-to-key map as\nplugin.json. Set `ThemeName` and `Description` to `i18n:` keys:\n\n```json\n{\n  \"ThemeName\": \"i18n:theme_name\",\n  \"Description\": \"i18n:theme_description\",\n  \"I18n\": {\n    \"en_US\": {\"theme_name\": \"Ming\", \"theme_description\": \"An imperial red and gold theme.\"},\n    \"zh_CN\": {\"theme_name\": \"明\", \"theme_description\": \"朱红与金黄的皇家主题。\"}\n  }\n}\n```\n\nProvide `en_US` as fallback, plus the intended languages (`zh_CN`, `ru_RU`,\n`pt_BR`, `ko_KR`, `ja_JP`). Missing translations fall back to English, then\nWox's built-in translations, then the original key. Literal text stays literal.\nTranslations are resolved for display and search; saved JSON retains the keys\nand translation map. `I18n` belongs at the root, not in platform overrides.\nThis extension uses schema 2 and requires Wox 2.4.4. Theme translations currently\nuse inline `I18n`; separate `lang/` files are not loaded.\n\nA minimal v2 document looks like this; replace the sample ID and name:\n\n```json\n{\n  \"SchemaVersion\": 2,\n  \"MinWoxVersion\": \"2.4.3\",\n  \"ThemeId\": \"66288aad-d3fa-493b-bc46-7e8e7280c40d\",\n  \"ThemeName\": \"Jade\",\n  \"BaseBackgroundColor\": \"rgba(28, 35, 37, 0.72)\",\n  \"BaseTextColor\": \"#E5ECE9\",\n  \"BaseAccentColor\": \"#70D6A6\"\n}\n```\n\nThe three base colors, ID, and name are required. Explicitly declare schema 2. Set `MinWoxVersion` to the release supporting the features used; check current built-ins rather than lowering the floor to make installation succeed. `Version` is the theme's own version, separate from schema and minimum Wox versions. Include truthful author, description, and URL metadata when available. Do not mark a custom theme as system-installed. Automatic appearance themes use `IsAutoAppearance`, `DarkThemeId`, and `LightThemeId`; their required base colors still provide a fallback.\n\nGroup overrides by surface: window, query/Glance/Attention, result container/items, Action Panel/items/query, preview/tags, toolbar/keycaps. Keep the document sparse; add overrides for intentional design differences.\n\n| Authored value                            | Meaning                                                  |\n| ----------------------------------------- | -------------------------------------------------------- |\n| Missing optional style                    | Inherit parent, or schema default at the root            |\n| `null` at the root                        | Same as omitted: schema default                          |\n| `null` on a platform or variant           | Clear the inherited value and restore the schema default |\n| Integer `0`                               | Explicit zero; never substitute a default                |\n| `transparent` or alpha zero               | Explicit transparency                                    |\n| Empty color, negative/fractional geometry | Invalid                                                  |\n\nColors accept `#RRGGBB`, `#RRGGBBAA` (alpha last), `rgb(r,g,b)`, `rgba(r,g,b,a)`, and `transparent`. RGB channels are 0–255; alpha is 0–1. Geometry uses logical units, not physical screen pixels.\n\nFont sizes are controlled by the application Interface size setting; do not add theme font-size overrides.\n\n## Default window shape and transparency\n\nUnless the user explicitly requests a custom app outline or window corners, omit `AppBorderColor`, `AppBorderWidth`, and `AppBorderRadius` at the root and all platform/variant levels. Do not infer a custom window outline or radius from a reference screenshot or a general request for a rounded visual style. Keep the system/default window shape and use a slightly translucent `AppBackgroundColor` by default (for example, alpha 0.90).\n\nIf the user explicitly requests a custom app outline or window corners, author the requested `AppBorder*` fields and default `AppBackgroundColor` to fully opaque (alpha 1). An explicit request for transparency or opacity overrides that default. QueryBox, result, preview, and Action Panel corner settings do not count as a request for custom window chrome. Toolbar and Action Panel may retain modest in-app translucency in either case.\n\nThese are theme-authoring defaults, not changes to schema parsing. Apply them when creating themes or when the user asks to restyle an existing theme; do not silently rewrite other existing themes. Keep `BaseBackgroundColor` independent when an explicit app background override is sufficient, so changing window alpha does not unintentionally change every derived surface.\n\n## Design the surfaces together\n\nStart with background, text, and accent roles. Optional colors derive independently from these roles; changing one optional token does not change another. Base alpha also affects derived colors. Consult the resolver for exact defaults instead of duplicating its entire catalog here.\n\n- For translucent themes, consider app, query, Action Panel, action query, preview, and toolbar backgrounds together. An opaque surface can hide translucency beneath it; layered alpha and native materials affect the final appearance.\n- V2 `AppContentInset` reserves a uniform logical inset around the entire launcher content, including the toolbar, previews, and floating panels. `AppContentBackgroundColor` paints the inner panel and `AppContentBorderRadius` rounds its background. Defaults are 0, transparent, and 0, preserving existing themes. These fields do not select custom window chrome: use a translucent `AppBackgroundColor` and omit `AppBorder*` to expose a native-material rim. Existing `AppPadding*` remains spacing inside the content panel. Child surfaces retain their own corner styles; the toolbar follows the panel's bottom corners.\n- Floating overlays use `OverlayBackgroundColor` and `OverlayFontColor`. Omitted values follow the effective `AppBackgroundColor` and `ActionItemFontColor`. They do not change the launcher, Notes, or WebView windows. Image-backed themes must set both explicitly; see Image-backed themes.\n- Set `ResultContainerPaddingTop` and `ResultContainerPaddingBottom` to the same value, normally 8, so the result list matches the built-in themes. The schema default is top 8 and bottom 0, so write both fields explicitly; omitting the bottom padding does not produce a matching gutter. Keep left and right at 0 unless a side inset is part of the design. Leave an existing theme's values unchanged unless that spacing is being authored.\n- V2 uses `ResultItemActiveIndicatorColor`, `ResultItemActiveIndicatorWidth`, `ResultItemActiveIndicatorInsetLeft`, `ResultItemActiveIndicatorInsetTop`, `ResultItemActiveIndicatorInsetBottom`, and `ResultItemActiveIndicatorBorderRadius` for the selected-result marker. Width defaults to 0, color to the base accent, and insets/radius to 0. Zero insets/radius reproduce the edge strip; use positive insets and radius for a short rounded marker. Reserve icon space with result-item padding; marker geometry does not shift content. The unreleased v2 `ResultItemActiveBorderLeftWidth/Color` fields were removed; v1 keeps its original fields. Check normal, selected, and hovered rows separately; `ResultItemHoverBackgroundColor` controls hover.\n- `QuerySeparatorColor`, `QuerySeparatorThickness`, `QuerySeparatorPaddingLeft`, and `QuerySeparatorPaddingRight` draw the line under the query. Thickness is the stroke size in logical pixels; omitted thickness draws nothing. Left and right padding inset the line from the window edges, and omitted padding runs it across the window. The line does not follow the query box corner radius.\n- Action Panel border fields are `ActionContainerBorderColor`, `ActionContainerBorderWidth`, and `ActionContainerBorderRadius`. `ActionContainerDividerColor` controls internal separators independently of `PreviewSplitLineColor`.\n- Toolbar primary actions (default/bare Enter) support `ToolbarPrimaryFontColor` and `ToolbarPrimaryHotkey{Font,Background,Border}Color`. Omitted values inherit the corresponding effective toolbar colors; explicit transparency is preserved. Configure emphasis here rather than relying on automatic dimming of other actions.\n- Keycaps have three independent v2 groups: `ToolbarHotkey{Font,Background,Border}Color`, `ActionItemHotkey{Font,Background,Border}Color`, and `ActionItemActiveHotkey{Font,Background,Border}Color`. All accept explicit transparency. Omitted values derive from base colors, not another surface's overrides: normal text uses secondary text and border uses divider; active text/border use base text; backgrounds default transparent. Set active colors explicitly for contrasting selection backgrounds (for example, white keycaps on blue). The unreleased shared `Hotkey*` fields were removed. Keep keycaps readable without competing with labels.\n- `PreviewBorderRadius` and `PreviewTagBorderRadius` control generic preview and metadata-tag corners in logical units. Omitted values retain 8; zero is square.\n- Preview has `PreviewBackgroundColor`, `PreviewBorderColor`, existing text/property/selection colors, and `PreviewTagFontColor`, `PreviewTagBackgroundColor`, `PreviewTagBorderColor`. Generic preview tokens do not necessarily control specialized chat, terminal, media, or native/web surfaces.\n- Glance has `GlanceFontColor`, `GlanceIconColor`, `GlanceBackgroundColor`, and `GlanceHoverBackgroundColor`. Raster images retain their own colors.\n- Attention has `AttentionFontColor`, `AttentionIconColor`, `AttentionBackgroundColor`, `AttentionBorderColor`, `AttentionHoverBackgroundColor`, and `AttentionHoverBorderColor`. Omitted values match Glance: transparent idle fill/border and a query-text hover wash. Raster images retain their own colors.\n- Shared scrollbars expose `ScrollbarThumbColor`, `ScrollbarThumbHoverColor`, `ScrollbarThumbActiveColor`, `ScrollbarWidth`, `ScrollbarHoverWidth`, and `ScrollbarBorderRadius`. Widths default to 3/7 logical units; omitted radius follows half the animated thickness. Zero width/radius and transparent colors are explicit. Horizontal bars use width as thickness. Native/web-owned scrollbars remain outside this contract.\n- Filters use `RefinementButton{Font,Icon,Background,Border,HoverBackground}Color` and their `RefinementButtonActive...Color` counterparts. Active means expanded or a non-default filter is applied. The expanded strip uses `Refinement{Background,Border,Title,Divider,Hotkey}Color`; options use `RefinementItem{Font,Background,HoverBackground}Color` and `RefinementItemActive...Color`. These are JSON overrides; preserve explicit alpha for every state, including selected-hovered options. Control dimensions remain launcher-density geometry.\n- `AppBorderColor`, `AppBorderWidth`, and `AppBorderRadius` control launcher outer chrome. Width and radius use logical units. Zero width disables the outline. Zero radius is an explicit square corner for the painted outline. Omitted fields keep the previous platform behavior. Set width explicitly when designing an outline. If any one of these three fields is authored, every platform disables system window material (Windows Acrylic, macOS Liquid Glass/vibrancy, Linux compositor blur) so Go UI can paint the outline. Windows applies a DPI-scaled region plus DirectComposition clip only when a radius is authored, including 0; color or width alone leaves DWM's default corners. macOS detaches the glass/vibrancy wrapper and clips the renderer layer to the authored radius, but the launcher stays a titled window, so AppKit still masks the window and its shadow to the system corner radius. `AppBorderRadius: 0` therefore cannot produce fully square corners on macOS. Linux turns compositor blur off and paints the authored radius, including 0. Result, query, preview, and Action Panel radii are in-app geometry and can be square. Theme-color alpha still controls ordinary window transparency. Verify shadow and transparency on each target OS before promising identical results.\n\n## Explain the custom-chrome tradeoff\n\nWhen creating, editing, or recommending a theme that authors any of `AppBorderColor`, `AppBorderWidth`, or `AppBorderRadius`, explicitly tell the user that this disables system window material on every platform (Acrylic, Liquid Glass, Linux compositor blur). The native window switches to transparent composition; theme-color alpha controls ordinary window transparency. This does not disable Wox's own in-app frosted-glass surfaces. Include this limitation in the delivery message, not only in JSON or internal notes.\n\nToolbar and Action Panel retain their application-rendered frosted-glass transparency independently of the native window material. When designing custom-chrome themes, consider modest transparency in `ToolbarBackgroundColor` and `ActionContainerBackgroundColor` (for example, alpha around 0.88–0.90), while keeping text readable. Do not make these surfaces opaque merely because custom window chrome is enabled. An opaque `AppBackgroundColor` can remain intentional: these panels reveal or blur underlying app content, not the desktop through that opaque background.\n\nAn explicit zero (`AppBorderWidth: 0` or `AppBorderRadius: 0`) also selects this path. To restore system material, omit all three fields. A child platform or variant can restore material after a parent outline by setting those fields to `null`; that clears the inherited chrome instead of painting a square window. Assigning a default-looking number does not restore the material. Background colors still need alpha below 1 to reveal anything underneath.\n\nSuggested user-facing wording: “主题只要设置了 AppBorderColor、AppBorderWidth 或 AppBorderRadius 中的任意一项，所有平台都不会再使用系统窗口材质（Windows Acrylic、macOS Liquid Glass、Linux 合成器模糊）。窗口改用普通透明合成，透明程度由主题颜色的 Alpha 决定。Toolbar 和 Action Panel 的应用内磨玻璃效果仍保留，可以适度保留透明度。若要恢复系统材质，需要移除这三项配置。子级平台或变体可以把这三项设为 null，用来取消父级圆角/描边并重新打开系统材质。”\n\nWhen `AppBorderRadius` is 0 at the root or on `macos`, including an explicit request for square window corners, also tell the user about the macOS window-shape limit in that same delivery message. Do not attach this warning to a positive radius, or to square result, query, preview, or Action Panel corners.\n\nSuggested user-facing wording: “在 macOS 上，启动器窗口外形和阴影仍由系统标题栏窗口决定。AppBorderRadius 设为 0 只会让 Wox 按直角绘制内容，系统仍会把窗口裁成圆角，无法得到完全直角。”\n\n## Platform overrides and compatibility\n\nResolution order is root authored values, then `windows`/`macos`/`linux`, then that platform's matching `variants` entry, then defaults. Read `theme_platform.go` for supported variant names. Omitted platform fields inherit the parent. JSON `null` on a platform or variant clears the inherited value so the schema default applies; this is how Hyprland can keep compositor blur after a shared Linux `AppBorderRadius`. Base colors may be overridden so dependent defaults derive from the effective palette. All platform variants are validated, including inactive ones.\n\nPreserve authored values and platform nodes when editing or saving. Never flatten a resolved platform theme into the source document. When explicitly converting v1, retain its effective appearance with explicit v2 overrides where defaults differ; verify zero values, aliases, and legacy contextual color behavior rather than only changing `SchemaVersion`.\n\n## Deliver and check\n\nFor local debugging, use the user's requested path; the normal user theme directory is `~/.wox/wox-user/themes/`. Use `<ThemeId>.json` for a plain color theme. For image-backed themes, deliver a `.wox-theme` package containing root `theme.json` and its assets; installed packages live under `<ThemeId>/`. Do not overwrite an unrelated theme or publish to the store as part of local authoring.\n\nValidate JSON and use Wox's actual parser/resolver to check fields, colors, platform nodes, and version compatibility. Existing checks live in `wox.core/common/theme_v2_test.go` and `theme_document_test.go`; for changes to parsing run `go test -tags 'sqlite_fts5,wox_automation' ./common` from `wox.core`. That suite validates the implementation, not an arbitrary new file: load the authored file through Wox or a focused parser check as well.\n\nWhen a running preview is available, inspect selected/hovered results, the Action Panel, keycaps, toolbar, preview/tags, and Glance. For transparency, compare against light and dark desktop content. Report which platforms were actually observed; do not claim native material behavior from a static JSON check.\n\nResource-backed themes are local-only for now: Cloud Sync skips their install, update, deletion, and snapshot payloads. Ordinary JSON themes continue to sync. Share image themes using the `.wox-theme` file.\n\n## Resizable frames: stretch versus repeat\n\nSchema v2 nine-slice images accept optional `\"Repeat\": {\"X\": \"tile\", \"Y\": \"stretch\"}`.\nEach omitted axis defaults to `stretch`; accepted values are `stretch` and `tile`.\n`Repeat` is invalid on whole-image `stretch` or `tile` modes. Existing declarations are unchanged.\n\nCorners retain their authored logical Insets. X controls the top/bottom middle strips;\nY controls the left/right middle strips. The center follows both axes. Tiling starts\nat the left/top of each slice; the final partial tile is clipped, never squeezed.\nTop/bottom tile width equals source strip width multiplied by actual logical strip\nheight divided by source strip height. Left/right tile height uses the corresponding\nwidth ratio. The center uses the first positive Insets/Slice ratio in Top, Bottom,\nLeft, Right order (or 1 if all are zero). Keep these ratios consistent for a uniform\nmaterial density. DPI is applied by the renderer; do not multiply Insets by display scale.\nVery small windows shrink opposing borders proportionally. A pathological slice that\nwould require more than 4096 tile draws falls back to stretching that slice; avoid tiny\nrepeat units and verify the maximum supported window size.\n\nUse stretching for flat fills and simple straight rules, tiling for roof tiles, woven\npatterns, rivets or bamboo, and fixed-size Decorations for crests, lettering and figures.\nNine-slice does not turn an arbitrary illustration into a seamless material. The full\nmiddle strip is the repeat unit: its two ends must match in height, color, lighting,\nalpha and motif phase. Do not include isolated statues in it. Keep curved-to-straight\ntransitions entirely within fixed corner slices; put cut lines only in straight,\nregular sections and preserve tangent continuity. Corners and adjacent strips need\nmatching scale as well as matching pixels. Inspect the join at both ends, not only\nrepeat-to-repeat seams. A clipped final motif can meet the far corner at a different\nphase; prefer a neutral join or a fixed decorative cap where this would be visible.\n\nFor an irregular Action/About panel, set ActionContainerBackgroundColor and its border\ncolor to transparent, remove the separate rectangular Background image, and provide\nan opaque interior inside a transparent-exterior Frame. This also skips the rectangular\nfloating material. Leave padding for the ornaments. App ContentInsets reserve draggable\nouter chrome; controls remain inside the reserved content bounds.\n\nVerify minimum, default and wide launcher widths, short and tall result lists, fractional\nDPI (125%, 150%), fixed crest proportions, partial tiles, alpha silhouette, and Action/\nAbout content clearance. Check the actual rendered UI before claiming seamless joins;\nimage generation and parser validation alone cannot establish that.\n",".agents/skills/wox-test-ensurance/SKILL.md":"---\nname: wox-test-ensurance\ndescription: Use when the user invokes Wox test assurance or asks to run Wox tests; direct invocation is explicit permission to execute the current core, Go UI unit, and native smoke suites and fix failures until they pass.\n---\n\n# Wox Test Ensurance\n\n## Overview\n\nDrive Wox test assurance from the repository root until the core tests, headless Go UI tests, and native Go UI smoke tests 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.\n\n## Invocation Contract\n\nIf this skill is explicitly invoked, the user has already authorized the complete Wox test assurance workflow: `make test`, `make test-go-ui-unit`, and `make smoke`. Do not stop after summarizing a plan or ask for extra confirmation.\n\nIf the user asks for one exact command, such as `make test`, run only that requested command and fix its failures. Do not silently expand an exact command request into native UI smoke testing.\n\nUse the active Wox checkout containing the root `Makefile` and `wox.core` directory. Do not assume a fixed drive or checkout path.\n\n## Preflight\n\nBefore running the suite, ensure no local Wox instance or VS Code-launched Wox debug process from the active checkout is still running. Force-stop matching processes; stale processes can hold ports or keep old state alive, and native smoke tests must own the Wox process they exercise.\n\nUse a Windows PowerShell check like this from the repository root:\n\n```powershell\n$repo = (Resolve-Path \".\").Path\n$woxProcesses = Get-CimInstance Win32_Process | Where-Object {\n    $name = $_.Name\n    $cmd = $_.CommandLine\n    $exe = $_.ExecutablePath\n    $isWoxBinary = $name -in @(\"Wox.exe\", \"wox.exe\", \"wox.core.exe\", \"__debug_bin.exe\")\n    $isWoxDebug = $name -in @(\"dlv.exe\", \"__debug_bin.exe\") -and $cmd -like \"*$repo*\"\n    $isRepoRuntime = ($exe -like \"$repo*\") -and ($name -like \"*wox*\")\n    $isWoxBinary -or $isWoxDebug -or $isRepoRuntime\n}\n$woxProcesses | ForEach-Object { Stop-Process -Id $_.ProcessId -Force }\n```\n\nIf stopped processes are found, mention them briefly in the working update or final summary.\n\n## Workflow\n\n1. Confirm the current directory is the Wox repository root, then begin without asking whether to run tests.\n2. Run the preflight process cleanup and force-stop any matching Wox/runtime debug process.\n3. Run `make test` for the core integration suite.\n4. Run `make test-go-ui-unit` for retained-widget, automation-contract, launcher, and driver tests. This suite does not open a native window.\n5. Run `make smoke` for the real single-process Go UI. On headless Linux, set `GO_UI_SMOKE_RUNNER=\"xvfb-run -a\"`.\n6. For each failure, capture the package or smoke case, test name, command output, and relevant logs, then investigate and fix the root cause.\n7. After any fix, format only the files touched according to Wox project style, then rerun the affected command.\n8. Before claiming completion, rerun every command required by the invocation contract from the repository root. Smoke cases may be targeted while diagnosing, but explicit test assurance ends with the complete `make smoke` suite.\n\n## Failure Triage\n\nPrefer this order:\n\n1. Check whether recent implementation changes broke product behavior, API contracts, async ordering, platform handling, or persisted state.\n2. Inspect the failing test's intended behavior and compare it with the current product contract.\n3. Fix production code when the test exposes a real regression.\n4. Change an existing test only when evidence shows the product behavior is correct and the assertion/setup is outdated, flaky, or testing the wrong layer.\n5. Do not add new tests unless the user explicitly asks for new test coverage.\n\nUse targeted reruns only while narrowing a failure. They are not final proof. The final proof is every suite required by the invocation contract passing.\n\n## Wox-Specific Notes\n\n- Wox runs in mixed Windows and WSL environments. Verify the shell, path, and repo root before treating a runner failure as a code failure.\n- If a shell shim or external tool prevents the real command from starting, isolate the environment problem, use the closest repo runner only for diagnosis, and do not report success until the requested `make` command passes.\n\n## Completion Checklist\n\n- Every command required by the invocation contract passed from the Wox repository root.\n- Explicit test assurance includes successful `make test`, `make test-go-ui-unit`, and `make smoke` runs.\n- Any code or test edits are locally formatted with the relevant project formatter.\n- The final response includes the exact commands run and whether they passed.\n",".agents/skills/wox-visual-style/SKILL.md":"---\nname: wox-visual-style\ndescription: Design, implement, refactor, or review the visual style of Wox's portable Go UI under wox.core/ui. Use for Settings, dialogs, forms, tables, catalogs, management pages, shared Wox controls, typography, semantic colors, spacing, alignment, icons, control sizing, and default, hover, pressed, selected, focused, disabled, loading, empty, and error states. Also use to audit visual consistency or decide whether appearance belongs in launcher/component or launcher/view. Treat the Launcher query surface and Action Panel as explicit special contracts instead of forcing the ordinary Settings control-size system onto them.\n---\n\n# Wox Visual Style\n\nApply one coherent visual language to Wox Go UI without changing business behavior accidentally.\n\n## Load the visual contract\n\nRead [references/visual-style-guide.md](references/visual-style-guide.md) completely before designing, reviewing, or editing UI. Treat it as the sole visual policy for Wox Go UI. Treat production components and tests as implementation evidence; when they disagree with the guide, report or fix the implementation drift instead of silently redefining the guide from current code.\n\nKeep the guide at the level of cross-feature design principles and shared control conventions. Record feature-specific colors, dimensions, theme-field behavior, and bug-fix rationale in the owning code, tests, or domain documentation instead of appending them to the guide.\n\nAlso read the repository `AGENTS.md`, `README.md`, `Wox.code-workspace`, and `wox.core/ui/README.md` before refactors.\n\n## Classify the surface\n\nClassify the requested surface before applying size rules:\n\n- Apply the ordinary control system to Settings, dialogs, forms, tables, catalogs, onboarding management controls, and other application-management pages.\n- Keep the Launcher query, its accessories, results, toolbar, refinements, Glance, and Attention under launcher density and theme geometry.\n- Keep the complete Action Panel, including its filter and rows, under its own geometry contract.\n- Scale every interface element's text, line box, and the control that holds that text with `UiDensity`. Keep normal-density bases in `typography.go` and multiply them at draw time with `ControlTheme.Scaled` or the launcher density scale. Do not bake the current density into those bases, and do not multiply a size that was already scaled.\n- Keep native window controls and platform-owned dialogs under the platform contract.\n\nDo not use a special-surface exception to justify page-local styling elsewhere.\n\n## Inspect the current contract\n\n1. Inspect the nearest shared `Wox*` component and its focused tests.\n2. Inspect `launcher/component/wox_theme.go`, `launcher/component/typography.go`, and `launcher/theme.go` when colors or type are involved.\n3. Inspect relevant views for repeated literals, primitive interactive controls, and inconsistent state handling.\n4. Check whether the same semantic control exists on other production pages.\n5. Record current values separately from target values when auditing known drift.\n\nUseful focused searches include:\n\n```bash\nrg -n 'Wox(Button|TextField|Dropdown|Checkbox|Switch|IconButton)' wox.core/ui/launcher\nrg -n 'woxwidget\\.Gesture\\{' wox.core/ui/launcher/view\nrg -n 'TextStyle\\{Size:|Height:|Radius:|Color: woxui\\.Color' wox.core/ui/launcher/view\nrg -n 'BorderWidth: [0-9]+\\.|Radius: [0-9]+\\.|LineHeight: [0-9]+\\.|TextStyle\\{Size: [0-9]+\\.[0-9]' wox.core/ui/launcher\n```\n\nInterpret results in context. Primitive gestures are valid for page-specific pointer regions and tooltips; they are a defect when they recreate a reusable control contract.\n\n## Design or review the change\n\n1. Identify each element's semantic role, size tier, visual state, and alignment group.\n2. Use semantic theme roles and shared typography instead of raw colors or page-local type scales.\n3. Use the ordinary 32-unit control height only inside its defined scope. Preserve special Launcher and Action Panel geometry. Author only whole logical units for size, padding, gap, radius, border, font size, and line height.\n4. Align controls by interaction frame and centerline. Preserve the internal geometry of checkboxes and switches.\n5. Cover every applicable state from the state matrix, including non-color cues and accessibility semantics.\n6. Prefer an existing catalog name from `wox/common/icons` via `icons.Get`; add a new semantic name there before introducing a local asset. For theme-adaptive SVG paints, use `var(--wox-theme-icon-color)` explicitly; follow the SVG theme-color contract in [Components, icons, and content](references/visual-style-guide.md#components-icons-and-content).\n7. Check light and dark themes, long or translated text, narrow widths, scrolling, logical units, DPI boundaries, and disabled/error content.\n\nExpress alignment through layout primitives first: use `Align`, Flex main/cross-axis alignment, `Expanded`, or `Constrained` to center and place controls. Do not hand-calculate offsets such as `(rowHeight-controlHeight)/2`, or use padding as a substitute for alignment; improve the owning layout/component boundary when the existing primitives cannot express the relationship.\n\nWhen reviewing only, report concrete violations with the owning layer and recommended shared fix. Do not mutate files unless the user requested implementation.\n\n## Implement at the correct layer\n\n- Put reusable geometry, appearance, pointer states, focus treatment, and accessibility in `launcher/component`.\n- Keep page hierarchy, responsive composition, and genuinely page-specific spacing in `launcher/view`.\n- Keep mutable interaction state below `launcher.App` and preserve `widget.Boundary.Build` purity.\n- Centralize stable metrics used by multiple production surfaces. Do not add a token for a single local constraint.\n- Keep ordinary control size explicit through shared defaults or a semantic size API; do not copy the same height into call sites.\n- Keep Launcher and Action Panel metrics independent so ordinary component changes cannot alter their geometry accidentally.\n- Prefer layout components over manual alignment math. Center controls with `Align` or Flex alignment and reserve padding for actual content insets, not positional compensation.\n- Add English intent comments only for non-obvious visual constraints or exceptions.\n\nPreserve existing behavior unless the request includes interaction changes. A visual refactor must not alter values, callbacks, focus order, IME ownership, keyboard activation, scrolling, or window lifecycle.\n\n## Validate proportionally\n\n1. Format changed Go files with `gofmt`.\n2. Run the narrowest affected component and view tests from `wox.core`.\n3. Run `GOCACHE=/tmp/wox-go-cache make test-go-ui-unit` from the repository root when shared components, widget behavior, or broad launcher UI changed.\n4. Add focused source tests for size tiers, alignment, states, semantics, and special-surface isolation.\n5. Review the diff for duplicated literals and accidental Launcher or Action Panel changes.\n\nSource inspection is the default. Request permission before launching Wox for runtime comparison unless the user already requested it. Escalate to serial screenshots when font measurement, DPI, animation, clipping, compositing, native focus, or platform rendering leaves a meaningful visual ambiguity.\n\n## Report completion\n\nReport:\n\n- surface classification and size tier;\n- shared component or view ownership;\n- visual states covered;\n- known implementation drift found or fixed;\n- formatting and tests actually run;\n- whether validation was source-only or included an approved runtime comparison.\n","AGENTS.md":"# AI Agent Protocol & Instructions\n\nPath: `AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/AGENTS.md)","store-plugin.json":"# Plugin Plugin Manifest\n\nPath: `store-plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/store-plugin.json)",".agents/skills/wox-blog/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-blog/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/agents/openai.yaml)",".agents/skills/wox-blog/assets/article-template.md":"# Assets Skill\n\nPath: `.agents/skills/wox-blog/assets/article-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/assets/article-template.md)",".agents/skills/wox-blog/references/cover-style.md":"# References Skill\n\nPath: `.agents/skills/wox-blog/references/cover-style.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/references/cover-style.md)",".agents/skills/wox-blog/references/writing-style.md":"# References Skill\n\nPath: `.agents/skills/wox-blog/references/writing-style.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/references/writing-style.md)",".agents/skills/wox-changelog-update/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-changelog-update/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-changelog-update/agents/openai.yaml)",".agents/skills/wox-commit/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-commit/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-commit/agents/openai.yaml)",".agents/skills/wox-cpu-debug/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-cpu-debug/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-cpu-debug/agents/openai.yaml)",".agents/skills/wox-generate-smoke-test-case/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-generate-smoke-test-case/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-generate-smoke-test-case/agents/openai.yaml)",".agents/skills/wox-i18n/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-i18n/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-i18n/agents/openai.yaml)",".agents/skills/wox-memory-debug/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-memory-debug/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-memory-debug/agents/openai.yaml)",".agents/skills/wox-plugin-creator/references/hotkeys.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/hotkeys.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/hotkeys.md)",".agents/skills/wox-plugin-creator/references/html_preview_updates.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/html_preview_updates.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/html_preview_updates.md)",".agents/skills/wox-plugin-creator/references/icons.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/icons.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/icons.md)",".agents/skills/wox-plugin-creator/references/plugin_i18n.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/plugin_i18n.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_i18n.md)",".agents/skills/wox-plugin-creator/references/plugin_json_schema.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/plugin_json_schema.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_json_schema.md)",".agents/skills/wox-plugin-creator/references/plugin_overview.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/plugin_overview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_overview.md)",".agents/skills/wox-plugin-creator/references/plugin_tools.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/plugin_tools.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_tools.md)",".agents/skills/wox-plugin-creator/references/refinements.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/refinements.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/refinements.md)",".agents/skills/wox-plugin-creator/references/scaffold_nodejs.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/scaffold_nodejs.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/scaffold_nodejs.md)",".agents/skills/wox-plugin-creator/references/scaffold_python.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/scaffold_python.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/scaffold_python.md)",".agents/skills/wox-plugin-creator/references/sdk_nodejs.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/sdk_nodejs.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/sdk_nodejs.md)",".agents/skills/wox-plugin-creator/references/sdk_python.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/sdk_python.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/sdk_python.md)",".agents/skills/wox-plugin-creator/references/settings_patterns.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/settings_patterns.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/settings_patterns.md)",".agents/skills/wox-plugin-submit2store/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-plugin-submit2store/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-submit2store/agents/openai.yaml)",".agents/skills/wox-plugin-submit2store/references/store-plugin-entry.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-submit2store/references/store-plugin-entry.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-submit2store/references/store-plugin-entry.md)",".agents/skills/wox-test-ensurance/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-test-ensurance/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-test-ensurance/agents/openai.yaml)",".agents/skills/wox-visual-style/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-visual-style/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-visual-style/agents/openai.yaml)",".agents/skills/wox-visual-style/references/visual-style-guide.md":"# References Skill\n\nPath: `.agents/skills/wox-visual-style/references/visual-style-guide.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-visual-style/references/visual-style-guide.md)","www/docs/guide/plugins/system/application.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/application.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/application.md)","www/docs/guide/plugins/system/backup.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/backup.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/backup.md)","www/docs/guide/plugins/system/browser-bookmark.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/browser-bookmark.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/browser-bookmark.md)","www/docs/guide/plugins/system/browser.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/browser.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/browser.md)","www/docs/guide/plugins/system/calculator.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/calculator.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/calculator.md)","www/docs/guide/plugins/system/chat.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/chat.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/chat.md)","www/docs/guide/plugins/system/clipboard.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/clipboard.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/clipboard.md)","www/docs/guide/plugins/system/cloudsync.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/cloudsync.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/cloudsync.md)","www/docs/guide/plugins/system/color.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/color.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/color.md)","www/docs/guide/plugins/system/converter.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/converter.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/converter.md)","www/docs/guide/plugins/system/doctor.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/doctor.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/doctor.md)","www/docs/guide/plugins/system/emoji.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/emoji.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/emoji.md)","www/docs/guide/plugins/system/explorer.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/explorer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/explorer.md)","www/docs/guide/plugins/system/feedback.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/feedback.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/feedback.md)","www/docs/guide/plugins/system/file.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/file.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/file.md)","www/docs/guide/plugins/system/folder.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/folder.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/folder.md)","www/docs/guide/plugins/system/hotkey-overview.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/hotkey-overview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/hotkey-overview.md)","www/docs/guide/plugins/system/mediaplayer.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/mediaplayer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/mediaplayer.md)","www/docs/guide/plugins/system/query-history.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/query-history.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/query-history.md)","www/docs/guide/plugins/system/shell.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/shell.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/shell.md)","www/docs/guide/plugins/system/sys.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/sys.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/sys.md)","www/docs/guide/plugins/system/theme.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/theme.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/theme.md)","www/docs/guide/plugins/system/update.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/update.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/update.md)","www/docs/guide/plugins/system/url.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/url.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/url.md)","www/docs/guide/plugins/system/websearch.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/websearch.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/websearch.md)","www/docs/guide/plugins/system/webview.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/webview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/webview.md)","www/docs/guide/plugins/system/wpm.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/wpm.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/wpm.md)","www/docs/zh/guide/plugins/system/application.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/application.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/application.md)","www/docs/zh/guide/plugins/system/backup.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/backup.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/backup.md)","www/docs/zh/guide/plugins/system/browser-bookmark.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/browser-bookmark.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/browser-bookmark.md)","www/docs/zh/guide/plugins/system/browser.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/browser.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/browser.md)","www/docs/zh/guide/plugins/system/calculator.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/calculator.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/calculator.md)","www/docs/zh/guide/plugins/system/chat.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/chat.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/chat.md)","www/docs/zh/guide/plugins/system/clipboard.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/clipboard.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/clipboard.md)","www/docs/zh/guide/plugins/system/cloudsync.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/cloudsync.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/cloudsync.md)","www/docs/zh/guide/plugins/system/color.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/color.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/color.md)","www/docs/zh/guide/plugins/system/converter.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/converter.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/converter.md)","www/docs/zh/guide/plugins/system/doctor.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/doctor.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/doctor.md)","www/docs/zh/guide/plugins/system/emoji.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/emoji.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/emoji.md)","www/docs/zh/guide/plugins/system/explorer.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/explorer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/explorer.md)","www/docs/zh/guide/plugins/system/feedback.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/feedback.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/feedback.md)","www/docs/zh/guide/plugins/system/file.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/file.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/file.md)","www/docs/zh/guide/plugins/system/folder.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/folder.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/folder.md)","www/docs/zh/guide/plugins/system/hotkey-overview.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/hotkey-overview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/hotkey-overview.md)","www/docs/zh/guide/plugins/system/mediaplayer.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/mediaplayer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/mediaplayer.md)","www/docs/zh/guide/plugins/system/query-history.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/query-history.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/query-history.md)","www/docs/zh/guide/plugins/system/shell.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/shell.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/shell.md)","www/docs/zh/guide/plugins/system/sys.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/sys.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/sys.md)","www/docs/zh/guide/plugins/system/theme.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/theme.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/theme.md)","www/docs/zh/guide/plugins/system/update.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/update.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/update.md)","www/docs/zh/guide/plugins/system/url.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/url.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/url.md)","www/docs/zh/guide/plugins/system/websearch.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/websearch.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/websearch.md)","www/docs/zh/guide/plugins/system/webview.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/webview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/webview.md)","www/docs/zh/guide/plugins/system/wpm.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/wpm.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/wpm.md)"},"files":{".agents/skills/wox-blog/SKILL.md":"---\nname: wox-blog\ndescription: Create or revise Wox blog articles with practical workflows, paired English and Chinese Markdown, and consistent illustrated covers. Use for Wox blog writing and editorial standards, not release changelogs or general documentation.\n---\n\n# Wox Blog\n\nWrite for people using Wox: one concrete task, its useful outcome, and enough detail to reproduce it. Support product stories and engineering articles when requested; practical tips and workflows are the default.\n\n## Establish the facts\n\n- Read relevant feature documentation and implementation before describing commands, setting labels, defaults, or platform support. Distinguish released behavior from development-only changes; do not imply unreleased features are available in the current release.\n- Inspect nearby articles and `www/docs/.vitepress/theme/components/blog.data.mts` for the metadata contract. Do not turn a blog request into an app feature change.\n- For existing articles, preserve the slug, publication date, and useful media unless the request explicitly changes them.\n\n## Write the article pair\n\n- Read [the writing style guide](references/writing-style.md) before drafting or substantially rewriting. It contains the Mole sample analysis, Wox-specific examples, and an editorial review. Borrow explanatory techniques rather than copying an author's voice.\n- Default to English in `www/docs/blog/<slug>.md` and Simplified Chinese in `www/docs/zh/blog/<slug>.md`, using the same slug, date, category, and cover. Honor explicit single-language requests.\n- Use [the article template](assets/article-template.md) for frontmatter and a starting point, replacing every template token. It is not a mandatory outline.\n- Choose a specific title about a task or benefit. Avoid a repeated “Did You Know” / “你知道吗” prefix, exaggerated claims, and generic introductions. The description should add useful context rather than repeat the title.\n- Develop the situation, a concrete example, the reason for consequential settings, and the observable result as needed. Use connected prose for the explanation and steps for actions. Add useful context where an article feels thin; do not pad it with adjectives, repeated benefits, or a mandatory FAQ/conclusion. Keep length and structure proportional to the task.\n- Use a calm, conversational voice with specific nouns and verbs. Do not fabricate personal experience, measured improvements, user quotations, or test results to make the writing lively. Keep card descriptions compact; put the fuller explanation in the body.\n- Translate naturally. Keep commands, setting semantics, platform constraints, and outcomes equivalent across languages. Make frontmatter `title` match the article H1.\n- New articles use the actual publication date in `YYYY-MM-DD`. Use a stable descriptive kebab-case slug; omit the legacy `did-you-know-` prefix for new articles.\n\n## Supply card metadata and a cover\n\nRequired frontmatter: `title`, `description`, `date`, `category`, `cover`, and `coverAlt`.\n\n| Category ID | English label | Chinese label |\n| --- | --- | --- |\n| `workspace` | Windows & apps | 窗口与应用 |\n| `preview` | Files & previews | 文件与预览 |\n| `automation` | Shortcuts & automation | 快捷键与自动化 |\n| `product` | Inside Wox | Wox 动态 |\n\nChoose the closest category. Add a category only when the article genuinely falls outside these themes, updating loader validation and both localized labels in `BlogIndex.vue` together.\n\n- The default cover style is the approved flat illustration family: front-facing 2D shapes, thin charcoal-blue outlines, pale gray backgrounds, muted blue/sage/peach accents, and generous whitespace. Avoid clay-like 3D materials, bevels, thick keys, perspective, and heavy shadows. Use no text or logos in covers.\n- Read [the cover style reference](references/cover-style.md) when creating or replacing a cover. Use the built-in image generation tool for original illustrations; inspect an existing cover as a style reference when useful.\n- Save selected images under `www/docs/public/images/blog/` and reference `/images/blog/<name>.webp` (or the actual image extension). Localize `coverAlt` concisely.\n- Covers express the topic, not evidence of product behavior. Preserve real screenshots and videos in the body. Never substitute generated mock UI for factual screenshots.\n- When a real Wox product screenshot is needed but unavailable, continue drafting with a descriptive text placeholder at the intended position, such as `> Screenshot needed: Wox workspace settings showing the saved window layout on Windows.` Specify the screen, relevant state or action, and what the image should demonstrate; use the article language. Do not create an image link to a nonexistent file. At delivery, notify the user and list the article locations and screenshots they need to supply. These intentional screenshot placeholders may remain in the draft; they do not block completing the text and local validation.\n- If image generation is unavailable, finish text preparation and report the missing cover. Do not leave broken references or silently switch to a different medium.\n- The homepage discovers Markdown automatically and sorts by date, then URL. Do not manually add links to the blog indexes or hard-code cards.\n\n## Verify and deliver\n\n- Run the editorial pass in the writing guide: check that the reader can recognize the situation, follow the example, and tell what success looks like; remove unsupported claims and repeated filler.\n- Check both languages, links, actual asset paths, metadata, and claims against the source feature. Preserve existing URLs when revising.\n- From `www`, run `pnpm docs:build`; run `git diff --check` from the repository root.\n- Verify the article appears on its language homepage with its cover, complete title, and correct date. Inspect article media and the card at desktop and mobile widths.\n- Report article paths and verification limits. Default to local files and local verification; do not commit, push, or deploy unless requested.\n",".agents/skills/wox-cpu-debug/SKILL.md":"---\nname: wox-cpu-debug\ndescription: Measure CPU usage, attribute CPU hotspots, and optimize them without materially increasing Go or native memory in the real single-process Wox Go UI. Use for continuous-query CPU regressions, high idle or hidden CPU, plugin/query hot paths, renderer or native platform activity, background work that continues after hide, and comparisons of Go pprof data with macOS or Windows process samples.\n---\n\n# Wox CPU Debug\n\n## Goal\n\nRun the real Wox debug build with `wox_automation`, warm the same process, replay deterministic queries, and measure query-active and hidden CPU independently. Use Go CPU profiles for Go ownership and OS process/native samples for whole-process behavior. Keep profilers in separate identical runs so one profiler does not distort another.\n\n## Run the Debug Build\n\n### macOS\n\n1. Stop every other Wox instance.\n2. Start the real debug build under Delve:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\nWOX_AUTOMATION_INFO_FILE=/tmp/wox-cpu-automation.json /Users/qianlifeng/go/bin/dlv debug . --build-flags=-tags=sqlite_fts5,wox_automation\n```\n\n3. Run `continue`, wait for startup and plugin initialization, and record the debuggee PID.\n4. Keep this PID alive and running normally for the complete comparison. Never sample Delve or `debugserver` instead of the debuggee.\n\nBuild the automation workload once before measuring so Go compilation is outside every CPU window:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\ngo build -o /tmp/wox-cpu-workload ../.agents/skills/wox-cpu-debug/scripts/run-cpu-workload.go\n```\n\n### Windows\n\nStart Delve headlessly so the real debuggee can run normally while measurements execute from another PowerShell process:\n\n```powershell\ncd D:\\dev\\Wox\\wox.core\nNew-Item -ItemType Directory -Force .tmp\\cpu-debug | Out-Null\n$env:WOX_AUTOMATION_INFO_FILE = \"D:\\dev\\Wox\\wox.core\\.tmp\\cpu-debug\\automation.json\"\n$env:CGO_ENABLED = \"1\"\n$delve = Start-Process -FilePath (Get-Command dlv).Source `\n  -ArgumentList @(\"debug\", \".\", \"--headless\", \"--listen=127.0.0.1:43001\", \"--api-version=2\", \"--accept-multiclient\", \"--continue\", \"--build-flags=-tags=sqlite_fts5,wox_automation\", \"--output=D:\\dev\\Wox\\wox.core\\.tmp\\cpu-debug\\__debug_bin_wox.exe\") `\n  -WorkingDirectory (Get-Location).Path -WindowStyle Hidden -PassThru\n```\n\nWait for `automation.json`, then identify the `__debug_bin_wox.exe` child PID. Never sample either Delve process:\n\n```powershell\nwhile (-not (Test-Path $env:WOX_AUTOMATION_INFO_FILE)) { Start-Sleep -Milliseconds 100 }\nGet-CimInstance Win32_Process |\n  Where-Object { $_.ParentProcessId -eq $delve.Id -and $_.Name -eq \"__debug_bin_wox.exe\" } |\n  Select-Object ProcessId, ParentProcessId, Name, CommandLine\n```\n\nBuild the workload once before warm-up:\n\n```powershell\ngo build -o .tmp\\cpu-debug\\wox-cpu-workload.exe ..\\.agents\\skills\\wox-cpu-debug\\scripts\\run-cpu-workload.go\n```\n\nKeep the same debuggee PID alive through warm-up and every before/after comparison. When finished, stop only the exact debuggee and Delve PIDs created by this run.\n\n## Warm the Process\n\nRun a 15-second mixed-query block, hide the launcher, and wait 10 seconds:\n\n```bash\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode queries -duration 15s -seed 1\nsleep 10\n```\n\nWarm-up absorbs startup, application indexing, font loading, icon decoding, and lazy caches. Restarting Wox after warm-up invalidates the comparison.\n\nOn Windows, use the corresponding `.exe` and PowerShell sleep command:\n\n```powershell\n& .tmp\\cpu-debug\\wox-cpu-workload.exe -info .tmp\\cpu-debug\\automation.json -mode queries -duration 15s -seed 1\nStart-Sleep -Seconds 10\n```\n\n## Measure Query Latency\n\nUse the workload's `latency` mode for query responsiveness. The `queries` mode only\nchecks input updates and drives CPU activity; its fixed waits are not latency samples.\nBuild the workload before measuring, then warm the same process with 40 completed\nqueries and measure a deterministic sequence:\n\n```powershell\n& .tmp\\cpu-debug\\wox-cpu-workload.exe -info .tmp\\cpu-debug\\automation.json -mode latency -query-count 40 -seed 1 -output .tmp\\cpu-debug\\warmup.json\n& .tmp\\cpu-debug\\wox-cpu-workload.exe -info .tmp\\cpu-debug\\automation.json -mode latency -query-count 160 -seed 11 -output .tmp\\cpu-debug\\latency.json\n```\n\nThe report contains raw per-query samples and nearest-rank p50/p95 for input\ndispatch to the first current result in the retained semantics frame, and to the\ncompleted result frame. Polling is every 5 ms plus RPC/scheduling overhead; these\nare client-observed UI-frame timings, not native presentation or icon-decode\ncompletion timings. Queries with no results contribute only to completion latency.\nEach query has a 10-second timeout; a failed run is invalid and must not contribute\npartial samples to the aggregate. Compare query families as well as aggregate p95.\n\n`perf.query_state` correlates the query generation, result ownership, input value,\nand retained row IDs, so an older retained result or completion cannot satisfy the\nmeasurement. `-mode stats` reads PID, effective GOMAXPROCS, Go heap allocation,\nGo retained memory (`Sys - HeapReleased`), stack allocation, and MemProfileRate\nwithout showing Wox or forcing GC.\n\nWhen comparing startup GOMAXPROCS policies, use a fresh process for each arm,\nwith identical isolated settings, warm-up, query sequence, and GOGC. Preserve each\nPID through that run's warm-up and measurements. Alternate arm order across at\nleast three pairs. Do not compile, run tests, or run another profiler during a\nmeasurement window. Collect process CPU in separate `queries` windows, recording\ncompleted query counts, then sample memory at 45 seconds after hide so both staged\nrelease deadlines have passed. Keep private working set, total working set, private\ncommitted bytes, and Go retained memory distinct. Repeat decisive measurements in\nan optimized production-configured build, where development heap profiling is off.\n\n## Capture Continuous-Query Go CPU\n\nTrigger Wox's built-in 30-second `runtime/pprof` action and keep deterministic queries running for that complete window:\n\n```bash\n/tmp/wox-cpu-workload \\\n  -info /tmp/wox-cpu-automation.json \\\n  -mode profile-queries \\\n  -seed 11 \\\n  -output /tmp/wox-cpu-queries.prof\n```\n\nInspect both self time and cumulative ownership:\n\n```bash\ngo tool pprof -top -nodecount=30 /tmp/wox-cpu-queries.prof\ngo tool pprof -top -cum -nodecount=30 /tmp/wox-cpu-queries.prof\n```\n\nOn macOS and Linux, read the profile header's `Duration` and `Total samples` ratio as average effective core use during the 30-second window. Record the top flat and cumulative owners. Use `go tool pprof -list '<pattern>'` for source-level attribution only after a stable owner appears.\n\nOn Windows, do not trust `Total samples / Duration` until it agrees with process CPU sampling. Go profiles can charge time blocked in `runtime.cgocall`, `syscall.syscalln`, `GetMessage`, or `GetQueuedCompletionStatus` as if it were CPU. When these wait paths dominate and the profile ratio contradicts process CPU, treat the ratio and those cumulative wait owners as profiling artifacts. Use the Windows process sampler as the CPU baseline and use application-owned profile paths only as attribution candidates that require reproduction.\n\nRepeat with `-query terminal` or another fixed query when mixed queries need attribution. Compare mixed and fixed runs from the same PID; do not compare a profile captured during startup with a warmed profile.\n\nThe automation client can time out while waiting for semantics during expensive mixed queries. If that happens:\n\n- Mark the complete process window as contaminated; do not average the idle samples after the workload stalled.\n- Check whether the built-in 30-second profile still completed in `~/.wox/cpu.prof` or `%USERPROFILE%\\.wox\\cpu.prof`, but label it partial-workload evidence.\n- Repeat with a safe fixed query such as `-query terminal`. Only use a run that reports its completed query count for the clean baseline.\n- Record the query and transition (`set` or `clear`) that timed out as a separate automation/query diagnostic.\n\n## Measure macOS Query CPU\n\nUse a separate workload-only run for process CPU percentages:\n\n```bash\nready=$(mktemp /tmp/wox-cpu-query.XXXXXX)\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode queries -duration 35s -seed 11 -ready-file \"$ready\" &\nworkload_pid=$!\nwhile [[ ! -s \"$ready\" ]]; do sleep 0.1; done\n/Users/qianlifeng/Projects/Wox/.agents/skills/wox-cpu-debug/scripts/sample-wox-cpu-macos.sh --pid <PID> --samples 30 --interval 1\nwait \"$workload_pid\"\n```\n\nUse `AverageCPUPercent`, `MedianCPUPercent`, and `MaxCPUPercent`. macOS `%CPU` uses one-core units and may exceed 100 when multiple cores are active.\n\nWhen Go pprof does not explain process CPU, repeat the workload in a separate run and capture native stacks:\n\n```bash\nready=$(mktemp /tmp/wox-cpu-query-native.XXXXXX)\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode queries -duration 35s -seed 11 -ready-file \"$ready\" &\nworkload_pid=$!\nwhile [[ ! -s \"$ready\" ]]; do sleep 0.1; done\n/usr/bin/sample <PID> 30 -file /tmp/wox-cpu-queries-native.txt\nwait \"$workload_pid\"\n```\n\nDo not run `sample` and Go CPU profiling together. Attribute CoreText, CoreGraphics, AppKit, image decoding, cgo, and platform event-loop stacks from the native capture.\n\n## Measure Windows Query CPU\n\nUse a separate workload-only run. Start the workload with a unique ready file, wait for readiness, then sample the debuggee with `TotalProcessorTime` deltas:\n\n```powershell\n$ready = Join-Path $env:TEMP (\"wox-cpu-query-\" + [guid]::NewGuid().ToString(\"N\") + \".ready\")\n$workload = Start-Process -FilePath .tmp\\cpu-debug\\wox-cpu-workload.exe `\n  -ArgumentList @(\"-info\", \".tmp\\cpu-debug\\automation.json\", \"-mode\", \"queries\", \"-duration\", \"35s\", \"-seed\", \"11\", \"-query\", \"terminal\", \"-ready-file\", $ready) `\n  -WorkingDirectory (Get-Location).Path -WindowStyle Hidden -PassThru\nwhile (-not (Test-Path $ready)) { Start-Sleep -Milliseconds 100 }\n& ..\\.agents\\skills\\wox-cpu-debug\\scripts\\sample-wox-cpu-windows.ps1 `\n  -ProcessId <PID> -Samples 30 -IntervalSeconds 1 -CsvPath .tmp\\cpu-debug\\query-samples.csv\nWait-Process -Id $workload.Id\n```\n\nWindows CPU percentages also use one-core units and can exceed 100%. One-second samples can quantize around the Windows scheduler/accounting interval, so interpret the median and repeated pattern rather than a single small non-zero value.\n\nWhen Go pprof does not explain measured process CPU, capture ETW sampled CPU stacks with Windows Performance Recorder/Analyzer or another available native profiler in a separate identical run. Filter to the debuggee PID and verify symbols before attributing DirectComposition, Direct2D, DirectWrite, Win32, image decoding, or cgo work. If no native stack profiler is available, report that limitation instead of inferring a native owner from cumulative cgo time.\n\n## Measure Hidden CPU\n\nHide Wox first, signal readiness only after the hide completes, and sample the settled process:\n\n```bash\nready=$(mktemp /tmp/wox-cpu-hidden.XXXXXX)\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode hidden -duration 35s -ready-file \"$ready\" &\nworkload_pid=$!\nwhile [[ ! -s \"$ready\" ]]; do sleep 0.1; done\nsleep 2\n/Users/qianlifeng/Projects/Wox/.agents/skills/wox-cpu-debug/scripts/sample-wox-cpu-macos.sh --pid <PID> --samples 30 --interval 1\nwait \"$workload_pid\"\n```\n\nCapture hidden native stacks in another identical run when median CPU stays above sampler noise or periodic spikes recur:\n\n```bash\nready=$(mktemp /tmp/wox-cpu-hidden-native.XXXXXX)\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode hidden -duration 35s -ready-file \"$ready\" &\nworkload_pid=$!\nwhile [[ ! -s \"$ready\" ]]; do sleep 0.1; done\nsleep 2\n/usr/bin/sample <PID> 30 -file /tmp/wox-cpu-hidden-native.txt\nwait \"$workload_pid\"\n```\n\nUse `profile-hidden` only as a secondary Go-owner check:\n\n```bash\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode profile-hidden -output /tmp/wox-cpu-hidden.prof\n```\n\nThe CPU-profile action must briefly show the launcher to activate itself, so `profile-hidden` contains one-time activation and hide work at the start. Treat a function as a hidden hotspot only when it also appears in the settled OS/native run or consumes enough repeated samples to dominate that one-time transition.\n\nOn Windows, start the same `hidden` workload with a unique ready file, wait two seconds after readiness, and invoke `sample-wox-cpu-windows.ps1` for the debuggee PID. If a large spike appears while the median is near the sampling floor, capture two more settled 30-second windows. Classify it as periodic activity only if the spike or owner recurs.\n\n## Interpret Hotspots\n\nClassify query and hidden phases separately:\n\n- **Expected query work:** plugin query execution, fuzzy matching, file/application lookup, result adaptation, layout, text measurement, image decode, and rendering that stops after hide.\n- **Query hotspot candidate:** one owner repeatedly dominates flat or cumulative samples across identical profiles and scales with query frequency.\n- **No hidden CPU signal:** median settles at sampler noise, occasional spikes do not repeat, and a 30-second native sample has no recurring application stack.\n- **Possible hidden regression:** CPU remains above noise across three settled windows or recurring stacks show timers, animation/frame scheduling, renderer submission, Glance refresh, query cleanup, indexing, GC pressure, or asynchronous reloads after hide.\n- **Strong hidden regression:** the same owner persists in Go and/or native samples, reproduces after another warm run, and disappears when its feature is disabled or its lifecycle ends.\n\nIf process CPU is high but Go pprof is quiet, investigate native or cgo owners before changing Go query code. If Go pprof is high but process samples are low, verify that the profile was captured from the same PID and that activation/transition work did not dominate a mostly idle window.\n\nOn Windows, a high pprof total dominated by blocked Win32 calls is not evidence of high process CPU. Prefer the process sampler for magnitude and use the profile only to locate application work that scales across clean, identical workloads.\n\nDo not edit production code until the workload and owner reproduce. Add targeted `util.GetLogger()` diagnostics only when profiles identify a narrow lifecycle or scheduling path but cannot prove why it remains active.\n\n## Protect Memory While Optimizing CPU\n\nTreat memory as a required guardrail for every CPU optimization:\n\n- Prefer eliminating duplicate work, coalescing invalidations, stopping unnecessary scheduling, and reusing already-owned bounded resources.\n- Do not trade CPU for unbounded caches, duplicate decoded images or pixel buffers, retained render surfaces, longer-lived queues, or state that survives hide/close without a lifecycle reason.\n- Give every new cache, pool, or buffer a hard bound and an explicit release path. Clear window-scoped native resources on hide or close unless retaining them is required and measured.\n- For changes that alter caching, buffering, pooling, object lifetime, image ownership, or native resources, compare warmed before/after process physical footprint and Go retained heap under the same workload. Use `wox-memory-debug` for repeated-cycle attribution when the delta is unclear.\n- Treat a repeatable increase above 10 MiB or 5% of the warmed process footprint as material. Rework or reject the optimization unless the user explicitly accepts the tradeoff.\n\nDo not conclude that memory is unchanged from Go heap data alone. CoreGraphics, AppKit, IOSurface, decoded images, cgo allocations, and plugin hosts can increase process memory without appearing in the Go heap.\n\n## Report\n\nInclude:\n\n- OS, CPU architecture, debug tags, PID, warm-up, query pool or fixed query, and sample duration.\n- Query average/median/max process CPU and Go profile total samples versus duration.\n- Query top flat and cumulative Go owners, plus native owners when captured.\n- Hidden average/median/max process CPU and recurring Go/native stacks.\n- Before/after process footprint and Go retained-heap deltas when the optimization can affect memory ownership, including cache bounds and hide/close release behavior.\n- Whether activation, compilation, indexing, or another limitation contaminated a window.\n- On Windows, whether blocked Win32 calls contaminated pprof totals and whether native ETW stacks were available.\n- Classification for query CPU and hidden CPU, with the exact evidence supporting each.\n",".agents/skills/wox-generate-smoke-test-case/SKILL.md":"---\nname: wox-generate-smoke-test-case\ndescription: Analyze Wox feature code and plugin-exposed settings, recommend high-value native UI smoke scenarios and user flows, then generate focused Go UI smoke test cases using the automation driver and shared-process harness. Use when the user asks to identify smoke coverage for a Wox feature or plugin, or to design, add, write, or generate a smoke case under wox.core/test/smoke.\n---\n\n# Wox Generate Smoke Test Case\n\nUnderstand the feature before choosing coverage. Recommend the smallest high-value real-process smoke flow, then reuse the current smoke harness and product automation surface instead of building test-only paths.\n\n## Discover the Feature\n\n1. Read the repository `AGENTS.md` and relevant `README.md` files. Inspect `git status`, unstaged changes, staged changes, and relevant untracked files without modifying unrelated work.\n2. Locate the feature's real user entry point, then trace the code end to end: UI component, interaction handler, controller or service, persisted state or side effect, visible result, error path, and cleanup. Search every caller of the shared function before deciding where coverage belongs.\n3. Inspect the smoke infrastructure and nearest existing coverage:\n   - `wox.core/test/smoke/harness.go`\n   - `wox.core/test/automationdriver/client.go`\n   - The closest existing case under `wox.core/test/smoke/`\n   - The UI code that owns the relevant automation IDs and actions\n4. Identify the main functional points, platform branches, important state transitions, failure recovery, and existing unit or smoke coverage. Base the list on concrete code paths, not UI labels or assumptions.\n\n### Interpret Settings Semantics\n\nFor every settings smoke case, determine why the setting exists and trace the runtime path that consumes it before writing the test.\n\n1. State a **setting semantic contract** in user terms: changing the setting from a chosen value to another must alter a specific real product behavior, not merely the displayed or persisted control value.\n2. Build deterministic preconditions that make that behavior observable. Ensure the input data crosses the relevant boundary; for example, a maximum-result setting needs more available results than the tested cap.\n3. Drive the setting through its owning Settings section, then exercise the actual user flow that consumes it. Assert the live UI, runtime artifact, platform effect, or persisted product output that proves the semantic contract.\n4. Do not treat a selected value, a reopened control, or persistence alone as sufficient smoke evidence. Those checks may support the flow, but the final assertion must cover the setting's real user-visible effect.\n5. Account for implementation details that can distort naive evidence, such as virtual-list overscan, pagination, debouncing, asynchronous saves, or cached results. Measure the actual user-visible viewport or outcome rather than incidental semantic-tree node counts when they differ.\n\n### Inspect Plugin Settings\n\nWhen the target is a plugin:\n\n1. Find every exposed setting in the plugin metadata `SettingDefinitions`, dynamic setting callbacks, and query/action forms. Record its key, type, default, validators, options, and visibility conditions.\n2. Search every read of each setting, including `GetSetting` calls, initialization, reload callbacks, and persistence code. Map the setting to the behavior it actually changes.\n3. Build a setting coverage matrix with: setting, affected user behavior, important values or boundaries, existing coverage, smoke value, automation feasibility, and recommendation.\n4. Recommend a smoke case when a setting changes query results, actions, enablement, persistence or reload behavior, platform integration, validation or recovery, or another user-visible cross-process boundary.\n5. Skip separate smoke coverage for headings, labels, layout-only fields, equivalent options already covered by one representative value, and branches better protected by unit tests. Avoid a case for every setting or every option.\n6. Group settings into one user flow only when they naturally belong to the same task and failures remain easy to diagnose. Keep independent high-risk behaviors in separate cases.\n7. Never require real secrets, uncontrolled network services, or unavailable hardware. Prefer deterministic missing/invalid configuration and local persistence behavior unless the dependency is explicitly controlled by the test environment.\n\n## Recommend Coverage\n\nWhen the user asks for coverage design, present:\n\n- **Code map:** Name the main source files, functions, and responsibilities.\n- **Functional points:** Summarize the primary user-visible behaviors and important boundaries.\n- **Candidate cases:** Recommend no more than five flows, ordered by value. For each, include priority, user risk, existing coverage gap, prerequisites, actions, observable expected result, and automation feasibility.\n- **Plugin setting matrix:** For plugin requests, show which exposed settings deserve smoke coverage, which do not, and the source-backed reason for each decision.\n- **Recommended first case:** Select the smallest flow that covers the highest-risk real integration boundary and explain briefly why it belongs in smoke rather than a unit test.\n- **Automation gap:** Identify any missing stable automation ID or action required by the recommended flow.\n\nWhen the user already specified the exact flow, keep the pre-edit design brief: present only the code map, one observable behavior contract, and any automation gap. Do not expand an approved flow into an unnecessary candidate list or full setting matrix.\n\nRecommend smoke coverage only for real-process native UI, lifecycle, persistence, plugin integration, platform, accessibility, or rendering boundaries. Prefer unit tests for local pure logic and skip behavior already covered at the same boundary.\n\nIf the user asked only for design, stop after the recommendation. If the user already named or approved an exact flow, continue. Otherwise ask which recommended case to generate before editing product or test code.\n\n## Generate the Case\n\n1. State one observable behavior contract for the selected flow.\n2. Search all smoke packages for an existing helper before adding a local one. Promote a helper to `automationdriver` or `smoke` when a second consumer uses the same interaction contract; keep plugin-specific behavior in the leaf package. Avoid page-object layers or table-editor DSLs until repeated cases justify them.\n3. Reuse existing automation IDs, actions, `smoke.Case`, and helpers. Before driving a control, confirm its semantics expose a stable ID, role, label, current value or checked state, selected state when relevant, and the correct action. If that contract is missing, modify the smallest shared owning UI component to add a stable automation ID or semantic action, then add a focused component test for that contract. The semantic action must follow the real user interaction path; do not add a test-only bypass around product behavior.\n4. Add the case under the owning functional path. Reserve `wox.core/test/smoke/setting/` for Wox's own settings sections, such as `setting/ui/`. Every plugin-owned case must live under `wox.core/test/smoke/launcher/plugin/<plugin>/`, including flows that configure the plugin through its Settings page before exercising Launcher behavior. Classify by product owner rather than the UI route used during the flow; for example, place Calculator coverage under `launcher/plugin/calculator/`. Use the next unused three-digit number without renumbering existing cases:\n   - File: `NNN_descriptive_name_test.go`\n   - Function: `TestNNNDescriptiveName`\n   - Build constraint: `//go:build wox_ui_smoke`\n5. Immediately above every generated `TestNNN...` function, add a concise English doc comment that states the user-visible intent, the ordered UI flow, and the final evidence that proves the behavior. Mention prerequisites or cleanup only when they are part of the contract. Describe product behavior rather than automation implementation details. Use this shape:\n\n   ```go\n   // TestNNNDescriptiveName verifies <user-visible behavior and boundary>.\n   // Flow: <entry> -> <important actions or state transitions> -> <observable result>.\n   // Evidence: <real UI, runtime, persisted artifact, or log assertion that proves success>.\n   func TestNNNDescriptiveName(t *testing.T) {\n   ```\n\n6. Drive the UI through `automationdriver.Client` semantic actions (`Perform`, `PressKey`, `SetValue`) and `client.WaitFor`. Never use fixed sleeps to guess readiness. Use postconditions such as `Selected`, `Checked`, `Value`, status, or disappearance. Do not use mouse clicks, drags, node bounds, pointer coordinates, or screenshot pixels when a semantic action can produce the same transition. A real pointer or OLE drag is allowed only when the behavior under test is that native gesture and no semantic action exists. Even then, do not assert desktop hit-testing: which other HWND became foreground, title-bar or caption-button coordinates, z-order, or that a fixed client point such as a window center stays uncovered. Developer screens and CI desktops overlap differently. Assert Wox's own outcome (visibility, query result, callback, or file artifact). If a point is unavoidable, derive it at runtime from current window rects and keep it off other windows in the case.\n7. Treat query and result state as generation-bound. Setting the same query value may be a no-op, and refreshes may replace dynamic result IDs. Force a real query transition when freshness matters, wait for both the input value and `launcher.results=complete`, and resolve dynamic IDs again after refresh instead of retaining them across generations.\n8. Treat every command executed by a smoke case as interpreter- and platform-dependent input. Confirm the interpreter the case actually selects or inherits on Windows, macOS, and Linux. Prefer the simplest syntax shared by all targeted interpreters; do not assume Bash operators such as `&&`, `export`, Unix paths, or Unix-only tools work in Windows PowerShell. When no shared command exists, select the command with `runtime.GOOS` and, when configurable, the chosen interpreter, while keeping output and side effects equivalent. Normalize path separators and line endings in assertions. If the behavior is intentionally platform-specific, skip it explicitly with the reason instead of waiting for an impossible state.\n9. Let `smoke.Case` own before/after reset and the shared client, but do not assume reset restores plugin settings or desktop side effects. Explicitly restore changed settings and clean external state. Reopen settings or inspect persisted data before exercising runtime behavior; a locally updated control does not prove an asynchronous save completed.\n10. Keep assertions user-visible and deterministic. Prefer evidence in this order: real runtime artifact or fresh log slice, reloaded persisted value, then live semantic state. Treat relevant snapshot diagnostics as failures. Do not weaken assertions or add retries merely to hide a race.\n11. Do not launch another Wox process or create a second data directory inside a case. Use `automationdriver.SharedDataDirectoryEnvironment` only when the behavior must inspect real persisted output, and poll artifacts independently of UI generation changes.\n12. Format every touched Go file with the repository formatter. Run the new case from the repository root:\n\n   ```text\n   make smoke <functional/path/NNN>\n   ```\n\n13. After the targeted case passes, run `make smoke` to catch leaked state and shared-process cleanup failures. If the full suite fails in an existing case, distinguish that baseline failure from the new selector instead of attributing it to the new coverage. If execution is blocked by the environment, report the exact blocker and do not claim runtime coverage.\n\n## Failure Handling\n\n- Start from the exact command output, logs, snapshot, and failing state.\n- On a wait failure, capture the current values, checked states, status nodes, diagnostics, and relevant fresh log or artifact contents. Report the observed boundary instead of only the timeout.\n- Fix the shared product or automation boundary when that is the root cause; do not patch every case around it.\n- Add diagnostic logging only when the failure path cannot be identified with certainty, then use the new evidence before changing behavior.\n- Preserve unrelated worktree changes and keep the diff limited to the case plus any strictly required automation exposure.\n\n## Completion\n\nReport the behavior covered, the created case selector, every production or automation file changed to support it, and the exact verification commands with pass or failure status.\n",".agents/skills/wox-plugin-submit2store/SKILL.md":"---\nname: wox-plugin-submit2store\ndescription: Submit a Wox plugin to the official store by ensuring the user has a reusable fork of Wox-launcher/Wox, checking whether the plugin ID already exists in store-plugin.json, adding a new store entry when missing, and preparing a pull request to Wox-launcher/Wox. Single-file SDK plugins should be hosted on a public GitHub gist. Do not open the store pull request unless ScreenshotUrls contains at least one public screenshot of the plugin running in 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.\n---\n\n# Wox Plugin Submit2store\n\n## Overview\n\nSubmit a plugin 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. A store entry requires at least one public screenshot. Do not submit with an empty or omitted `ScreenshotUrls`, and do not open a PR that says a screenshot will be added later.\n\nFor **single-file SDK plugins**, host the plugin on a public GitHub gist. That is the simplest store delivery. Do not require a GitHub repository, `plugin.json`, or a `.wox` package. Example: https://gist.github.com/qianlifeng/04a9609de66eaa582a473f5852450ede\n\n## Workflow\n\n1. Ensure the user already has a fork of `Wox-launcher/Wox`, or create one.\n2. Read the current plugin (packaged repo, or the single-file `.js`/`.py` header) before touching the store repo.\n3. Validate that the plugin has enough public metadata and release assets for a store entry, including at least one public screenshot of the plugin running in Wox.\n4. Clone the user's fork into a temporary directory and add `upstream` for `https://github.com/Wox-launcher/Wox`.\n5. Check upstream `store-plugin.json` for the current plugin ID.\n6. Stop and tell the user not to submit when the ID already exists.\n7. Add the new store entry when the ID is absent.\n8. Commit on a branch in the fork and open a PR to `Wox-launcher/Wox`.\n\n## Ensure A Fork Exists First\n\nTreat fork setup as the first gate. Do not clone or edit a working copy until one of these is true:\n\n- the user already has a fork of `Wox-launcher/Wox`\n- the current authenticated GitHub user can create one now\n\nUse this order:\n\n1. Check whether the user already has a fork and reuse it when present.\n2. If `gh` is available and authenticated, create the fork from the CLI.\n3. If `gh` is unavailable, unauthenticated, or fails, send the user to the web fork flow and continue only after the fork exists.\n\nFor CLI-driven fork handling:\n\n- prefer reusing an existing fork instead of creating a new one\n- if a fork is missing, create it with GitHub CLI\n- after the fork exists, treat the fork as `origin` and the official repo as `upstream`\n\nFor web fallback:\n\n- direct the user to `https://github.com/Wox-launcher/Wox/fork`\n- wait for the user to confirm the fork is ready\n- continue by cloning the fork repository, not the upstream repository\n\nWhen the user has direct write access to `Wox-launcher/Wox`, a fork is not required. Otherwise, do not assume direct push access.\n\n## Read Local Metadata First\n\nFor a **single-file SDK plugin**, read the JSON metadata header in the live `.js` or `.py` file (usually `~/.wox/wox-user/plugins/single-file/Wox.Plugin.<Name>.js`). Prefer a public gist as `Website` / `DownloadUrl`. Upload the screenshot and icon to GitHub and use `https://gist.github.com/user-attachments/assets/<id>` URLs for `IconUrl` and `ScreenshotUrls`.\n\nFor a **packaged SDK plugin**, read at least:\n\n- `plugin.json`\n- `package.json` when version information needs confirmation\n- local screenshots or icon files when URLs need to be derived\n- git remotes to determine the GitHub repository URL\n\nExtract or derive these values:\n\n- plugin `Id`\n- `Name`\n- `Author`\n- `Version`\n- `MinWoxVersion`\n- `Runtime`\n- `Description`\n- `Website` (gist HTML URL, or GitHub repository URL)\n- `DownloadUrl` (gist raw `.js`/`.py` URL, or `.wox` release asset)\n- public icon URL\n- required screenshot URLs: at least one public image of the plugin running in Wox\n- supported operating systems\n\nStop and ask the user to fix the source first when any of these conditions hold:\n\n- metadata still contains template placeholders such as `{{.Id}}` or `{{.Name}}`\n- a single-file plugin has no public gist whose raw URL path ends with `.js` or `.py`\n- a packaged plugin has no public repository URL or no installable `.wox` release asset\n- there is no screenshot, `ScreenshotUrls` would be empty or omitted, or the only screenshot is local and has no stable public URL\n- the icon is only local and no stable public URL can be formed\n\n## Clone The Fork And Check For Duplicates\n\nClone 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`.\n\nInspect `store-plugin.json` from the current upstream default branch and search by the exact plugin ID from the local metadata.\n\nWhen the ID already exists:\n\n- do not modify `store-plugin.json`\n- tell the user that the plugin is already listed\n- include the existing matching entry or its location so the user can verify it quickly\n\nWhen the ID does not exist:\n\n- continue to create a new entry\n- preserve the file's existing formatting and ordering style\n\n## Build The Store Entry\n\nUse the field template and sourcing rules in [references/store-plugin-entry.md](./references/store-plugin-entry.md).\n\nApply these rules while building the JSON object:\n\n- Keep `Id`, `Name`, `Author`, `Version`, `MinWoxVersion`, and `Runtime` aligned with local plugin metadata.\n- Prefer a plain `Description` string when no i18n payload exists.\n- Add `I18n` only when the repository already has trustworthy localized copy.\n- Convert local OS names to the store style: `Windows`, `Darwin`, `Linux` (`Macos` in plugin headers becomes `Darwin`).\n- Set `DateCreated` and `DateUpdated` to the current local timestamp in `YYYY-MM-DD HH:MM:SS`.\n- For a gist-hosted single-file plugin: `Website` is the gist HTML URL, `DownloadUrl` is the gist raw URL including the `.js` or `.py` filename, and `IconUrl` / `ScreenshotUrls` are `https://gist.github.com/user-attachments/assets/<id>` links. Runtime is lowercase `nodejs` or `python`.\n- For a packaged plugin: use the canonical repository URL for `Website`, the latest `.wox` release asset for `DownloadUrl`, and public raw image URLs for `IconUrl` / `ScreenshotUrls`.\n- `ScreenshotUrls` must contain at least one public URL. Do not omit the field, submit `[]`, or continue while telling the user that no screenshot is included yet. Ask for a screenshot and stop until one is uploaded. Use a cropped Wox launcher screenshot that shows the query and the plugin's real results, like https://raw.githubusercontent.com/Wox-launcher/Wox.Plugin.ColorPicker/main/images/screenshot1.png. Do not submit an icon, a README image, source code, or a full-desktop capture.\n\nBefore editing `store-plugin.json`, re-check that the generated URLs and filenames match the gist file name or the packaged repository layout.\n\n## Prepare The PR\n\nAfter editing the cloned fork workspace:\n\n1. Create a branch such as `codex/add-<plugin-name>-store-entry`.\n2. Commit only the `store-plugin.json` change.\n3. Push to the user's fork.\n4. Open a PR targeting `Wox-launcher/Wox`.\n\nUse a concise PR title such as `Add <Plugin Name> to store`.\n\nUse a PR body that includes:\n\n- what plugin was added\n- the gist or repository URL\n- the download URL\n- every public screenshot URL. Stop instead of opening the PR when this list is empty\n\n## Report Back To The User\n\nAlways end with one of these outcomes:\n\n- `Already listed`: explain that no submission is needed.\n- `Ready to submit`: summarize the new store entry and PR URL.\n- `Waiting for fork`: tell the user to finish the web fork flow before continuing.\n- `Blocked`: list the missing metadata or missing public assets that prevented submission.\n",".agents/skills/wox-commit/SKILL.md":"---\nname: wox-commit\ndescription: Generate a repository-style commit message from the current Wox working tree without modifying the repository. Use when the user asks for a commit message or explicitly invokes `$wox-commit`.\n---\n\n# Wox Commit Message\n\n## Contract\n\nTreat explicit invocation as permission to inspect the current Wox diff and generate a commit message only. Do not stage, commit, amend, push, or otherwise modify the repository.\n\n## Workflow\n\n1. Read the repository instructions and inspect `git status --short`, the unstaged and staged diffs, and relevant untracked files.\n2. Infer every distinct behavior change from the actual diff and recent commit style. Do not ask the user to pick one feature when several unrelated changes are present.\n3. Prefer `type(scope): imperative summary` for normal code changes; use the repository's established wording for automated, release, or store updates.\n4. Always return both a subject and a body in one copy-ready block.\n\n## Message Rules\n\n- Describe the reason or behavior change, not a file list.\n- Keep the subject specific, imperative, and free of trailing punctuation.\n- Choose the narrowest accurate scope already used by nearby commits. When the tree spans unrelated areas, omit a misleading narrow scope rather than picking one feature.\n- Use `feat`, `fix`, `refactor`, `docs`, `test`, `build`, or `chore` only when it matches the diff.\n- Cover every distinct change in the same message. Unrelated features still belong in one subject-plus-body: name each behavior so a reviewer can see all of them without reading the file list.\n- When one change dominates, put it in the subject and name the others in the body. When two or more are peer features, name both in the subject if they fit; otherwise use a broader subject and give each change its own sentence in the body.\n- Always write a body that expands the why or the non-obvious behavior. One or two sentences is enough for a single change; use one short sentence per distinct change when the tree contains more than one. Do not leave the body empty.\n- Do not run formatting, tests, hooks, or other validation; the caller has already completed validation before requesting the message.\n\n## Completion\n\nReturn exactly one fenced text block the user can copy as a full commit message: subject, a blank line, then the body. After the block, add a brief note only if the diff is empty. Do not claim that a commit was created.\n\n```text\ntype(scope): imperative summary\n\nBody that explains the why or the non-obvious behavior.\n```\n",".agents/skills/wox-i18n/SKILL.md":"---\nname: wox-i18n\ndescription: Add a new Wox language or complete and improve an existing Wox translation. Use for Wox-owned locale registration, translation parity, wording quality, and placeholder-safe updates based on wox.core/resource/lang/en_US.json.\n---\n\n# Wox I18n\n\nUse `wox.core/resource/lang/en_US.json` as the authoritative source for keys, meaning, structure, and placeholders. Work on one requested locale at a time unless the user explicitly asks for several.\n\n## Shared rules\n\n- Read the repository `AGENTS.md` and the relevant locale files before editing.\n- Preserve every placeholder exactly, including `{name}`, Wox placeholders such as `{wox:selected_text}`, printf verbs such as `%s` and `%02d`, newlines, and other formatting tokens. Reordering placeholders is allowed only when the format mechanism supports it and the target language requires it.\n- Resolve ambiguous English by searching for the key's call sites and neighboring translations. Translate the UI meaning, not the key name in isolation.\n- Keep product names, commands, file paths, URLs, keyboard shortcuts, and technical identifiers unchanged when they are proper names or literal input.\n- Match the tone and terminology already used by the target locale. Prefer natural, concise UI text over literal translation.\n- Keep JSON valid, formatted with two-space indentation and a final newline. Preserve English key order; insert missing entries beside their English counterparts instead of reordering unrelated entries.\n- Do not put Wox-owned translations in Go maps. Keep them in `wox.core/resource/lang/*.json` and reference them with `i18n:` keys, as required by the repository instructions.\n- Do not blanket-translate third-party entries in `store-plugin.json`; their translations belong to their authors. Wox-owned catalogs such as `store-ai-command.json` are in scope when they contain the target locale.\n\n## Choose the workflow\n\n### Add a new language\n\nUse commit `0cfb2a346af4278c5cd385aa649cb9ddb641f461` as a concrete checklist, but follow the current tree when it has evolved:\n\n```powershell\ngit show --stat 0cfb2a346af4278c5cd385aa649cb9ddb641f461\ngit show 0cfb2a346af4278c5cd385aa649cb9ddb641f461 -- wox.core/i18n/lang.go store-ai-command.json wox.core/ui/launcher/view/form_table_view_test.go www/docs/.vitepress/theme/components/pluginStore.ts www/docs/development/plugins/specification.md www/docs/zh/development/plugins/specification.md AGENTS.md\n```\n\nThen make the smallest complete current-tree change:\n\n1. Confirm the locale code, English language name, and native display name.\n2. Create `wox.core/resource/lang/<locale>.json` with every key from `en_US.json`, in the same order, fully translated.\n3. Register the `LangCode` and native display name in `wox.core/i18n/lang.go`.\n4. Add the locale to Wox-owned locale maps, currently including `store-ai-command.json`, and to website locale mapping where applicable.\n5. Update current supported-language documentation and any tests that explicitly enumerate languages or translated labels.\n6. Search for the existing locale codes to find registration surfaces added after the reference commit. Update only surfaces whose behavior depends on the complete supported-language list.\n\nDo not create a translated documentation site merely because the app gains a locale; add one only when the user requests and supplies that scope.\n\n### Complete or improve an existing language\n\n1. Run the checker to identify missing, extra, empty, identical-to-English, and placeholder-mismatched values.\n2. Add every missing English key and translate it from the English value. Treat identical values as review candidates, not automatic errors: names and technical terms may legitimately remain English.\n3. For requested quality improvements, inspect awkward or stale values in related groups and their call sites. Change only wording you can improve confidently.\n4. Remove an extra key only after confirming that it is absent from `en_US.json` and unused; otherwise report it for review.\n5. Check Wox-owned auxiliary catalogs, especially `store-ai-command.json`, for missing target-locale entries when the request is to complete the language across Wox.\n\nAvoid replacing the whole locale file when a focused insertion or wording edit produces a clear diff.\n\n## Verification\n\nRun from the repository root:\n\n```powershell\npython .agents/skills/wox-i18n/scripts/check_locale.py <locale>\ngit diff --check\n```\n\nThe checker must pass without missing keys, extra keys, empty values, or placeholder mismatches. Review its identical-value warnings manually.\n\nIf language registration or enumerating tests changed, run the focused Go tests from `wox.core`:\n\n```powershell\ngo test ./i18n ./ui/launcher/view\n```\n\nFinish by reviewing the diff for accidental English fallback text, placeholder damage, unrelated rewrites, and omissions from the reference-commit checklist.\n",".agents/skills/wox-memory-debug/SKILL.md":"---\nname: wox-memory-debug\ndescription: Diagnose memory leaks in the current single-process Wox Go UI by launching the real debug build with its automation endpoint enabled, replaying representative launcher searches and settings-window open/close cycles, sampling the same process across repeated workload blocks, and comparing Go heap profiles when retained memory keeps growing. Use for Wox memory-leak checks, search-result retention, settings cleanup, Go UI memory growth, or repeated UI lifecycle regressions on Windows or macOS.\n---\n\n# Wox Memory Debug\n\n## Goal\n\nRun the real Go UI in debug mode with the `wox_automation` endpoint, exercise normal launcher searches and the independent settings-window lifecycle through the semantics tree, and decide whether memory settles after warm-up or grows with repeated work. Treat Wox as one Go process and use post-warm-up growth rather than an absolute memory budget as the leak criterion.\n\n## Run the Debug Build\n\n1. Stop other Wox instances so sampling cannot select the wrong process.\n2. Start the real Wox debug build under Delve with both production dependencies and the automation endpoint enabled:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\nWOX_AUTOMATION_INFO_FILE=/tmp/wox-memory-automation.json /Users/qianlifeng/go/bin/dlv debug . --build-flags=-tags=sqlite_fts5,wox_automation\n```\n\n3. At the Delve prompt, run `continue`.\n4. Wait until startup and plugin initialization finish, then wait for `WOX_AUTOMATION_INFO_FILE` to be written.\n5. Record the debuggee PID from the debugger. Always pass this PID to the sampler because debugger-built executables may have temporary names.\n\nKeep the debugger running normally. Do not pause at breakpoints while collecting memory samples. This uses the real Wox process with only the automation server compiled in; do not launch the separate Go UI smoke-test runner.\n\n## Establish a Warm Baseline\n\nUse the bundled automation workload driver against the real launcher:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\ngo run ../.agents/skills/wox-memory-debug/scripts/run-query-workload.go -info /tmp/wox-memory-automation.json -mode queries -count 20 -seed 1\n```\n\n1. Run two warm-up blocks before recording the baseline.\n2. In each block, replay 20 queries drawn repeatedly from these safe categories:\n   - Calculator, such as `1+1`.\n   - System command lookup, such as `settings`.\n   - Application or general search, such as `wox`.\n   - File-oriented search, such as `readme`.\n3. Use a different deterministic seed for each block so the workload is reproducible while still varying result types.\n4. The driver waits for the query value, allows results to settle, records the visible result count and semantics generation, clears the query, and continues. It does not execute results or commands.\n5. At the end of the block, the driver hides the launcher. Wait 10 seconds so every checkpoint uses the same idle state.\n\nTake the warm baseline only after these blocks. Initial startup growth, lazy font loading, icon decoding, and cache creation are expected and are not leak evidence.\n\n## Sample the Same Process\n\n### macOS\n\n```bash\n/Users/qianlifeng/Projects/Wox/.agents/skills/wox-memory-debug/scripts/sample-wox-memory-macos.sh --pid <PID> --samples 3 --interval 2\n```\n\nUse `PhysicalFootprintMB`. Absolute debug memory is not the leak criterion.\n\n### Windows\n\n```powershell\npowershell -ExecutionPolicy Bypass -File C:\\dev\\Wox\\.agents\\skills\\wox-memory-debug\\scripts\\sample-wox-memory.ps1 -Pids <PID> -Samples 3 -IntervalSeconds 2\n```\n\nUse `PrivateWorkingSetMB`.\n\nDo not compare macOS physical footprint with Windows private working set. Compare checkpoints from the same PID, OS, debug session, workload, and idle state.\n\n## Run the Measured Query Workload\n\n1. Record the warm baseline.\n2. Run five measured blocks of 10 or 20 queries using distinct seeds and the same query pool.\n3. After each block, clear the query, hide the launcher, wait 10 seconds, and sample the same PID three times.\n4. Record the median of each three-sample checkpoint to reduce sampler noise.\n5. Report cumulative query count, median memory, change from the warm baseline, and the observed shape of the series.\n\nUse more blocks only when the trend is ambiguous. Keep the process alive for the whole run; restarting Wox invalidates the comparison.\n\n## Test Settings Window Cleanup\n\nRun this lifecycle check after the query workload. It opens settings through the real `Open Wox Settings` result, waits for the independent settings semantics host, closes the settings window, waits until the launcher host owns automation again, and clears the opening query:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\ngo run ../.agents/skills/wox-memory-debug/scripts/run-query-workload.go -info /tmp/wox-memory-automation.json -mode settings -count 1\n```\n\n1. Run one settings cycle as warm-up. Wait 10 seconds and record the closed-settings baseline.\n2. Run at least three measured blocks of five open/close cycles:\n\n```bash\ngo run ../.agents/skills/wox-memory-debug/scripts/run-query-workload.go -info /tmp/wox-memory-automation.json -mode settings -count 5\n```\n\n3. After each block, keep both launcher and settings closed, wait 10 seconds, and sample the same PID three times. Record the median.\n4. Confirm every cycle reports both an `opened_generation` and `closed_generation`. The driver considers close complete only after `settings-search-field` disappears and `launcher.query.input` returns, which means `settingsView` and `settingsHost` have left the active automation surface.\n5. Compare measured block medians with the post-warm-up closed-settings baseline. Repeat one identical five-cycle block after a 30-second idle checkpoint when the trend is ambiguous.\n\nThe first settings open may retain shared fonts, icons, and reusable renderer caches. Do not require the process to return to its pre-first-open value. Window-scoped settings state and native resources must not accumulate across later cycles: after warm-up, closed-settings checkpoints should plateau within sampler jitter instead of growing with cumulative open/close count.\n\n## macOS Debug Reference\n\nUse the August 10, 2026 macOS arm64 run as a comparison point for the current settings cleanup behavior, not as an absolute budget. The run used macOS 26.5.2, Go 1.26.2, Delve 1.26.2, the `sqlite_fts5,wox_automation` build tags, real Wox data, one PID, a 10-second hidden/closed wait, and three `PhysicalFootprintMB` samples at two-second intervals.\n\nThe query baseline was recorded after two 20-query warm-up blocks. The settings baseline was recorded after one complete warm-up open/close cycle:\n\n| Checkpoint | Median PhysicalFootprintMB | Change from closed-settings baseline |\n| --- | ---: | ---: |\n| Hidden after 40 warm-up queries | 89.1 MB | N/A |\n| Settings closed warm baseline | 99.5 MB | 0.0 MB |\n| 5 measured settings cycles | 100.9 MB | +1.4 MB |\n| 10 measured settings cycles | 101.4 MB | +1.9 MB |\n| 15 measured settings cycles | 101.7 MB | +2.2 MB |\n| 30-second idle confirmation | 102.3 MB | +2.8 MB |\n\nClassify this series as `no leak signal`: the closed-settings checkpoints remained around 100-102 MB, and the 30-second confirmation stayed within observed sampler and allocator variation. `vmmap` reported no resident IOSurface memory after close; CoreGraphics and IOAccelerator residency was negligible. A Go heap comparison captured during the investigation showed only about 15 KB of retained delta, which redirected attribution to native window ownership rather than Go settings state.\n\nPreserve these cleanup contracts when investigating a regression:\n\n- Keep at most one live `wox.settings` window, while still treating each close/reopen as a new native lifetime.\n- Release settings-only plugin catalogs, search indexes, forms, and application candidates on close, and invalidate in-flight loads so they cannot refill released caches.\n- Load the plugin store and application candidates only when their UI needs them.\n- Release the macOS `NSWindow`, view, and delegate hierarchy synchronously on close. Do not defer them to the application-lifetime autorelease pool.\n\nBefore the native close fix, a separate same-shape debug run rose from 104.8 MB after the warm settings close to 112.8 MB after 15 measured cycles. Treat a return of that cumulative, window-count-scaled shape as a regression even when the absolute starting footprint differs.\n\n## Windows Debug Reference\n\nUse the September 22, 2026 Windows run as a comparison point for hidden idle memory, not as a budget. The run used a dev build with `sqlite_fts5,wox_automation`, real Wox data, two 20-query warm-up blocks, and three `PrivateWorkingSetMB` samples 45 seconds after hide, when both the 10-second and 30-second release stages had run:\n\n| Checkpoint | Median PrivateWorkingSetMB | Live Go heap |\n| --- | ---: | ---: |\n| Staged trims plus prepared search text and pinyin release | 63.8 MB | 17.2 MB |\n| Shared plugin logger and shared fsnotify watcher | 60.8 MB | 15.2 MB |\n| Live-object reductions (`wox.core/ui/README.md`, \"Hidden-state ownership rules\") | 55.4 MB | 11.0 MB |\n\nHidden memory drops in two steps: about 2-4 MB at 10 seconds and about 40 MB at 30 seconds, so sampling before 45 seconds compares different lifecycle states. When attributing what remains, use Delve `goroutines -group userloc` for goroutine ownership and the `woxmemory go` / `woxmemory native` commands for the Go-versus-native split; the largest native owners are NT heap fragmentation from show/hide churn and renderer objects that survive hide.\n\n## Decide Whether Memory Leaks\n\nInterpret the post-warm-up series, not a single number:\n\n- **No leak signal:** memory rises during warm-up and then plateaus, oscillates within a stable range, or drops after an idle checkpoint.\n- **Possible leak:** the settled checkpoint median keeps increasing across at least three consecutive measured blocks and the increase is materially larger than sampler jitter.\n- **Strong leak signal:** retained growth continues after another identical workload, scales with cumulative query or settings-cycle count, and does not settle during a longer 30-60 second idle checkpoint.\n\nApply the same classification independently to cumulative queries and cumulative settings cycles. A stable query series does not rule out a settings-window lifecycle leak.\n\nGo may retain heap arenas after objects become unreachable, so a high or non-decreasing process footprint alone is not proof. Report the result as `no leak signal`, `possible leak`, or `strong leak signal`, together with the measurements that support it.\n\n## Attribute Persistent Growth\n\nOnly profile after the repeated-query or settings-lifecycle run shows a possible or strong leak signal.\n\n1. Trigger the Wox Memory plugin's `woxmemory profile ` command through the automation driver after warm-up:\n\n```bash\ngo run ../.agents/skills/wox-memory-debug/scripts/run-query-workload.go -info /tmp/wox-memory-automation.json -mode profile\n```\n2. Copy the generated profile immediately because the next capture overwrites it:\n\n```bash\ncp ~/.wox/memory.prof /tmp/wox-memory-before.prof\n```\n\nOn Windows, copy `%USERPROFILE%\\.wox\\memory.prof` to a distinct temporary file instead.\n\n3. Repeat the measured workload, run the command again, and copy the second profile:\n\n```bash\ncp ~/.wox/memory.prof /tmp/wox-memory-after.prof\n```\n\n4. Compare retained Go heap growth from `wox.core`:\n\n```bash\ngo tool pprof -top -base /tmp/wox-memory-before.prof /tmp/wox-memory-after.prof\n```\n\nIf process memory grows but the Go heap delta stays small, inspect Go UI native owners next: GPU textures and image caches, decoded result icons, preview resources, platform window allocations, and query-result cleanup. For settings-only growth, inspect `settingsView`, `settingsHost`, settings editors/forms, theme wallpaper previews, cloud/model state, asynchronous reloads, and native window/renderer destruction. On macOS, compare `vmmap <PID> -summary` checkpoints and pay particular attention to `IOAccelerator` and `IOSurface`. If repeated identical queries still grow, inspect lazy-image cache identity, per-draw Metal texture creation, and drawable-size churn before attributing growth to unique query strings.\n\nUse `-query terminal` with query mode for an identical-query control only when the mixed workload needs further attribution.\n\n## Report\n\nInclude:\n\n- OS, debug configuration, PID, workload, and checkpoint timing.\n- A checkpoint table with cumulative queries and median process memory.\n- A separate closed-settings checkpoint table with cumulative open/close cycles and median process memory.\n- The trend classification and whether a longer confirmation block was needed.\n- Go heap delta owners only when profiling was necessary.\n- Any limitation that prevented consistent UI automation or reliable sampling.\n\nDo not edit production code until the measurements identify a reproducible trend and a likely owner.\n",".agents/skills/wox-plugin-creator/SKILL.md":"---\nname: wox-plugin-creator\ndescription: Create, scaffold, implement, and package Wox plugins (nodejs, python, singlefile-python, singlefile-nodejs). Use when cloning official SDK templates, generating single-file SDK plugin templates, editing plugin.json metadata, defining SettingDefinitions and validators, wiring i18n, implementing plugin APIs, QueryResponse refinements, refinement and action hotkeys, structured query slots, Plugin Tools (RegisterPluginTool / InvokePluginTool), 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.\n---\n\n# Wox Plugin Creator\n\n## Quick Start\n\n- Scaffold a Node.js plugin (clones template repo):\n  - `python3 scripts/scaffold_wox_plugin.py --type nodejs --output-dir ./MyPlugin --name \"My Plugin\" --trigger-keywords my`\n- Scaffold a Python plugin (clones template repo):\n  - `python3 scripts/scaffold_wox_plugin.py --type python --output-dir ./MyPlugin --name \"My Plugin\" --trigger-keywords my`\n- Scaffold a single-file SDK plugin (uses local templates; plugin-id auto-generated; writes **one** file into the live user plugin directory so a running Wox instance can load it immediately). Omit `--output-dir`; default is `~/.wox/wox-user/plugins/single-file/` (Windows: `%USERPROFILE%\\.wox\\wox-user\\plugins\\single-file\\`):\n  - Auto-detect this machine: `python3 scripts/scaffold_wox_plugin.py --type singlefile --name \"Weather\" --trigger-keywords weather`\n  - Explicit Node.js: `python3 scripts/scaffold_wox_plugin.py --type singlefile-nodejs --name \"Weather\" --trigger-keywords weather`\n  - Explicit Python: `python3 scripts/scaffold_wox_plugin.py --type singlefile-python --name \"Weather\" --trigger-keywords weather`\n\n## Choose a plugin type\n\n- **Single-file SDK plugin**: one `.py` or CommonJS `.js` file with full Public API, loaded into the existing Python/Node runtime host. No extra process per query. Create and edit **only** `~/.wox/wox-user/plugins/single-file/Wox.Plugin.<Name>.js` (or `.py`); Wox watches that directory and reloads on save. Requires Wox 2.4.2+; header `MinWoxVersion` must be `\"2.4.2\"`.\n- **SDK plugin (`.wox`)**: multi-file package with dependencies, resources, TypeScript, and `plugin.json`.\n\nNode.js first version must stay CommonJS (`module.exports.plugin`) and must not import `@wox-launcher/wox-plugin`.\n\n## Choose a runtime language\n\nHonor an explicit Python or Node.js request from the user, including a `.py` or `.js` output filename.\n\nWhen the user does not specify a language, detect this machine before scaffolding. Do not default to Python.\n\n1. Run `python3 scripts/detect_local_runtime.py` (use `python` if `python3` is missing). It prints `nodejs`, `python`, or `none`.\n2. If that script cannot run, check the floors yourself: `node --version` for Node.js 20+, and `python3 --version` for Python 3.10+. On Windows also try `py -3 --version` and `python --version`.\n3. Decision:\n   - Only one runtime meets the floor → use that runtime\n   - Both meet the floor → use Node.js\n   - Neither meets the floor → ask the user which language they want\n4. Map the choice to `--type`: `singlefile-nodejs` / `singlefile-python`, or `nodejs` / `python`. `--type singlefile` applies the same detection inside the scaffold.\n\n## Workflow\n\n### 1) Scaffold plugin files\n\n- Use `scripts/scaffold_wox_plugin.py` for `nodejs`, `python`, `singlefile`, `singlefile-python`, or `singlefile-nodejs`.\n- Pass `--name` and `--trigger-keywords` for every runtime. The scaffold exits without them. `--output-dir` is required for packaged SDK plugins; omit it for single-file SDK plugins so the file lands in `~/.wox/wox-user/plugins/single-file/`.\n- For Node.js and Python packages, the scaffold clones the official template repos and replaces placeholders like `{{.ID}}`, `{{.Name}}`, `{{.Description}}`, `{{.TriggerKeywordsJSON}}`, `{{.Author}}`.\n- Before starting work in a new SDK plugin project, run `make init` in the project root when the project has not been initialized yet.\n- Single-file SDK plugins are **single-file** host-loaded plugins. Prefer filenames like `Wox.Plugin.<Name>.js` or `Wox.Plugin.<Name>.py`.\n- **Single-file SDK destination**: create and implement the plugin as one file in `~/.wox/wox-user/plugins/single-file/` (Windows: `%USERPROFILE%\\.wox\\wox-user\\plugins\\single-file\\`). That directory is what a running Wox instance loads; saving reloads after about 500ms, so the user can query the trigger keyword immediately. Omit `--output-dir` when using the scaffold, or write the file there directly from `assets/single_file_plugin_templates/`. Do not also create a copy under the current repository (`plugins/`, workspace root, or a new folder). Pass `--output-dir` only when the user asks for a different path.\n- Do not put companion files (`*.test.js`, README, extra modules) in the live directory. Wox loads every `.js` and `.py` there as a plugin.\n- Single-file SDK plugins must set header `MinWoxVersion` to `\"2.4.2\"`. The scaffold applies this default when `--min-wox-version` is omitted. Do not lower it; Wox 2.4.2 is the first release that can load this plugin type, and store/CI reject older floors.\n- For single-file SDK plugins, the scaffold copies templates from `~/.wox/ai/skills/wox-plugin-creator/assets/single_file_plugin_templates/` (or the repo `.agents/skills/wox-plugin-creator/assets/single_file_plugin_templates/` fallback).\n- Prefer standard library features; avoid third-party dependencies unless absolutely necessary. Single-file SDK plugins cannot use pip/npm packages.\n- For SDK usage and API details, read `references/sdk_nodejs.md` or `references/sdk_python.md`.\n- For plugins declaring `querySelection`, return results only for selection types and content the plugin can process. Return an empty results list for unsupported, missing, or empty selection data instead of showing usage or help rows for unrelated selections.\n- Keep a result on the row. `Title` is the name to scan. `SubTitle` is one short identity line, such as a code, place, or source. `Tails` are the few facts that must stay visible, such as a price and its change. Use at most three tail tags on one result. A fourth tag can be clipped, so part of a tag is not shown. Put any further fact in the subtitle, the copied text, or a preview. Do not add `Preview` for a quote, status, short record, or anything that fits on that row.\n- A durable result must set `IdentityKey` (Python `identity_key`, script JSON `identity_key`). Wox uses it for usage history, query pins, and MRU. The value must identify that one result and no other result from the plugin, and it must stay the same when the title, subtitle, translation, score, or query text changes. Use the item's own id, such as a path, URL, note id, command id, or record id. Do not use the visible title, a translated string, the current query, a random id, or one shared key for a whole list. The same item returned from search and from MRU restore must use the same key. `score_key` / `ScoreKey` is only the older name. Omit `IdentityKey` on a temporary result: a prompt, an empty or error state, a one-time status, or a row that exists only for the current selection or query and will not be pinned or restored.\n- A text tail already has a theme-aware rounded container. Use an SVG image tail only when that tag must also contain an icon. Match the launcher metrics below, and see [Simulated tail tags](#simulated-tail-tags).\n- Refresh a visible row in place with `UpdateResult` / `update_result`. Remember the results returned by the latest `query()`. Replace that list on the next query. When a background refresh or an action changes a row that is still on screen, call `UpdateResult` with the same result `Id` and only the fields that changed (`Title`, `SubTitle`, `Icon`, `Tails`, `Actions`). The query text stays put and the list does not reload. Use `RefreshQuery` / `refresh_query` only when rows must be added or removed and `UpdateResult` cannot express that. Do not use `ChangeQuery` to redraw results.\n- Add `Preview` only for a large body that cannot fit the row: a long document, many fields, a chart, a gallery, or syntax highlighting. When a preview is required, use `markdown` for prose, lists, links, and images. Use `text` or `image` when that is the whole preview. Use `webview` HTML only after markdown cannot express it, such as syntax highlighting, folding, or an interactive layout. HTML is the last option because the webview can steal query focus, miss launcher theme colors, and hit layout bugs. There is no separate `html` preview type; HTML uses `webview` with a JSON-encoded `html` field and no local HTTP server. See the HTML preview examples in the SDK references.\n- For dynamic updates to an existing HTML WebView, prefer script-mode `UpdateResult` / `update_result` with `{\"updateMode\":\"script\",\"script\":\"...\"}` instead of repeatedly replacing the full HTML. Update existing DOM nodes to preserve scrolling, text selection, and animations. This does not change the rule that HTML is the last preview option. Read [HTML preview updates](references/html_preview_updates.md) for the contract, lifecycle, safe serialization, and Python/Node.js examples.\n- Do not rasterize documents as SVG/`image` previews; those scale as pictures, cannot select text, and do not follow theme colors.\n- When HTML is required, follow the current Wox theme. Call `GetThemeColors` / `get_theme_colors` (Wox >= 2.4.5) when building the HTML and paint opaque `Background`, `Text`, `SecondaryText`, `Border`, `Accent`, `AccentText`, and `Selection`. Use `Dark` to choose a light or dark syntax palette. Do not hardcode only a dark page, and do not rely on `transparent` or `prefers-color-scheme` as a substitute for the launcher palette. Include a theme color in `cacheKey` so the preview refreshes after a theme change. If the API is missing, fall back to a dark and a light default.\n- For inline command arguments or atomic query blocks, read [QueryHint](#queryhint). Command declarations contain suffix templates; `ChangeQuery` contains a complete instance. Keep legacy text parsing when structure is absent.\n- For query-scoped filters or sort controls, return `QueryResponse.Refinements` and read [references/refinements.md](references/refinements.md).\n- Before assigning refinement or result action hotkeys, read [references/hotkeys.md](references/hotkeys.md). Prefer defaults that avoid Wox window commands, launcher bindings, focused-editor commands, and shortcuts for the plugin's preview type. Check refinements and actions together for duplicates; choose another chord or leave `Hotkey` empty when it conflicts. Do not assume adding Shift makes a built-in chord available.\n- For `plugin.json`, `SettingDefinitions`, `QueryRequirements`, validators, dynamic settings, and feature flags, read `references/plugin_json_schema.md` first.\n- When implementing an SDK or single-file SDK plugin, also register Plugin Tools in `init()` for capabilities other plugins should be able to call. Query results and actions stay for the user; tools expose the same work as structured operations. Read `references/plugin_tools.md` first. Requires Wox >= 2.4.5 (`MinWoxVersion` `\"2.4.5\"` or newer). Do not declare tools in `plugin.json`.\n- SDK and single-file SDK plugins should support MRU unless the plugin is clearly unsuitable. Declare the `mru` feature with `HashBy` `identityKey`, put restore identity on action `ContextData`, and register `OnMRURestore` / `on_mru_restore` in `init()`. The restored result must use the same `IdentityKey` as the original result. The restore callback must return immediately from memory or local cache. Wox waits 300ms for each start-page MRU restore, then discards that item, logs the timeout, and shows the next MRU item. Do not fetch, scan disk, or call host APIs inside the callback. Skip MRU only for context-dependent, one-shot, diagnostic, or inbox-style plugins, and say why in the implementation notes.\n- Persist user settings through the Public API (`GetSetting` / `SaveSetting` / `SetSetting` / `OnSettingChanged`, or Python `get_setting` / `save_setting` / `set_setting` / `on_setting_changed`). A normal setting write is cloud-synced and follows the user across machines. Use these APIs for preferences, API keys, favorites, and account configuration.\n\n### Cache stays out of the settings API\n\nAnything the plugin can rebuild is cache: fetched JSON, subject or entity snapshots, search indexes, downloaded files, and thumbnails. Write that data under the plugin cache folder. Do not pass it to `SaveSetting`, `SetSetting`, `save_setting`, or `set_setting`.\n\nPlugin settings are cloud-synced. Each settings write becomes a sync record and is copied to the user's other devices, including a hidden key that is absent from `SettingDefinitions`. A cache blob stored this way is uploaded on every refresh and fills sync history. `IsPlatformSpecific` still syncs; it only keeps a separate value per operating system. `IsLocal` / `is_local` is for a small machine-local preference that must remain in the settings store, such as a window position. It is not a place for cache.\n\n- Call `GetCacheFolder(ctx)` / `get_cache_folder(ctx)` once in `init()`, keep the path, and write cache files under it.\n- The folder is `~/.wox/cache/plugins/<plugin-id>/`. Wox creates it and deletes it when the plugin is uninstalled.\n- Do not invent a `cache/`, `tmp/`, `downloads/`, or `data/` directory beside the plugin file, under user data, or under a hardcoded name.\n- When authoring `SettingDefinitions`, always decide whether each setting is platform-specific before shipping it. Wox cloud sync replicates normal plugin settings across devices, so local paths, executable paths, shell commands, hotkeys, system integrations, browser profiles, and application paths should usually set `IsPlatformSpecific: true`. Account IDs, API keys, remote service hosts, and cross-platform user preferences should usually keep `IsPlatformSpecific: false`.\n- Use `DisabledInPlatforms` only to disable a setting on selected platforms. It does not isolate stored values; use `IsPlatformSpecific` when the value must differ per platform after cloud sync.\n- When a plugin cannot run a query without required settings such as access keys, declare those requirements in metadata `QueryRequirements` instead of returning ad hoc setup results from `query()`.\n- Query refinements (type filters, sort modes, and similar query-scoped chips) belong on `QueryResponse.Refinements`, not in command syntax. When assigning a refinement `Hotkey`, use the platform primary modifier: `cmd+<key>` on macOS and `ctrl+<key>` on Windows/Linux. Detect the OS at runtime and emit the matching string; omit the binding if no suitable chord is available.\n- For ready-to-copy patterns such as validated textbox/select fields, editable tables, AI model selectors, and dynamic preview settings, read `references/settings_patterns.md`.\n- For Python settings APIs, note that helper builders are limited; advanced settings are often created by constructing `PluginSettingDefinitionItem` and value objects directly.\n\n### 2) Author result and action icons\n\n- Read `references/icons.md` before choosing any glyph. Result-row and plugin-identity icons may be colorful; Action Panel leading icons must not.\n- Scaffold templates use inline SVGs for the default plugin and result icons. Keep those defaults as SVG; use emoji or other formats only when deliberately choosing a result identity icon.\n- Prefer a bundled monochrome verb from `assets/iconify/action/` (copy, open, execute/lightning, delete, edit, paste, add, search, settings). These SVGs already use `var(--wox-theme-icon-color)` so the Action Panel can tint them to the row label.\n- Do not use emoji, brand logos, the plugin mark, or mixed-color result art as the leading action icon. The panel only tints SVGs that contain the theme variable; anything else stays authored and looks inconsistent next to system actions.\n- Execute actions use the lightning verb (`action/execute.svg`), not a gear or play triangle. Settings actions use the gear.\n- For a new action metaphor, fetch a monochrome Iconify outline with `scripts/search_iconify.py` (it rewrites `currentColor` to the theme variable by default). Use `--no-wox-theme` only for colorful **result** icons.\n- Single-file SDK plugins cannot use relative image paths. Inline the SVG for actions; emoji/URL/base64 are acceptable for result identity only.\n\n### 3) Package and submit plugin\n\n- For SDK plugins cloned from templates, run `make package` inside the template repo.\n- Single-file SDK plugins embed JSON metadata in the file header. Keep `MinWoxVersion` as `\"2.4.2\"`.\n- **Publish a single-file SDK plugin** on a public GitHub gist. That is the simplest store host. Reference: https://gist.github.com/qianlifeng/04a9609de66eaa582a473f5852450ede\n  1. Create one public gist file named `Wox.Plugin.<Name>.js` or `Wox.Plugin.<Name>.py`. The store `DownloadUrl` path must end with `.js` or `.py` (a gist URL without that suffix will not install). Example: `gh gist create --public --desc \"Wox.Plugin.YouTube\" Wox.Plugin.YouTube.js`\n  2. A screenshot of the plugin running in Wox is required. If the user has not provided one, stop and ask for it; do not continue the store submission without it. Use a cropped Wox launcher screenshot that shows the query and the plugin's real results, like https://raw.githubusercontent.com/Wox-launcher/Wox.Plugin.ColorPicker/main/images/screenshot1.png. Do not submit an icon, a README image, source code, or a full-desktop capture. Upload the screenshot and icon to GitHub (drag them onto the gist page or a gist comment). Copy the resulting `https://gist.github.com/user-attachments/assets/<id>` URLs, for example `https://gist.github.com/user-attachments/assets/7502acdc-1ea5-4ef6-a3fb-31875353dabe`.\n  3. Then follow `wox-plugin-submit2store`: clone Wox and add a `store-plugin.json` entry. `Website` is the gist HTML URL, `DownloadUrl` is the gist raw URL including the filename (`https://gist.githubusercontent.com/<user>/<gist-id>/raw/Wox.Plugin.<Name>.js`), `IconUrl` and `ScreenshotUrls` are the user-attachments URLs. Runtime is `nodejs` or `python`. Do not ship a `.wox` for this plugin type.\n- For packaged SDK plugins, use `wox-plugin-submit2store` with a GitHub repository and `.wox` release. Ask the user before submitting to the store. The store entry still requires at least one public screenshot; do not submit while `ScreenshotUrls` is missing or empty.\n\n## Simulated tail tags\n\nPrefer a native `text` tail whenever the label is only text. Wox draws compact rounded rectangles and owns theme, selected-row colors, font rendering, and density scaling. Use at most three tails on one result; additional facts belong in the subtitle, copied text, or a preview.\n\nUse an SVG `image` tail only when an icon and label must share one tag. Match the current native text-tail geometry; do not reuse the old pill shape or outlined capsule examples. At normal density, the logical dimensions are:\n\n| Property | Value |\n| --- | --- |\n| Height | 22 |\n| Corner radius | 4 (`rx=\"4\"`), not half the height |\n| Side inset | 7 on each side; text-only width is measured text width plus 14 |\n| Font | 11, regular weight |\n| Border | None; omit `stroke` |\n| Default | Row foreground text; background uses the same RGB at alpha 13/255, or 24/255 when selected |\n| Success | Fill `#027A48`, label `#FFFFFF` |\n| Danger | Fill `#B42318`, label `#FFFFFF` |\n| Warning | Fill `#B54708`, label `#FFFFFF` |\n\nUse native `TextCategory` / `text_category` for semantic text tails. Status fills remain solid; ordinary metadata has a subtle background. Do not make every secondary fact a status badge just to add color.\n\nFor an icon-and-label SVG, width is `7 + icon width + gap + measured label width + 7`. Set `ImageWidth` to that width and `ImageHeight` to 22, or the launcher defaults to a 20px image slot. For example, a 90-unit tag starts with `<svg viewBox=\"0 0 90 22\" ...><rect width=\"90\" height=\"22\" rx=\"4\" fill=\"#027A48\"/>...`, with no stroke. Keep the image-tail corners consistent with adjacent native tags.\n\nImage tails keep their authored colors; Wox does not automatically apply text-tail selection or theme styling to them. For neutral metadata, prefer native text instead of hardcoding white text on a transparent SVG. If a custom image is necessary, use `GetThemeColors` / `get_theme_colors` to choose readable light/dark colors and include those colors in its cache key. Avoid claiming an SVG matches selected-row styling when the plugin has no selection state.\n\nDraw side-by-side icon labels as filled glyph paths inside the SVG. The SVG rasterizer does not draw general `<text>`. One `<text text-anchor=\"middle\">` whose `x` is the viewBox center is extracted and painted centered on the whole image; it is unsuitable for a label beside an icon because that shifts the intended spacing.\n\n## QueryHint\n\n`QueryHint` is optional semantic background guidance for `input` queries. It can\ncarry actual argument values, but must never turn continuous input into a mandatory\nform. Preserve normal caret movement, cross-element selection, deletion, clipboard,\nundo and IME behavior. Tab is optional. When editing invalidates a semantic boundary,\nkeep the user's text and discard unreliable metadata rather than blocking input.\n\n- Declare suffix elements in `Commands[].QueryHint`; `Aliases` use the same trigger.\n  Wox inserts the matched command prefix with reserved ID `command`. Static metadata\n  and `RegisterQueryCommands` / `register_query_commands` use the same model.\n- `ChangeQuery` always requires `QueryType` and complete `QueryText` for input,\n  or complete `QuerySelection` for selection. `QueryHint` is optional visual\n  enhancement, never a replacement for query content. An input hint must describe\n  exactly the supplied text, including trigger keyword, command, separators and values.\n  An invalid or mismatching hint is ignored; the supplied `QueryText` is used unchanged. Explicit `QueryText: \"\"` remains valid for clearing.\n  Python uses `ChangeQueryParam(query_type=QueryType.INPUT, query_text=\"set volume 50\",\n  query_hint=QueryHint(elements=[...]))`; `QueryHint` and `QueryElement` are SDK exports.\n- Elements have nonempty, unique `Id` values. `text` uses `Text` (including explicit\n  separators); `argument` uses `Value`, optional `Placeholder` and `Required`;\n  `block` uses atomic `Value`. A highlighted argument remains freely editable.\n- Placeholders support `i18n:` and never enter the query value or clipboard.\n  `Required` is descriptive: validate empty values and business constraints before\n  offering or executing actions. Querying itself must not perform the action.\n- Read values by ID from `query.QueryHint.Elements` (Node.js) or\n  `query.query_hint.elements` (Python). Keep legacy `Search` / `search` parsing when\n  the hint is absent; an empty argument is not an absent hint. Wox supplies a lossy\n  plain-text projection in existing query fields; do not reconstruct boundaries from it.\n- Complete commands preview hints; space or Tab activates the template. Whole-command\n  paste into ordinary text is not parsed into arguments. Reopening selects the entire\n  query for replacement; undo and history preserve hints when possible.\n- Keep the list flat; no nested elements, dropdowns, custom rendering or inline markup.\n  Hints never carry plugin identity or create a scope. Routing uses the normal query\n  text and explicit `QueryScope`; complete instances must include the trigger keyword\n  when needed (for example `gh issues `). If both text and a hint are passed to `ChangeQuery`,\n  the explicit query text remains authoritative; the hint must match it.\n- Use SDK or single-file SDK APIs. Verify the first supporting Wox/SDK release before setting\n  distribution requirements; the single-file runtime version floor alone is insufficient.\n- Validate blank/valid/invalid arguments, multiple arguments, whole-query replacement\n  after reopen, undo and the legacy path. Set Volume is the first built-in example.\n\nExample command suffix (Wox adds the command text):\n\n```json\n{\n  \"Command\": \"set-volume\",\n  \"Aliases\": [\"set volume\", \"volume\"],\n  \"QueryHint\": {\n    \"Elements\": [\n      { \"Id\": \"volume\", \"Kind\": \"argument\", \"Placeholder\": \"Volume (0–100)\", \"Required\": true }\n    ]\n  }\n}\n```\n\n## Runtime Requirements\n\nWox enforces the same interpreter floors for SDK plugins and single-file SDK plugins. Store install fails, and queries show a setup result, when the machine is below these versions:\n\n- **Python**: 3.10 or later\n- **Node.js**: 20 or later\n\nDo not target older interpreters. Single-file SDK plugins run inside Wox's existing Python/Node runtime host and require **Wox 2.4.2 or later** (`MinWoxVersion`: `\"2.4.2\"`).\n\n## Resources\n\n- scripts: `scripts/scaffold_wox_plugin.py`, `scripts/detect_local_runtime.py`, `scripts/search_iconify.py`\n- references: `references/plugin_overview.md`, `references/scaffold_nodejs.md`, `references/scaffold_python.md`, `references/sdk_nodejs.md`, `references/sdk_python.md`, `references/plugin_json_schema.md`, `references/settings_patterns.md`, `references/plugin_i18n.md`, `references/icons.md`, `references/refinements.md`, `references/hotkeys.md`, `references/plugin_tools.md`\n- assets: `assets/single_file_plugin_templates/`, `assets/iconify/action/`\n",".agents/skills/wox-changelog-update/SKILL.md":"---\nname: wox-changelog-update\ndescription: Update Wox CHANGELOG.md and CHANGELOG.zh_CN.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.\n---\n\n# Wox Update Changelog\n\n## Overview\n\nUpdate `CHANGELOG.md` and `CHANGELOG.zh_CN.md` from the latest released version to `HEAD` and keep wording, section order, and markdown style consistent with existing entries. The two files must describe the same release with the same structure; only the language of user-facing prose changes.\n\n## Workflow\n\n1. Identify the release boundary.\n\n- Read the top of `CHANGELOG.md` and `CHANGELOG.zh_CN.md` and detect the target section (usually newest version at the top).\n- Detect the last released tag with `git tag --sort=-creatordate`.\n- Use commit range `last_release_tag..HEAD` by default.\n- If changelog heading and git tag disagree, prefer changelog context and state the assumption.\n\n2. Collect candidate changes.\n\n- Run `git log --oneline --no-merges <range>`.\n- Open key commits with `git show --stat --oneline <sha>` to classify user-facing impact.\n- Check whether each included change came through a pull request. Inspect merge commits as well as the non-merge log, and use GitHub's commit-to-PR lookup or PR metadata for squash/rebase merges or unclear local history. Record the PR URL and the contributor's verified GitHub login; use the PR author, not the person who merged it. Do not infer a login from a commit display name or email. If attribution cannot be verified, report that gap instead of guessing or silently omitting it.\n- Ignore pure build/version bump commits unless they change user-visible behavior.\n- Collect store catalog additions separately from app/core commits. Compare `store-plugin.json` and `store-theme.json` at `last_release_tag` vs `HEAD`. A store item is new only when its `Id` (plugin) or `ThemeId` (theme) is absent from the last release file. Ignore version bumps, field edits, and other updates to existing store entries. Ignore bundled script plugin version bumps.\n- Do not put third-party store catalog changes in `Add`, `Improve`, or `Fix`. List only newly added store plugins and themes in `Store`.\n\n3. Classify into changelog buckets.\n\n- `Add`: major, clearly new user-visible capabilities, workflows, plugins, or standalone feature areas.\n- `Improve`: behavioral or UX improvements without new core capability.\n- `Fix`: user-facing bug fixes/regressions.\n- `Store`: plugins and themes newly listed in the Wox store during this range.\n- Omit the `Add` section when the release does not contain a substantial new feature. Prefer `Improve` for additions that extend an existing feature area rather than creating a new user workflow.\n- Omit the `Store` section when no new store plugin or theme IDs appeared in range.\n- Treat platform-specific implementations, provider additions, runtime dependency checks, searchable metadata, theme overrides, and similar support for existing systems as `Improve` unless the commit introduces a large new user-facing feature.\n- Exclude internal refactors/tests/docs/chore unless directly user-visible.\n- Exclude tiny UI-only polish by default (for example spacing, alignment, minor color/wording tweaks) unless it fixes a functional UX issue or the user explicitly asks to include small UI changes.\n\n4. Write changelog entries in repository style.\n\n- Preserve header pattern exactly (for example: `## v2.0.1 -`). Use the same heading, date, screenshots, issue links, and section keys in both files.\n- Keep section titles in English in both files: `- Add`, `- Improve`, `- Fix`, `- Store`. The client already localizes these labels.\n- Add a short highlight paragraph directly below every release heading you create or update, before screenshots and `Add`/`Improve`/`Fix`/`Store` sections. Follow the `v2.4.4` style: one or two short everyday sentences about the visible change, not the implementation. Example: a new Jade theme and Liquid Glass on macOS 26; Settings keep their own look so themes no longer change that window.\n- Write for ordinary users, not developers or reviewers. Describe what someone sees or can do after updating. Do not explain schemas, APIs, caches, indexes, host restarts, platform variants, or other internals unless that is the user-facing name of the feature (for example Liquid Glass, `cb paste`, `.wox`).\n- Prefer plain words over implementation labels: say \"Settings keep their own look\" instead of \"independent chrome\", \"every word must match\" instead of \"AND matching\", \"theme previews match the launcher\" instead of \"schema v2 sparse authoring\".\n- Keep section order: `Add`, `Improve`, `Fix`, `Store`.\n- Use bullet nesting style already used in file.\n- Keep wording concise, everyday, and factual. If a sentence needs a term a typical user would not know, rewrite it or drop that detail.\n- Match wording to the bucket. English `Improve` entries should say \"Improve\", \"Expand\", \"Support\", or similar, not \"Add\", unless the entry is intentionally describing a small added option inside an improvement.\n- For new `Add` features, explain what the feature is for and why a user would use it. Do not reduce major features to one terse implementation phrase.\n- Keep the same feature in one bullet whenever possible. For example, combine Screenshot scrolling capture, pinning, and plugin API changes into one `[`Screenshot`]` bullet instead of splitting them into separate bullets.\n- If a new feature needs screenshots but the images are not available yet, leave clearly named screenshot placeholder image lines in the same bullet so the screenshots can be added later.\n- Prefer plugin/module prefix when clear, e.g. ``[`Shell`]`` or ``[`Clipboard`]``.\n- Write issue references as Markdown links, e.g. `[#4339](https://github.com/Wox-launcher/Wox/issues/4339)`. Do not leave a bare `#4339` for the preview to rewrite later.\n- Every changelog item originating from a PR must credit its contributor with `[@username](https://github.com/username)` and link the PR as `[#1234](https://github.com/Wox-launcher/Wox/pull/1234)`. Apply this to `Add`, `Improve`, `Fix`, and `Store`, with identical attribution in both languages. When a bullet combines contributions from several PRs, credit each relevant PR author once. Keep store author credits; if that author is also the PR contributor, reuse the existing mention, otherwise append the PR contributor separately. For example: ``  - [`Notes`] Fix typing `- [ ] ` not creating a task. [#4618](https://github.com/Wox-launcher/Wox/pull/4618) [@lmgarret](https://github.com/lmgarret)``.\n- Keep existing screenshots. Add new screenshot lines when screenshots already exist, or when a user explicitly asks to reserve screenshot positions for upcoming images.\n- Write `Store` as two nested groups, omitting an empty group: `Plugin` then `Theme`. Each item is already-clickable Markdown: `[Name](page_url) Description [@github_username](https://github.com/github_username)`. Resolve `i18n:` names and descriptions from `I18n.en_US` in `CHANGELOG.md` and from `I18n.zh_CN` in `CHANGELOG.zh_CN.md` (`plugin_name`, `plugin_desc` or `plugin_description`). If a locale is missing, fall back to `en_US`, then `Name` / `Description`. Use `ThemeName` and `Description` for themes. Link the name to `Website` (plugin) or `ThemeUrl` (theme). If that URL is empty, write the plain name without a link. Append the author as a GitHub profile link. Prefer the username from a `github.com` / `gist.github.com` `Website` or `ThemeUrl`; otherwise use `Author` or `ThemeAuthor` when it is a single handle. Skip the author link when the author is only a display name. Do not add store screenshots, download URLs, or version numbers.\n\n  ```markdown\n  - Store\n    - Plugin\n      - [Color Picker](https://github.com/author/wox-plugin-color) Wox plugin to pick colors [@author](https://github.com/author)\n      - [Strava](https://github.com/author/wox-plugin-strava) A plugin to interact with Strava workouts [@author](https://github.com/author)\n    - Theme\n      - [Wox Dracula](https://github.com/author/wox-theme-dracula) Wox theme inspired by the Dracula color scheme [@author](https://github.com/author)\n  ```\n\n- Write the English file first, then produce the Chinese file as a line-for-line counterpart. Do not add or drop bullets in only one language.\n- Both files now contain the full version history. Keep new headings in both files and do not leave a new release in only one language.\n\n5. Keep README in sync only when the latest **stable** heading changes.\n\n- Update the line next to the Release badge to `Latest: vX.Y.Z · Mon YYYY`, matching that heading (for example `Latest: v2.4.3 · Sep 2026`). GitHub README is not generated.\n- Skip this when you only add bullets under an existing heading, or when the newest heading is a beta (`vX.Y.Z-beta.N`).\n- Do not hand-edit `www/docs`. Homepage version text, compare stamps, and `/changelog/*` pages are generated from `CHANGELOG.md` and `CHANGELOG.zh_CN.md` during `docs:dev` / `docs:build`.\n\n6. Validate before finishing.\n\n- Ensure no duplicate bullets.\n- Ensure every `Add`/`Improve`/`Fix` bullet maps to at least one commit in range.\n- Ensure every PR-derived item includes its PR link and verified contributor mention in both languages, including when the same feature combines direct commits and PR contributions. Check merge history or GitHub associations so `--no-merges` does not hide attribution.\n- Ensure every `Store` bullet maps to a plugin `Id` or theme `ThemeId` that is new since `last_release_tag`.\n- Ensure every release section you create or update has a biggest-highlight paragraph under the version heading in both files, written in everyday language a typical user can understand.\n- Reread new bullets as a user: drop leftover implementation terms such as schema, chrome, prefetch, incremental index, DirectWrite, overlay, conversion mode, or host restart unless they are the feature name.\n- Ensure English and Chinese newest sections have the same headings, screenshots, issue links, and bullet count.\n- If the latest stable heading is new or its date changed, ensure README contains `Latest: vX.Y.Z · Mon YYYY` matching it (`docs:build` fails if this line is missing).\n- Ensure markdown renders cleanly and section spacing matches nearby versions.\n- Avoid rewriting old release sections unless explicitly requested.\n- If a commit set only contains tiny UI-only polish, keep it out of changelog by default.\n\n## Command Reference\n\n```bash\ngit tag --sort=-creatordate | head -n 20\nsed -n '1,120p' CHANGELOG.md\nsed -n '1,120p' CHANGELOG.zh_CN.md\ngit log --oneline --no-merges <last_tag>..HEAD\ngit log --oneline --merges <last_tag>..HEAD\ngit show --stat --oneline <sha>\ngit show <last_tag>:store-plugin.json\ngit show <last_tag>:store-theme.json\ngit diff -- CHANGELOG.md CHANGELOG.zh_CN.md\n```\n\nCompare store catalogs by ID, not by file diff hunks. Example:\n\n```bash\npython -c \"\nimport json, subprocess, sys\ntag = sys.argv[1]\ndef load(rev, path):\n    return json.loads(subprocess.check_output(['git', 'show', f'{rev}:{path}']))\nold_p = {p['Id'] for p in load(tag, 'store-plugin.json')}\nnew_p = json.load(open('store-plugin.json', encoding='utf-8'))\nfor p in new_p:\n    if p['Id'] not in old_p:\n        print('plugin', p.get('Name'), p.get('Description'), p.get('Author'), p.get('Website'), p.get('I18n'))\nold_t = {t['ThemeId'] for t in load(tag, 'store-theme.json')}\nnew_t = json.load(open('store-theme.json', encoding='utf-8'))\nfor t in new_t:\n    if t['ThemeId'] not in old_t:\n        print('theme', t.get('ThemeName'), t.get('Description'), t.get('ThemeAuthor'), t.get('ThemeUrl'))\n\" <last_tag>\n```\n\n## Output Rules\n\n- Edit `CHANGELOG.md` and `CHANGELOG.zh_CN.md` together.\n- If the latest stable heading changed, also update the README `Latest: vX.Y.Z · Mon YYYY` line. Do not edit `www/docs` changelog pages or homepage copy.\n- Keep final response short: what section was updated and what categories were changed, including `Store` plugin/theme counts when present.\n- If commit intent is ambiguous, state the assumption briefly in the final response.\n",".agents/skills/wox-theme-creator/SKILL.md":"---\nname: wox-theme-creator\ndescription: Design, create, and refine Wox theme JSON files, including schema v2 base colors, optional styles, transparency, platform overrides, and local debugging. Use for authoring themes or converting an existing theme while preserving its appearance.\n---\n\n# Wox Theme Creator\n\nCreate a deliberately designed theme with a coherent palette, readable states, and a valid authored JSON document. Prefer schema v2 for new themes. Preserve the requested output location and existing theme identity when editing; generate a fresh UUID for a new theme.\n\n## Embedded theme editor\n\nWhen invoked by Wox's theme editor, work on the supplied current draft and editable property list. These are the authoritative available fields. Apply the design guidance below; return only the requested JSON patch of changed properties, preserving unrelated values and theme identity. Do not require repository access, filesystem tools, or a new theme file. The editor validates the patch and handles preview, undo, and saving. A normal AI Chat or repository authoring session continues to use the document workflow below.\n\n## Source of truth\n\nPaths below are relative to the Wox repository root. Read the current implementation before choosing fields; do not invent theme tokens or copy resolved runtime values into a new theme.\n\n- `wox.core/common/theme_schema_v2.go`: complete v2 document, accepted fields, color/geometry defaults, validation, and platform resolution.\n- `wox.core/resource/themes/`: built-in themes as working examples.\n- `wox.core/common/theme_surfaces.go` and `theme_package.go`: image surface declarations, resource validation, and package parsing.\n- `wox.core/common/theme_schema_v1.go`: legacy wire format and behavior, needed when converting an old theme.\n- `wox.core/common/theme_runtime.go` and `theme.go`: independent runtime representation, schema dispatch, and Wox version checks. These are not the authored JSON schema.\n\nEach schema owns its complete document and parser. Missing `SchemaVersion` or historical zero means v1. Loading must not rewrite old files. Changing v2 default semantics would change sparse themes; a new format belongs in a separately registered schema, not a retrofit of v1 or v2.\n\n## Image-backed themes\n\nWox 2.4.4 adds optional image surfaces to schema 2. Existing v1/v2 JSON files,\ncolor defaults, window materials, and Action Panel placement are unchanged.\nUse `MinWoxVersion: \"2.4.4\"` when publishing a theme using these fields.\n\n### Package layout\n\nA `.wox-theme` file is a ZIP archive with `theme.json` at its root, not inside\nan enclosing folder:\n\n```text\nming.wox-theme\n  theme.json\n  assets/lacquer.png\n  assets/palace-frame.png\n  assets/crest.png\n```\n\nOpen the package with Wox, or select the file and invoke Wox's selection query.\nThe installer shows its name and an Install action. Installation validates all\nentries before replacing `<theme-directory>/<ThemeId>/`; failed staging leaves\nthe previous package intact. Plain `<ThemeId>.json` themes remain supported.\nResource-backed themes are excluded from Cloud Sync.\nTheme editor color changes and Save As retain the image declarations and assets.\n\nThe package accepts PNG and JPEG images. Paths are case-sensitive, slash-separated,\nrelative to the package root. Absolute paths, traversal, symlinks, Windows device\nnames, and case-colliding archive entries are rejected. Limits are 128 archive\nentries, 32 MiB uncompressed data, and 16 megapixels across all images. Nine-slice\nsource cuts must leave a nonempty center. Assets for inactive platforms must also\nbe included. No network image URLs or executable theme code are supported.\n\n### Example theme.json\n\n```json\n{\n  \"SchemaVersion\": 2,\n  \"MinWoxVersion\": \"2.4.5\",\n  \"ThemeId\": \"6cf090bd-ef04-44e9-aa61-cbe0e1dc2275\",\n  \"ThemeName\": \"明\",\n  \"BaseBackgroundColor\": \"#721D16\",\n  \"BaseTextColor\": \"#FFF0CA\",\n  \"BaseAccentColor\": \"#F4C453\",\n  \"AppBackgroundColor\": \"transparent\",\n  \"OverlayBackgroundColor\": \"#721D16\",\n  \"OverlayFontColor\": \"#FFF0CA\",\n  \"Surfaces\": {\n    \"App\": {\n      \"ContentInsets\": {\"Top\": 110, \"Right\": 48, \"Bottom\": 32, \"Left\": 48},\n      \"Background\": {\n        \"Source\": \"assets/lacquer.png\",\n        \"Mode\": \"tile\",\n        \"Size\": {\"Width\": 128, \"Height\": 128}\n      },\n      \"Frame\": {\n        \"Source\": \"assets/palace-frame.png\",\n        \"Mode\": \"nineSlice\",\n        \"Slice\": {\"Top\": 160, \"Right\": 96, \"Bottom\": 96, \"Left\": 96},\n        \"Insets\": {\"Top\": 80, \"Right\": 48, \"Bottom\": 48, \"Left\": 48}\n      },\n      \"Decorations\": [{\n        \"Source\": \"assets/crest.png\",\n        \"Anchor\": \"topCenter\",\n        \"Offset\": {\"X\": 0, \"Y\": 0},\n        \"Size\": {\"Width\": 120, \"Height\": 110}\n      }]\n    },\n    \"ActionContainer\": {\n      \"Background\": {\"Source\": \"assets/lacquer.png\", \"Mode\": \"tile\"}\n    }\n  }\n}\n```\n\n### Surface contract\n\n`InnerShadow` optionally shades inward over child fills to make a panel appear\nrecessed into its frame. It accepts `Color`, `Width` (0..64 logical units),\n`Radius` and `Insets` (each 0..4096). Insets locate the inner panel relative to\nthe surface; match App ContentInsets and AppContentBorderRadius for an inset\nlauncher. For example: `\"InnerShadow\": {\"Color\":\"rgba(25,42,55,0.25)\",\n\"Width\":7,\"Radius\":10,\"Insets\":{\"Top\":29,\"Right\":29,\"Bottom\":29,\"Left\":29}}`.\nThe shadow fades to transparent inward, follows display density, and allocates\nno image cache. Keep its width within the content padding so text stays clear.\nIt paints after children, unlike image layers; omit it to preserve existing\nappearance. This optional schema 2 extension requires Wox 2.4.5.\n\nThe supported regions are `App`, `QueryBox`, `ResultItemActive`,\n`ActionContainer`, `Preview`, and `Toolbar`. Each accepts the same optional\n`Background`, `Frame`, and `Decorations` declarations. The generic preview shell\nis supported; embedded web/native content and specialized previews still own\ntheir inner rendering.\n\nLayers draw in this order: existing color/material, Background, Frame,\nDecorations, existing borders, interactive contents. Images do not introduce\nhit targets. Transparent image pixels reveal the underlying fill; they do not\nerase it. Author a transparent App background and custom chrome explicitly when\nneeded. AppBorder fields still disable the OS material as before. Native\narbitrary-shape input regions are not part of this extension.\n\n`Background` and `Frame` accept these modes:\n\n| Mode        | Geometry                                                                                             |\n| ----------- | ---------------------------------------------------------------------------------------------------- |\n| `stretch`   | Scale the image to the surface bounds.                                                               |\n| `tile`      | Repeat at `Size` logical units; if absent, use the image's pixel dimensions as logical units.        |\n| `nineSlice` | Cut at `Slice` source pixels, draw borders at `Insets` logical units, stretch the remaining regions. |\n\nStretch and tiled images follow the surface corner radius. Nine-slice images\nretain their authored alpha silhouette; put rounded corners in the asset.\nFour corners retain their destination size unless the surface is too small,\nin which case opposing borders shrink proportionally. A frame's center is\nalso drawn, so use a transparent center when only an outline is wanted.\nTiled backgrounds retain only their latest raster size, at the active display's\nphysical pixel density, capped by the asset's authored density. Moving between\ndisplays rebuilds this cache; `Size` remains in logical units. The limit is 16\nmegapixels per background; larger requests use the existing color fallback.\nNine-slice textures are likewise derived at display density from the shared\ndecoded source: borders and repeated tiles are downsampled to their logical\nsize times the display scale (never upsampled), while an axis that stretches\nto the surface keeps its source pixels. Only the latest display scale is\ncached per surface.\nReuse the same `Source` for shared textures: decoded pixels are shared across\nsurfaces, while each surface keeps its own size cache. PNG file size is not its\nmemory cost: decoded RGBA uses roughly width × height × 4 bytes, plus raster\nand native renderer caches. Use reasonably sized texture tiles.\n\nDecorations require `Source`, `Anchor`, and a positive logical `Size`; `Offset`\ndefaults to zero. Anchors are `topLeft`, `topCenter`, `topRight`, `centerLeft`,\n`center`, `centerRight`, `bottomLeft`, `bottomCenter`, and `bottomRight`.\nOffsets are in logical units and decorations stay clipped to their owner.\nDecorations are static and do not change control layout.\n\nOnly `App` accepts `ContentInsets`. These add to the existing uniform\n`AppContentInset`, outside the inner content panel and existing `AppPadding`.\nThey reserve space for the entire launcher body, including the Toolbar and\nAction Panel. Frame insets do not implicitly add layout padding.\n\nPlatform and variant `Surfaces` objects merge **by region**. A supplied region\nreplaces that region's whole declaration; omitted regions inherit. Set a region\nto `null` to remove it, or `Surfaces: null` to remove every inherited surface.\nExisting scalar platform override semantics are unchanged.\n\n```json\n{\n  \"windows\": {\"Surfaces\": {\"Toolbar\": null}},\n  \"linux\": {\"Surfaces\": null}\n}\n```\n\nThere is no separate package format version; the schema version belongs to\n`theme.json`.\n\nFloating overlays (text notifications, tooltips, image preview, timer, dictation,\nand permission prompts) are not the launcher window. When `Surfaces` uses an\nimage, set `OverlayBackgroundColor` and `OverlayFontColor` explicitly.\nImage-backed themes usually leave `AppBackgroundColor` transparent so the frame\nasset is the window; overlays have no frame, so that transparent color lets the\ndesktop show through and the text becomes unreadable. Use an opaque fill that\nmatches the readable content surface, and a text color that contrasts with it.\nDo not copy the transparent window color. Omitted overlay colors follow the\neffective `AppBackgroundColor` and `ActionItemFontColor`, which is correct only\nfor themes whose window fill is already a readable wash. These fields do not\nrecolor the launcher, Notes, or WebView windows. Authoring them requires Wox\n2.4.5.\n\n## Author the document\n\n### Localized name and description\n\nSchema v2 supports optional inline `I18n`, using the same locale-to-key map as\nplugin.json. Set `ThemeName` and `Description` to `i18n:` keys:\n\n```json\n{\n  \"ThemeName\": \"i18n:theme_name\",\n  \"Description\": \"i18n:theme_description\",\n  \"I18n\": {\n    \"en_US\": {\"theme_name\": \"Ming\", \"theme_description\": \"An imperial red and gold theme.\"},\n    \"zh_CN\": {\"theme_name\": \"明\", \"theme_description\": \"朱红与金黄的皇家主题。\"}\n  }\n}\n```\n\nProvide `en_US` as fallback, plus the intended languages (`zh_CN`, `ru_RU`,\n`pt_BR`, `ko_KR`, `ja_JP`). Missing translations fall back to English, then\nWox's built-in translations, then the original key. Literal text stays literal.\nTranslations are resolved for display and search; saved JSON retains the keys\nand translation map. `I18n` belongs at the root, not in platform overrides.\nThis extension uses schema 2 and requires Wox 2.4.4. Theme translations currently\nuse inline `I18n`; separate `lang/` files are not loaded.\n\nA minimal v2 document looks like this; replace the sample ID and name:\n\n```json\n{\n  \"SchemaVersion\": 2,\n  \"MinWoxVersion\": \"2.4.3\",\n  \"ThemeId\": \"66288aad-d3fa-493b-bc46-7e8e7280c40d\",\n  \"ThemeName\": \"Jade\",\n  \"BaseBackgroundColor\": \"rgba(28, 35, 37, 0.72)\",\n  \"BaseTextColor\": \"#E5ECE9\",\n  \"BaseAccentColor\": \"#70D6A6\"\n}\n```\n\nThe three base colors, ID, and name are required. Explicitly declare schema 2. Set `MinWoxVersion` to the release supporting the features used; check current built-ins rather than lowering the floor to make installation succeed. `Version` is the theme's own version, separate from schema and minimum Wox versions. Include truthful author, description, and URL metadata when available. Do not mark a custom theme as system-installed. Automatic appearance themes use `IsAutoAppearance`, `DarkThemeId`, and `LightThemeId`; their required base colors still provide a fallback.\n\nGroup overrides by surface: window, query/Glance/Attention, result container/items, Action Panel/items/query, preview/tags, toolbar/keycaps. Keep the document sparse; add overrides for intentional design differences.\n\n| Authored value                            | Meaning                                                  |\n| ----------------------------------------- | -------------------------------------------------------- |\n| Missing optional style                    | Inherit parent, or schema default at the root            |\n| `null` at the root                        | Same as omitted: schema default                          |\n| `null` on a platform or variant           | Clear the inherited value and restore the schema default |\n| Integer `0`                               | Explicit zero; never substitute a default                |\n| `transparent` or alpha zero               | Explicit transparency                                    |\n| Empty color, negative/fractional geometry | Invalid                                                  |\n\nColors accept `#RRGGBB`, `#RRGGBBAA` (alpha last), `rgb(r,g,b)`, `rgba(r,g,b,a)`, and `transparent`. RGB channels are 0–255; alpha is 0–1. Geometry uses logical units, not physical screen pixels.\n\nFont sizes are controlled by the application Interface size setting; do not add theme font-size overrides.\n\n## Default window shape and transparency\n\nUnless the user explicitly requests a custom app outline or window corners, omit `AppBorderColor`, `AppBorderWidth`, and `AppBorderRadius` at the root and all platform/variant levels. Do not infer a custom window outline or radius from a reference screenshot or a general request for a rounded visual style. Keep the system/default window shape and use a slightly translucent `AppBackgroundColor` by default (for example, alpha 0.90).\n\nIf the user explicitly requests a custom app outline or window corners, author the requested `AppBorder*` fields and default `AppBackgroundColor` to fully opaque (alpha 1). An explicit request for transparency or opacity overrides that default. QueryBox, result, preview, and Action Panel corner settings do not count as a request for custom window chrome. Toolbar and Action Panel may retain modest in-app translucency in either case.\n\nThese are theme-authoring defaults, not changes to schema parsing. Apply them when creating themes or when the user asks to restyle an existing theme; do not silently rewrite other existing themes. Keep `BaseBackgroundColor` independent when an explicit app background override is sufficient, so changing window alpha does not unintentionally change every derived surface.\n\n## Design the surfaces together\n\nStart with background, text, and accent roles. Optional colors derive independently from these roles; changing one optional token does not change another. Base alpha also affects derived colors. Consult the resolver for exact defaults instead of duplicating its entire catalog here.\n\n- For translucent themes, consider app, query, Action Panel, action query, preview, and toolbar backgrounds together. An opaque surface can hide translucency beneath it; layered alpha and native materials affect the final appearance.\n- V2 `AppContentInset` reserves a uniform logical inset around the entire launcher content, including the toolbar, previews, and floating panels. `AppContentBackgroundColor` paints the inner panel and `AppContentBorderRadius` rounds its background. Defaults are 0, transparent, and 0, preserving existing themes. These fields do not select custom window chrome: use a translucent `AppBackgroundColor` and omit `AppBorder*` to expose a native-material rim. Existing `AppPadding*` remains spacing inside the content panel. Child surfaces retain their own corner styles; the toolbar follows the panel's bottom corners.\n- Floating overlays use `OverlayBackgroundColor` and `OverlayFontColor`. Omitted values follow the effective `AppBackgroundColor` and `ActionItemFontColor`. They do not change the launcher, Notes, or WebView windows. Image-backed themes must set both explicitly; see Image-backed themes.\n- Set `ResultContainerPaddingTop` and `ResultContainerPaddingBottom` to the same value, normally 8, so the result list matches the built-in themes. The schema default is top 8 and bottom 0, so write both fields explicitly; omitting the bottom padding does not produce a matching gutter. Keep left and right at 0 unless a side inset is part of the design. Leave an existing theme's values unchanged unless that spacing is being authored.\n- V2 uses `ResultItemActiveIndicatorColor`, `ResultItemActiveIndicatorWidth`, `ResultItemActiveIndicatorInsetLeft`, `ResultItemActiveIndicatorInsetTop`, `ResultItemActiveIndicatorInsetBottom`, and `ResultItemActiveIndicatorBorderRadius` for the selected-result marker. Width defaults to 0, color to the base accent, and insets/radius to 0. Zero insets/radius reproduce the edge strip; use positive insets and radius for a short rounded marker. Reserve icon space with result-item padding; marker geometry does not shift content. The unreleased v2 `ResultItemActiveBorderLeftWidth/Color` fields were removed; v1 keeps its original fields. Check normal, selected, and hovered rows separately; `ResultItemHoverBackgroundColor` controls hover.\n- `QuerySeparatorColor`, `QuerySeparatorThickness`, `QuerySeparatorPaddingLeft`, and `QuerySeparatorPaddingRight` draw the line under the query. Thickness is the stroke size in logical pixels; omitted thickness draws nothing. Left and right padding inset the line from the window edges, and omitted padding runs it across the window. The line does not follow the query box corner radius.\n- Action Panel border fields are `ActionContainerBorderColor`, `ActionContainerBorderWidth`, and `ActionContainerBorderRadius`. `ActionContainerDividerColor` controls internal separators independently of `PreviewSplitLineColor`.\n- Toolbar primary actions (default/bare Enter) support `ToolbarPrimaryFontColor` and `ToolbarPrimaryHotkey{Font,Background,Border}Color`. Omitted values inherit the corresponding effective toolbar colors; explicit transparency is preserved. Configure emphasis here rather than relying on automatic dimming of other actions.\n- Keycaps have three independent v2 groups: `ToolbarHotkey{Font,Background,Border}Color`, `ActionItemHotkey{Font,Background,Border}Color`, and `ActionItemActiveHotkey{Font,Background,Border}Color`. All accept explicit transparency. Omitted values derive from base colors, not another surface's overrides: normal text uses secondary text and border uses divider; active text/border use base text; backgrounds default transparent. Set active colors explicitly for contrasting selection backgrounds (for example, white keycaps on blue). The unreleased shared `Hotkey*` fields were removed. Keep keycaps readable without competing with labels.\n- `PreviewBorderRadius` and `PreviewTagBorderRadius` control generic preview and metadata-tag corners in logical units. Omitted values retain 8; zero is square.\n- Preview has `PreviewBackgroundColor`, `PreviewBorderColor`, existing text/property/selection colors, and `PreviewTagFontColor`, `PreviewTagBackgroundColor`, `PreviewTagBorderColor`. Generic preview tokens do not necessarily control specialized chat, terminal, media, or native/web surfaces.\n- Glance has `GlanceFontColor`, `GlanceIconColor`, `GlanceBackgroundColor`, and `GlanceHoverBackgroundColor`. Raster images retain their own colors.\n- Attention has `AttentionFontColor`, `AttentionIconColor`, `AttentionBackgroundColor`, `AttentionBorderColor`, `AttentionHoverBackgroundColor`, and `AttentionHoverBorderColor`. Omitted values match Glance: transparent idle fill/border and a query-text hover wash. Raster images retain their own colors.\n- Shared scrollbars expose `ScrollbarThumbColor`, `ScrollbarThumbHoverColor`, `ScrollbarThumbActiveColor`, `ScrollbarWidth`, `ScrollbarHoverWidth`, and `ScrollbarBorderRadius`. Widths default to 3/7 logical units; omitted radius follows half the animated thickness. Zero width/radius and transparent colors are explicit. Horizontal bars use width as thickness. Native/web-owned scrollbars remain outside this contract.\n- Filters use `RefinementButton{Font,Icon,Background,Border,HoverBackground}Color` and their `RefinementButtonActive...Color` counterparts. Active means expanded or a non-default filter is applied. The expanded strip uses `Refinement{Background,Border,Title,Divider,Hotkey}Color`; options use `RefinementItem{Font,Background,HoverBackground}Color` and `RefinementItemActive...Color`. These are JSON overrides; preserve explicit alpha for every state, including selected-hovered options. Control dimensions remain launcher-density geometry.\n- `AppBorderColor`, `AppBorderWidth`, and `AppBorderRadius` control launcher outer chrome. Width and radius use logical units. Zero width disables the outline. Zero radius is an explicit square corner for the painted outline. Omitted fields keep the previous platform behavior. Set width explicitly when designing an outline. If any one of these three fields is authored, every platform disables system window material (Windows Acrylic, macOS Liquid Glass/vibrancy, Linux compositor blur) so Go UI can paint the outline. Windows applies a DPI-scaled region plus DirectComposition clip only when a radius is authored, including 0; color or width alone leaves DWM's default corners. macOS detaches the glass/vibrancy wrapper and clips the renderer layer to the authored radius, but the launcher stays a titled window, so AppKit still masks the window and its shadow to the system corner radius. `AppBorderRadius: 0` therefore cannot produce fully square corners on macOS. Linux turns compositor blur off and paints the authored radius, including 0. Result, query, preview, and Action Panel radii are in-app geometry and can be square. Theme-color alpha still controls ordinary window transparency. Verify shadow and transparency on each target OS before promising identical results.\n\n## Explain the custom-chrome tradeoff\n\nWhen creating, editing, or recommending a theme that authors any of `AppBorderColor`, `AppBorderWidth`, or `AppBorderRadius`, explicitly tell the user that this disables system window material on every platform (Acrylic, Liquid Glass, Linux compositor blur). The native window switches to transparent composition; theme-color alpha controls ordinary window transparency. This does not disable Wox's own in-app frosted-glass surfaces. Include this limitation in the delivery message, not only in JSON or internal notes.\n\nToolbar and Action Panel retain their application-rendered frosted-glass transparency independently of the native window material. When designing custom-chrome themes, consider modest transparency in `ToolbarBackgroundColor` and `ActionContainerBackgroundColor` (for example, alpha around 0.88–0.90), while keeping text readable. Do not make these surfaces opaque merely because custom window chrome is enabled. An opaque `AppBackgroundColor` can remain intentional: these panels reveal or blur underlying app content, not the desktop through that opaque background.\n\nAn explicit zero (`AppBorderWidth: 0` or `AppBorderRadius: 0`) also selects this path. To restore system material, omit all three fields. A child platform or variant can restore material after a parent outline by setting those fields to `null`; that clears the inherited chrome instead of painting a square window. Assigning a default-looking number does not restore the material. Background colors still need alpha below 1 to reveal anything underneath.\n\nSuggested user-facing wording: “主题只要设置了 AppBorderColor、AppBorderWidth 或 AppBorderRadius 中的任意一项，所有平台都不会再使用系统窗口材质（Windows Acrylic、macOS Liquid Glass、Linux 合成器模糊）。窗口改用普通透明合成，透明程度由主题颜色的 Alpha 决定。Toolbar 和 Action Panel 的应用内磨玻璃效果仍保留，可以适度保留透明度。若要恢复系统材质，需要移除这三项配置。子级平台或变体可以把这三项设为 null，用来取消父级圆角/描边并重新打开系统材质。”\n\nWhen `AppBorderRadius` is 0 at the root or on `macos`, including an explicit request for square window corners, also tell the user about the macOS window-shape limit in that same delivery message. Do not attach this warning to a positive radius, or to square result, query, preview, or Action Panel corners.\n\nSuggested user-facing wording: “在 macOS 上，启动器窗口外形和阴影仍由系统标题栏窗口决定。AppBorderRadius 设为 0 只会让 Wox 按直角绘制内容，系统仍会把窗口裁成圆角，无法得到完全直角。”\n\n## Platform overrides and compatibility\n\nResolution order is root authored values, then `windows`/`macos`/`linux`, then that platform's matching `variants` entry, then defaults. Read `theme_platform.go` for supported variant names. Omitted platform fields inherit the parent. JSON `null` on a platform or variant clears the inherited value so the schema default applies; this is how Hyprland can keep compositor blur after a shared Linux `AppBorderRadius`. Base colors may be overridden so dependent defaults derive from the effective palette. All platform variants are validated, including inactive ones.\n\nPreserve authored values and platform nodes when editing or saving. Never flatten a resolved platform theme into the source document. When explicitly converting v1, retain its effective appearance with explicit v2 overrides where defaults differ; verify zero values, aliases, and legacy contextual color behavior rather than only changing `SchemaVersion`.\n\n## Deliver and check\n\nFor local debugging, use the user's requested path; the normal user theme directory is `~/.wox/wox-user/themes/`. Use `<ThemeId>.json` for a plain color theme. For image-backed themes, deliver a `.wox-theme` package containing root `theme.json` and its assets; installed packages live under `<ThemeId>/`. Do not overwrite an unrelated theme or publish to the store as part of local authoring.\n\nValidate JSON and use Wox's actual parser/resolver to check fields, colors, platform nodes, and version compatibility. Existing checks live in `wox.core/common/theme_v2_test.go` and `theme_document_test.go`; for changes to parsing run `go test -tags 'sqlite_fts5,wox_automation' ./common` from `wox.core`. That suite validates the implementation, not an arbitrary new file: load the authored file through Wox or a focused parser check as well.\n\nWhen a running preview is available, inspect selected/hovered results, the Action Panel, keycaps, toolbar, preview/tags, and Glance. For transparency, compare against light and dark desktop content. Report which platforms were actually observed; do not claim native material behavior from a static JSON check.\n\nResource-backed themes are local-only for now: Cloud Sync skips their install, update, deletion, and snapshot payloads. Ordinary JSON themes continue to sync. Share image themes using the `.wox-theme` file.\n\n## Resizable frames: stretch versus repeat\n\nSchema v2 nine-slice images accept optional `\"Repeat\": {\"X\": \"tile\", \"Y\": \"stretch\"}`.\nEach omitted axis defaults to `stretch`; accepted values are `stretch` and `tile`.\n`Repeat` is invalid on whole-image `stretch` or `tile` modes. Existing declarations are unchanged.\n\nCorners retain their authored logical Insets. X controls the top/bottom middle strips;\nY controls the left/right middle strips. The center follows both axes. Tiling starts\nat the left/top of each slice; the final partial tile is clipped, never squeezed.\nTop/bottom tile width equals source strip width multiplied by actual logical strip\nheight divided by source strip height. Left/right tile height uses the corresponding\nwidth ratio. The center uses the first positive Insets/Slice ratio in Top, Bottom,\nLeft, Right order (or 1 if all are zero). Keep these ratios consistent for a uniform\nmaterial density. DPI is applied by the renderer; do not multiply Insets by display scale.\nVery small windows shrink opposing borders proportionally. A pathological slice that\nwould require more than 4096 tile draws falls back to stretching that slice; avoid tiny\nrepeat units and verify the maximum supported window size.\n\nUse stretching for flat fills and simple straight rules, tiling for roof tiles, woven\npatterns, rivets or bamboo, and fixed-size Decorations for crests, lettering and figures.\nNine-slice does not turn an arbitrary illustration into a seamless material. The full\nmiddle strip is the repeat unit: its two ends must match in height, color, lighting,\nalpha and motif phase. Do not include isolated statues in it. Keep curved-to-straight\ntransitions entirely within fixed corner slices; put cut lines only in straight,\nregular sections and preserve tangent continuity. Corners and adjacent strips need\nmatching scale as well as matching pixels. Inspect the join at both ends, not only\nrepeat-to-repeat seams. A clipped final motif can meet the far corner at a different\nphase; prefer a neutral join or a fixed decorative cap where this would be visible.\n\nFor an irregular Action/About panel, set ActionContainerBackgroundColor and its border\ncolor to transparent, remove the separate rectangular Background image, and provide\nan opaque interior inside a transparent-exterior Frame. This also skips the rectangular\nfloating material. Leave padding for the ornaments. App ContentInsets reserve draggable\nouter chrome; controls remain inside the reserved content bounds.\n\nVerify minimum, default and wide launcher widths, short and tall result lists, fractional\nDPI (125%, 150%), fixed crest proportions, partial tiles, alpha silhouette, and Action/\nAbout content clearance. Check the actual rendered UI before claiming seamless joins;\nimage generation and parser validation alone cannot establish that.\n",".agents/skills/wox-test-ensurance/SKILL.md":"---\nname: wox-test-ensurance\ndescription: Use when the user invokes Wox test assurance or asks to run Wox tests; direct invocation is explicit permission to execute the current core, Go UI unit, and native smoke suites and fix failures until they pass.\n---\n\n# Wox Test Ensurance\n\n## Overview\n\nDrive Wox test assurance from the repository root until the core tests, headless Go UI tests, and native Go UI smoke tests 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.\n\n## Invocation Contract\n\nIf this skill is explicitly invoked, the user has already authorized the complete Wox test assurance workflow: `make test`, `make test-go-ui-unit`, and `make smoke`. Do not stop after summarizing a plan or ask for extra confirmation.\n\nIf the user asks for one exact command, such as `make test`, run only that requested command and fix its failures. Do not silently expand an exact command request into native UI smoke testing.\n\nUse the active Wox checkout containing the root `Makefile` and `wox.core` directory. Do not assume a fixed drive or checkout path.\n\n## Preflight\n\nBefore running the suite, ensure no local Wox instance or VS Code-launched Wox debug process from the active checkout is still running. Force-stop matching processes; stale processes can hold ports or keep old state alive, and native smoke tests must own the Wox process they exercise.\n\nUse a Windows PowerShell check like this from the repository root:\n\n```powershell\n$repo = (Resolve-Path \".\").Path\n$woxProcesses = Get-CimInstance Win32_Process | Where-Object {\n    $name = $_.Name\n    $cmd = $_.CommandLine\n    $exe = $_.ExecutablePath\n    $isWoxBinary = $name -in @(\"Wox.exe\", \"wox.exe\", \"wox.core.exe\", \"__debug_bin.exe\")\n    $isWoxDebug = $name -in @(\"dlv.exe\", \"__debug_bin.exe\") -and $cmd -like \"*$repo*\"\n    $isRepoRuntime = ($exe -like \"$repo*\") -and ($name -like \"*wox*\")\n    $isWoxBinary -or $isWoxDebug -or $isRepoRuntime\n}\n$woxProcesses | ForEach-Object { Stop-Process -Id $_.ProcessId -Force }\n```\n\nIf stopped processes are found, mention them briefly in the working update or final summary.\n\n## Workflow\n\n1. Confirm the current directory is the Wox repository root, then begin without asking whether to run tests.\n2. Run the preflight process cleanup and force-stop any matching Wox/runtime debug process.\n3. Run `make test` for the core integration suite.\n4. Run `make test-go-ui-unit` for retained-widget, automation-contract, launcher, and driver tests. This suite does not open a native window.\n5. Run `make smoke` for the real single-process Go UI. On headless Linux, set `GO_UI_SMOKE_RUNNER=\"xvfb-run -a\"`.\n6. For each failure, capture the package or smoke case, test name, command output, and relevant logs, then investigate and fix the root cause.\n7. After any fix, format only the files touched according to Wox project style, then rerun the affected command.\n8. Before claiming completion, rerun every command required by the invocation contract from the repository root. Smoke cases may be targeted while diagnosing, but explicit test assurance ends with the complete `make smoke` suite.\n\n## Failure Triage\n\nPrefer this order:\n\n1. Check whether recent implementation changes broke product behavior, API contracts, async ordering, platform handling, or persisted state.\n2. Inspect the failing test's intended behavior and compare it with the current product contract.\n3. Fix production code when the test exposes a real regression.\n4. Change an existing test only when evidence shows the product behavior is correct and the assertion/setup is outdated, flaky, or testing the wrong layer.\n5. Do not add new tests unless the user explicitly asks for new test coverage.\n\nUse targeted reruns only while narrowing a failure. They are not final proof. The final proof is every suite required by the invocation contract passing.\n\n## Wox-Specific Notes\n\n- Wox runs in mixed Windows and WSL environments. Verify the shell, path, and repo root before treating a runner failure as a code failure.\n- If a shell shim or external tool prevents the real command from starting, isolate the environment problem, use the closest repo runner only for diagnosis, and do not report success until the requested `make` command passes.\n\n## Completion Checklist\n\n- Every command required by the invocation contract passed from the Wox repository root.\n- Explicit test assurance includes successful `make test`, `make test-go-ui-unit`, and `make smoke` runs.\n- Any code or test edits are locally formatted with the relevant project formatter.\n- The final response includes the exact commands run and whether they passed.\n",".agents/skills/wox-visual-style/SKILL.md":"---\nname: wox-visual-style\ndescription: Design, implement, refactor, or review the visual style of Wox's portable Go UI under wox.core/ui. Use for Settings, dialogs, forms, tables, catalogs, management pages, shared Wox controls, typography, semantic colors, spacing, alignment, icons, control sizing, and default, hover, pressed, selected, focused, disabled, loading, empty, and error states. Also use to audit visual consistency or decide whether appearance belongs in launcher/component or launcher/view. Treat the Launcher query surface and Action Panel as explicit special contracts instead of forcing the ordinary Settings control-size system onto them.\n---\n\n# Wox Visual Style\n\nApply one coherent visual language to Wox Go UI without changing business behavior accidentally.\n\n## Load the visual contract\n\nRead [references/visual-style-guide.md](references/visual-style-guide.md) completely before designing, reviewing, or editing UI. Treat it as the sole visual policy for Wox Go UI. Treat production components and tests as implementation evidence; when they disagree with the guide, report or fix the implementation drift instead of silently redefining the guide from current code.\n\nKeep the guide at the level of cross-feature design principles and shared control conventions. Record feature-specific colors, dimensions, theme-field behavior, and bug-fix rationale in the owning code, tests, or domain documentation instead of appending them to the guide.\n\nAlso read the repository `AGENTS.md`, `README.md`, `Wox.code-workspace`, and `wox.core/ui/README.md` before refactors.\n\n## Classify the surface\n\nClassify the requested surface before applying size rules:\n\n- Apply the ordinary control system to Settings, dialogs, forms, tables, catalogs, onboarding management controls, and other application-management pages.\n- Keep the Launcher query, its accessories, results, toolbar, refinements, Glance, and Attention under launcher density and theme geometry.\n- Keep the complete Action Panel, including its filter and rows, under its own geometry contract.\n- Scale every interface element's text, line box, and the control that holds that text with `UiDensity`. Keep normal-density bases in `typography.go` and multiply them at draw time with `ControlTheme.Scaled` or the launcher density scale. Do not bake the current density into those bases, and do not multiply a size that was already scaled.\n- Keep native window controls and platform-owned dialogs under the platform contract.\n\nDo not use a special-surface exception to justify page-local styling elsewhere.\n\n## Inspect the current contract\n\n1. Inspect the nearest shared `Wox*` component and its focused tests.\n2. Inspect `launcher/component/wox_theme.go`, `launcher/component/typography.go`, and `launcher/theme.go` when colors or type are involved.\n3. Inspect relevant views for repeated literals, primitive interactive controls, and inconsistent state handling.\n4. Check whether the same semantic control exists on other production pages.\n5. Record current values separately from target values when auditing known drift.\n\nUseful focused searches include:\n\n```bash\nrg -n 'Wox(Button|TextField|Dropdown|Checkbox|Switch|IconButton)' wox.core/ui/launcher\nrg -n 'woxwidget\\.Gesture\\{' wox.core/ui/launcher/view\nrg -n 'TextStyle\\{Size:|Height:|Radius:|Color: woxui\\.Color' wox.core/ui/launcher/view\nrg -n 'BorderWidth: [0-9]+\\.|Radius: [0-9]+\\.|LineHeight: [0-9]+\\.|TextStyle\\{Size: [0-9]+\\.[0-9]' wox.core/ui/launcher\n```\n\nInterpret results in context. Primitive gestures are valid for page-specific pointer regions and tooltips; they are a defect when they recreate a reusable control contract.\n\n## Design or review the change\n\n1. Identify each element's semantic role, size tier, visual state, and alignment group.\n2. Use semantic theme roles and shared typography instead of raw colors or page-local type scales.\n3. Use the ordinary 32-unit control height only inside its defined scope. Preserve special Launcher and Action Panel geometry. Author only whole logical units for size, padding, gap, radius, border, font size, and line height.\n4. Align controls by interaction frame and centerline. Preserve the internal geometry of checkboxes and switches.\n5. Cover every applicable state from the state matrix, including non-color cues and accessibility semantics.\n6. Prefer an existing catalog name from `wox/common/icons` via `icons.Get`; add a new semantic name there before introducing a local asset. For theme-adaptive SVG paints, use `var(--wox-theme-icon-color)` explicitly; follow the SVG theme-color contract in [Components, icons, and content](references/visual-style-guide.md#components-icons-and-content).\n7. Check light and dark themes, long or translated text, narrow widths, scrolling, logical units, DPI boundaries, and disabled/error content.\n\nExpress alignment through layout primitives first: use `Align`, Flex main/cross-axis alignment, `Expanded`, or `Constrained` to center and place controls. Do not hand-calculate offsets such as `(rowHeight-controlHeight)/2`, or use padding as a substitute for alignment; improve the owning layout/component boundary when the existing primitives cannot express the relationship.\n\nWhen reviewing only, report concrete violations with the owning layer and recommended shared fix. Do not mutate files unless the user requested implementation.\n\n## Implement at the correct layer\n\n- Put reusable geometry, appearance, pointer states, focus treatment, and accessibility in `launcher/component`.\n- Keep page hierarchy, responsive composition, and genuinely page-specific spacing in `launcher/view`.\n- Keep mutable interaction state below `launcher.App` and preserve `widget.Boundary.Build` purity.\n- Centralize stable metrics used by multiple production surfaces. Do not add a token for a single local constraint.\n- Keep ordinary control size explicit through shared defaults or a semantic size API; do not copy the same height into call sites.\n- Keep Launcher and Action Panel metrics independent so ordinary component changes cannot alter their geometry accidentally.\n- Prefer layout components over manual alignment math. Center controls with `Align` or Flex alignment and reserve padding for actual content insets, not positional compensation.\n- Add English intent comments only for non-obvious visual constraints or exceptions.\n\nPreserve existing behavior unless the request includes interaction changes. A visual refactor must not alter values, callbacks, focus order, IME ownership, keyboard activation, scrolling, or window lifecycle.\n\n## Validate proportionally\n\n1. Format changed Go files with `gofmt`.\n2. Run the narrowest affected component and view tests from `wox.core`.\n3. Run `GOCACHE=/tmp/wox-go-cache make test-go-ui-unit` from the repository root when shared components, widget behavior, or broad launcher UI changed.\n4. Add focused source tests for size tiers, alignment, states, semantics, and special-surface isolation.\n5. Review the diff for duplicated literals and accidental Launcher or Action Panel changes.\n\nSource inspection is the default. Request permission before launching Wox for runtime comparison unless the user already requested it. Escalate to serial screenshots when font measurement, DPI, animation, clipping, compositing, native focus, or platform rendering leaves a meaningful visual ambiguity.\n\n## Report completion\n\nReport:\n\n- surface classification and size tier;\n- shared component or view ownership;\n- visual states covered;\n- known implementation drift found or fixed;\n- formatting and tests actually run;\n- whether validation was source-only or included an approved runtime comparison.\n","AGENTS.md":"# AI Agent Protocol & Instructions\n\nPath: `AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/AGENTS.md)","store-plugin.json":"# Plugin Plugin Manifest\n\nPath: `store-plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/store-plugin.json)",".agents/skills/wox-blog/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-blog/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/agents/openai.yaml)",".agents/skills/wox-blog/assets/article-template.md":"# Assets Skill\n\nPath: `.agents/skills/wox-blog/assets/article-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/assets/article-template.md)",".agents/skills/wox-blog/references/cover-style.md":"# References Skill\n\nPath: `.agents/skills/wox-blog/references/cover-style.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/references/cover-style.md)",".agents/skills/wox-blog/references/writing-style.md":"# References Skill\n\nPath: `.agents/skills/wox-blog/references/writing-style.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/references/writing-style.md)",".agents/skills/wox-changelog-update/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-changelog-update/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-changelog-update/agents/openai.yaml)",".agents/skills/wox-commit/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-commit/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-commit/agents/openai.yaml)",".agents/skills/wox-cpu-debug/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-cpu-debug/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-cpu-debug/agents/openai.yaml)",".agents/skills/wox-generate-smoke-test-case/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-generate-smoke-test-case/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-generate-smoke-test-case/agents/openai.yaml)",".agents/skills/wox-i18n/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-i18n/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-i18n/agents/openai.yaml)",".agents/skills/wox-memory-debug/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-memory-debug/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-memory-debug/agents/openai.yaml)",".agents/skills/wox-plugin-creator/references/hotkeys.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/hotkeys.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/hotkeys.md)",".agents/skills/wox-plugin-creator/references/html_preview_updates.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/html_preview_updates.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/html_preview_updates.md)",".agents/skills/wox-plugin-creator/references/icons.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/icons.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/icons.md)",".agents/skills/wox-plugin-creator/references/plugin_i18n.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/plugin_i18n.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_i18n.md)",".agents/skills/wox-plugin-creator/references/plugin_json_schema.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/plugin_json_schema.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_json_schema.md)",".agents/skills/wox-plugin-creator/references/plugin_overview.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/plugin_overview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_overview.md)",".agents/skills/wox-plugin-creator/references/plugin_tools.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/plugin_tools.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_tools.md)",".agents/skills/wox-plugin-creator/references/refinements.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/refinements.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/refinements.md)",".agents/skills/wox-plugin-creator/references/scaffold_nodejs.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/scaffold_nodejs.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/scaffold_nodejs.md)",".agents/skills/wox-plugin-creator/references/scaffold_python.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/scaffold_python.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/scaffold_python.md)",".agents/skills/wox-plugin-creator/references/sdk_nodejs.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/sdk_nodejs.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/sdk_nodejs.md)",".agents/skills/wox-plugin-creator/references/sdk_python.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/sdk_python.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/sdk_python.md)",".agents/skills/wox-plugin-creator/references/settings_patterns.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/settings_patterns.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/settings_patterns.md)",".agents/skills/wox-plugin-submit2store/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-plugin-submit2store/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-submit2store/agents/openai.yaml)",".agents/skills/wox-plugin-submit2store/references/store-plugin-entry.md":"# References Skill\n\nPath: `.agents/skills/wox-plugin-submit2store/references/store-plugin-entry.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-submit2store/references/store-plugin-entry.md)",".agents/skills/wox-test-ensurance/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-test-ensurance/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-test-ensurance/agents/openai.yaml)",".agents/skills/wox-visual-style/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/wox-visual-style/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-visual-style/agents/openai.yaml)",".agents/skills/wox-visual-style/references/visual-style-guide.md":"# References Skill\n\nPath: `.agents/skills/wox-visual-style/references/visual-style-guide.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-visual-style/references/visual-style-guide.md)","www/docs/guide/plugins/system/application.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/application.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/application.md)","www/docs/guide/plugins/system/backup.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/backup.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/backup.md)","www/docs/guide/plugins/system/browser-bookmark.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/browser-bookmark.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/browser-bookmark.md)","www/docs/guide/plugins/system/browser.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/browser.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/browser.md)","www/docs/guide/plugins/system/calculator.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/calculator.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/calculator.md)","www/docs/guide/plugins/system/chat.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/chat.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/chat.md)","www/docs/guide/plugins/system/clipboard.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/clipboard.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/clipboard.md)","www/docs/guide/plugins/system/cloudsync.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/cloudsync.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/cloudsync.md)","www/docs/guide/plugins/system/color.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/color.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/color.md)","www/docs/guide/plugins/system/converter.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/converter.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/converter.md)","www/docs/guide/plugins/system/doctor.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/doctor.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/doctor.md)","www/docs/guide/plugins/system/emoji.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/emoji.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/emoji.md)","www/docs/guide/plugins/system/explorer.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/explorer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/explorer.md)","www/docs/guide/plugins/system/feedback.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/feedback.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/feedback.md)","www/docs/guide/plugins/system/file.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/file.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/file.md)","www/docs/guide/plugins/system/folder.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/folder.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/folder.md)","www/docs/guide/plugins/system/hotkey-overview.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/hotkey-overview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/hotkey-overview.md)","www/docs/guide/plugins/system/mediaplayer.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/mediaplayer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/mediaplayer.md)","www/docs/guide/plugins/system/query-history.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/query-history.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/query-history.md)","www/docs/guide/plugins/system/shell.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/shell.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/shell.md)","www/docs/guide/plugins/system/sys.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/sys.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/sys.md)","www/docs/guide/plugins/system/theme.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/theme.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/theme.md)","www/docs/guide/plugins/system/update.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/update.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/update.md)","www/docs/guide/plugins/system/url.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/url.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/url.md)","www/docs/guide/plugins/system/websearch.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/websearch.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/websearch.md)","www/docs/guide/plugins/system/webview.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/webview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/webview.md)","www/docs/guide/plugins/system/wpm.md":"# System Skill\n\nPath: `www/docs/guide/plugins/system/wpm.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/wpm.md)","www/docs/zh/guide/plugins/system/application.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/application.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/application.md)","www/docs/zh/guide/plugins/system/backup.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/backup.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/backup.md)","www/docs/zh/guide/plugins/system/browser-bookmark.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/browser-bookmark.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/browser-bookmark.md)","www/docs/zh/guide/plugins/system/browser.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/browser.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/browser.md)","www/docs/zh/guide/plugins/system/calculator.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/calculator.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/calculator.md)","www/docs/zh/guide/plugins/system/chat.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/chat.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/chat.md)","www/docs/zh/guide/plugins/system/clipboard.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/clipboard.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/clipboard.md)","www/docs/zh/guide/plugins/system/cloudsync.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/cloudsync.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/cloudsync.md)","www/docs/zh/guide/plugins/system/color.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/color.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/color.md)","www/docs/zh/guide/plugins/system/converter.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/converter.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/converter.md)","www/docs/zh/guide/plugins/system/doctor.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/doctor.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/doctor.md)","www/docs/zh/guide/plugins/system/emoji.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/emoji.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/emoji.md)","www/docs/zh/guide/plugins/system/explorer.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/explorer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/explorer.md)","www/docs/zh/guide/plugins/system/feedback.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/feedback.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/feedback.md)","www/docs/zh/guide/plugins/system/file.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/file.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/file.md)","www/docs/zh/guide/plugins/system/folder.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/folder.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/folder.md)","www/docs/zh/guide/plugins/system/hotkey-overview.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/hotkey-overview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/hotkey-overview.md)","www/docs/zh/guide/plugins/system/mediaplayer.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/mediaplayer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/mediaplayer.md)","www/docs/zh/guide/plugins/system/query-history.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/query-history.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/query-history.md)","www/docs/zh/guide/plugins/system/shell.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/shell.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/shell.md)","www/docs/zh/guide/plugins/system/sys.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/sys.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/sys.md)","www/docs/zh/guide/plugins/system/theme.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/theme.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/theme.md)","www/docs/zh/guide/plugins/system/update.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/update.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/update.md)","www/docs/zh/guide/plugins/system/url.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/url.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/url.md)","www/docs/zh/guide/plugins/system/websearch.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/websearch.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/websearch.md)","www/docs/zh/guide/plugins/system/webview.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/webview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/webview.md)","www/docs/zh/guide/plugins/system/wpm.md":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/wpm.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/wpm.md)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AI Agent Protocol & Instructions\n\nPath: `AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/AGENTS.md)","tokens":300,"sizeBytes":150},{"name":"openai.yaml","path":".agents/skills/wox-blog/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `.agents/skills/wox-blog/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/agents/openai.yaml)","tokens":300,"sizeBytes":196},{"name":"article-template.md","path":".agents/skills/wox-blog/assets/article-template.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/assets/article-template.md","title":"Assets Skill","category":"anthropic-skill","format":"markdown","content":"# Assets Skill\n\nPath: `.agents/skills/wox-blog/assets/article-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/assets/article-template.md)","tokens":300,"sizeBytes":212},{"name":"cover-style.md","path":".agents/skills/wox-blog/references/cover-style.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/references/cover-style.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/wox-blog/references/cover-style.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/references/cover-style.md)","tokens":300,"sizeBytes":214},{"name":"writing-style.md","path":".agents/skills/wox-blog/references/writing-style.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/references/writing-style.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/wox-blog/references/writing-style.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/references/writing-style.md)","tokens":300,"sizeBytes":218},{"name":"SKILL.md","path":".agents/skills/wox-blog/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/SKILL.md","title":"wox-blog","category":"anthropic-skill","format":"markdown","content":"---\nname: wox-blog\ndescription: Create or revise Wox blog articles with practical workflows, paired English and Chinese Markdown, and consistent illustrated covers. Use for Wox blog writing and editorial standards, not release changelogs or general documentation.\n---\n\n# Wox Blog\n\nWrite for people using Wox: one concrete task, its useful outcome, and enough detail to reproduce it. Support product stories and engineering articles when requested; practical tips and workflows are the default.\n\n## Establish the facts\n\n- Read relevant feature documentation and implementation before describing commands, setting labels, defaults, or platform support. Distinguish released behavior from development-only changes; do not imply unreleased features are available in the current release.\n- Inspect nearby articles and `www/docs/.vitepress/theme/components/blog.data.mts` for the metadata contract. Do not turn a blog request into an app feature change.\n- For existing articles, preserve the slug, publication date, and useful media unless the request explicitly changes them.\n\n## Write the article pair\n\n- Read [the writing style guide](references/writing-style.md) before drafting or substantially rewriting. It contains the Mole sample analysis, Wox-specific examples, and an editorial review. Borrow explanatory techniques rather than copying an author's voice.\n- Default to English in `www/docs/blog/<slug>.md` and Simplified Chinese in `www/docs/zh/blog/<slug>.md`, using the same slug, date, category, and cover. Honor explicit single-language requests.\n- Use [the article template](assets/article-template.md) for frontmatter and a starting point, replacing every template token. It is not a mandatory outline.\n- Choose a specific title about a task or benefit. Avoid a repeated “Did You Know” / “你知道吗” prefix, exaggerated claims, and generic introductions. The description should add useful context rather than repeat the title.\n- Develop the situation, a concrete example, the reason for consequential settings, and the observable result as needed. Use connected prose for the explanation and steps for actions. Add useful context where an article feels thin; do not pad it with adjectives, repeated benefits, or a mandatory FAQ/conclusion. Keep length and structure proportional to the task.\n- Use a calm, conversational voice with specific nouns and verbs. Do not fabricate personal experience, measured improvements, user quotations, or test results to make the writing lively. Keep card descriptions compact; put the fuller explanation in the body.\n- Translate naturally. Keep commands, setting semantics, platform constraints, and outcomes equivalent across languages. Make frontmatter `title` match the article H1.\n- New articles use the actual publication date in `YYYY-MM-DD`. Use a stable descriptive kebab-case slug; omit the legacy `did-you-know-` prefix for new articles.\n\n## Supply card metadata and a cover\n\nRequired frontmatter: `title`, `description`, `date`, `category`, `cover`, and `coverAlt`.\n\n| Category ID | English label | Chinese label |\n| --- | --- | --- |\n| `workspace` | Windows & apps | 窗口与应用 |\n| `preview` | Files & previews | 文件与预览 |\n| `automation` | Shortcuts & automation | 快捷键与自动化 |\n| `product` | Inside Wox | Wox 动态 |\n\nChoose the closest category. Add a category only when the article genuinely falls outside these themes, updating loader validation and both localized labels in `BlogIndex.vue` together.\n\n- The default cover style is the approved flat illustration family: front-facing 2D shapes, thin charcoal-blue outlines, pale gray backgrounds, muted blue/sage/peach accents, and generous whitespace. Avoid clay-like 3D materials, bevels, thick keys, perspective, and heavy shadows. Use no text or logos in covers.\n- Read [the cover style reference](references/cover-style.md) when creating or replacing a cover. Use the built-in image generation tool for original illustrations; inspect an existing cover as a style reference when useful.\n- Save selected images under `www/docs/public/images/blog/` and reference `/images/blog/<name>.webp` (or the actual image extension). Localize `coverAlt` concisely.\n- Covers express the topic, not evidence of product behavior. Preserve real screenshots and videos in the body. Never substitute generated mock UI for factual screenshots.\n- When a real Wox product screenshot is needed but unavailable, continue drafting with a descriptive text placeholder at the intended position, such as `> Screenshot needed: Wox workspace settings showing the saved window layout on Windows.` Specify the screen, relevant state or action, and what the image should demonstrate; use the article language. Do not create an image link to a nonexistent file. At delivery, notify the user and list the article locations and screenshots they need to supply. These intentional screenshot placeholders may remain in the draft; they do not block completing the text and local validation.\n- If image generation is unavailable, finish text preparation and report the missing cover. Do not leave broken references or silently switch to a different medium.\n- The homepage discovers Markdown automatically and sorts by date, then URL. Do not manually add links to the blog indexes or hard-code cards.\n\n## Verify and deliver\n\n- Run the editorial pass in the writing guide: check that the reader can recognize the situation, follow the example, and tell what success looks like; remove unsupported claims and repeated filler.\n- Check both languages, links, actual asset paths, metadata, and claims against the source feature. Preserve existing URLs when revising.\n- From `www`, run `pnpm docs:build`; run `git diff --check` from the repository root.\n- Verify the article appears on its language homepage with its cover, complete title, and correct date. Inspect article media and the card at desktop and mobile widths.\n- Report article paths and verification limits. Default to local files and local verification; do not commit, push, or deploy unless requested.\n","frontmatter":{"name":"wox-blog","description":"Create or revise Wox blog articles with practical workflows, paired English and Chinese Markdown, and consistent illustrated covers. Use for Wox blog writing and editorial standards, not release changelogs or general documentation."},"isInternal":false,"tokens":1231,"sizeBytes":6070},{"name":"openai.yaml","path":".agents/skills/wox-changelog-update/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-changelog-update/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `.agents/skills/wox-changelog-update/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-changelog-update/agents/openai.yaml)","tokens":300,"sizeBytes":220},{"name":"SKILL.md","path":".agents/skills/wox-changelog-update/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-changelog-update/SKILL.md","title":"wox-changelog-update","category":"anthropic-skill","format":"markdown","content":"---\nname: wox-changelog-update\ndescription: Update Wox CHANGELOG.md and CHANGELOG.zh_CN.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.\n---\n\n# Wox Update Changelog\n\n## Overview\n\nUpdate `CHANGELOG.md` and `CHANGELOG.zh_CN.md` from the latest released version to `HEAD` and keep wording, section order, and markdown style consistent with existing entries. The two files must describe the same release with the same structure; only the language of user-facing prose changes.\n\n## Workflow\n\n1. Identify the release boundary.\n\n- Read the top of `CHANGELOG.md` and `CHANGELOG.zh_CN.md` and detect the target section (usually newest version at the top).\n- Detect the last released tag with `git tag --sort=-creatordate`.\n- Use commit range `last_release_tag..HEAD` by default.\n- If changelog heading and git tag disagree, prefer changelog context and state the assumption.\n\n2. Collect candidate changes.\n\n- Run `git log --oneline --no-merges <range>`.\n- Open key commits with `git show --stat --oneline <sha>` to classify user-facing impact.\n- Check whether each included change came through a pull request. Inspect merge commits as well as the non-merge log, and use GitHub's commit-to-PR lookup or PR metadata for squash/rebase merges or unclear local history. Record the PR URL and the contributor's verified GitHub login; use the PR author, not the person who merged it. Do not infer a login from a commit display name or email. If attribution cannot be verified, report that gap instead of guessing or silently omitting it.\n- Ignore pure build/version bump commits unless they change user-visible behavior.\n- Collect store catalog additions separately from app/core commits. Compare `store-plugin.json` and `store-theme.json` at `last_release_tag` vs `HEAD`. A store item is new only when its `Id` (plugin) or `ThemeId` (theme) is absent from the last release file. Ignore version bumps, field edits, and other updates to existing store entries. Ignore bundled script plugin version bumps.\n- Do not put third-party store catalog changes in `Add`, `Improve`, or `Fix`. List only newly added store plugins and themes in `Store`.\n\n3. Classify into changelog buckets.\n\n- `Add`: major, clearly new user-visible capabilities, workflows, plugins, or standalone feature areas.\n- `Improve`: behavioral or UX improvements without new core capability.\n- `Fix`: user-facing bug fixes/regressions.\n- `Store`: plugins and themes newly listed in the Wox store during this range.\n- Omit the `Add` section when the release does not contain a substantial new feature. Prefer `Improve` for additions that extend an existing feature area rather than creating a new user workflow.\n- Omit the `Store` section when no new store plugin or theme IDs appeared in range.\n- Treat platform-specific implementations, provider additions, runtime dependency checks, searchable metadata, theme overrides, and similar support for existing systems as `Improve` unless the commit introduces a large new user-facing feature.\n- Exclude internal refactors/tests/docs/chore unless directly user-visible.\n- Exclude tiny UI-only polish by default (for example spacing, alignment, minor color/wording tweaks) unless it fixes a functional UX issue or the user explicitly asks to include small UI changes.\n\n4. Write changelog entries in repository style.\n\n- Preserve header pattern exactly (for example: `## v2.0.1 -`). Use the same heading, date, screenshots, issue links, and section keys in both files.\n- Keep section titles in English in both files: `- Add`, `- Improve`, `- Fix`, `- Store`. The client already localizes these labels.\n- Add a short highlight paragraph directly below every release heading you create or update, before screenshots and `Add`/`Improve`/`Fix`/`Store` sections. Follow the `v2.4.4` style: one or two short everyday sentences about the visible change, not the implementation. Example: a new Jade theme and Liquid Glass on macOS 26; Settings keep their own look so themes no longer change that window.\n- Write for ordinary users, not developers or reviewers. Describe what someone sees or can do after updating. Do not explain schemas, APIs, caches, indexes, host restarts, platform variants, or other internals unless that is the user-facing name of the feature (for example Liquid Glass, `cb paste`, `.wox`).\n- Prefer plain words over implementation labels: say \"Settings keep their own look\" instead of \"independent chrome\", \"every word must match\" instead of \"AND matching\", \"theme previews match the launcher\" instead of \"schema v2 sparse authoring\".\n- Keep section order: `Add`, `Improve`, `Fix`, `Store`.\n- Use bullet nesting style already used in file.\n- Keep wording concise, everyday, and factual. If a sentence needs a term a typical user would not know, rewrite it or drop that detail.\n- Match wording to the bucket. English `Improve` entries should say \"Improve\", \"Expand\", \"Support\", or similar, not \"Add\", unless the entry is intentionally describing a small added option inside an improvement.\n- For new `Add` features, explain what the feature is for and why a user would use it. Do not reduce major features to one terse implementation phrase.\n- Keep the same feature in one bullet whenever possible. For example, combine Screenshot scrolling capture, pinning, and plugin API changes into one `[`Screenshot`]` bullet instead of splitting them into separate bullets.\n- If a new feature needs screenshots but the images are not available yet, leave clearly named screenshot placeholder image lines in the same bullet so the screenshots can be added later.\n- Prefer plugin/module prefix when clear, e.g. ``[`Shell`]`` or ``[`Clipboard`]``.\n- Write issue references as Markdown links, e.g. `[#4339](https://github.com/Wox-launcher/Wox/issues/4339)`. Do not leave a bare `#4339` for the preview to rewrite later.\n- Every changelog item originating from a PR must credit its contributor with `[@username](https://github.com/username)` and link the PR as `[#1234](https://github.com/Wox-launcher/Wox/pull/1234)`. Apply this to `Add`, `Improve`, `Fix`, and `Store`, with identical attribution in both languages. When a bullet combines contributions from several PRs, credit each relevant PR author once. Keep store author credits; if that author is also the PR contributor, reuse the existing mention, otherwise append the PR contributor separately. For example: ``  - [`Notes`] Fix typing `- [ ] ` not creating a task. [#4618](https://github.com/Wox-launcher/Wox/pull/4618) [@lmgarret](https://github.com/lmgarret)``.\n- Keep existing screenshots. Add new screenshot lines when screenshots already exist, or when a user explicitly asks to reserve screenshot positions for upcoming images.\n- Write `Store` as two nested groups, omitting an empty group: `Plugin` then `Theme`. Each item is already-clickable Markdown: `[Name](page_url) Description [@github_username](https://github.com/github_username)`. Resolve `i18n:` names and descriptions from `I18n.en_US` in `CHANGELOG.md` and from `I18n.zh_CN` in `CHANGELOG.zh_CN.md` (`plugin_name`, `plugin_desc` or `plugin_description`). If a locale is missing, fall back to `en_US`, then `Name` / `Description`. Use `ThemeName` and `Description` for themes. Link the name to `Website` (plugin) or `ThemeUrl` (theme). If that URL is empty, write the plain name without a link. Append the author as a GitHub profile link. Prefer the username from a `github.com` / `gist.github.com` `Website` or `ThemeUrl`; otherwise use `Author` or `ThemeAuthor` when it is a single handle. Skip the author link when the author is only a display name. Do not add store screenshots, download URLs, or version numbers.\n\n  ```markdown\n  - Store\n    - Plugin\n      - [Color Picker](https://github.com/author/wox-plugin-color) Wox plugin to pick colors [@author](https://github.com/author)\n      - [Strava](https://github.com/author/wox-plugin-strava) A plugin to interact with Strava workouts [@author](https://github.com/author)\n    - Theme\n      - [Wox Dracula](https://github.com/author/wox-theme-dracula) Wox theme inspired by the Dracula color scheme [@author](https://github.com/author)\n  ```\n\n- Write the English file first, then produce the Chinese file as a line-for-line counterpart. Do not add or drop bullets in only one language.\n- Both files now contain the full version history. Keep new headings in both files and do not leave a new release in only one language.\n\n5. Keep README in sync only when the latest **stable** heading changes.\n\n- Update the line next to the Release badge to `Latest: vX.Y.Z · Mon YYYY`, matching that heading (for example `Latest: v2.4.3 · Sep 2026`). GitHub README is not generated.\n- Skip this when you only add bullets under an existing heading, or when the newest heading is a beta (`vX.Y.Z-beta.N`).\n- Do not hand-edit `www/docs`. Homepage version text, compare stamps, and `/changelog/*` pages are generated from `CHANGELOG.md` and `CHANGELOG.zh_CN.md` during `docs:dev` / `docs:build`.\n\n6. Validate before finishing.\n\n- Ensure no duplicate bullets.\n- Ensure every `Add`/`Improve`/`Fix` bullet maps to at least one commit in range.\n- Ensure every PR-derived item includes its PR link and verified contributor mention in both languages, including when the same feature combines direct commits and PR contributions. Check merge history or GitHub associations so `--no-merges` does not hide attribution.\n- Ensure every `Store` bullet maps to a plugin `Id` or theme `ThemeId` that is new since `last_release_tag`.\n- Ensure every release section you create or update has a biggest-highlight paragraph under the version heading in both files, written in everyday language a typical user can understand.\n- Reread new bullets as a user: drop leftover implementation terms such as schema, chrome, prefetch, incremental index, DirectWrite, overlay, conversion mode, or host restart unless they are the feature name.\n- Ensure English and Chinese newest sections have the same headings, screenshots, issue links, and bullet count.\n- If the latest stable heading is new or its date changed, ensure README contains `Latest: vX.Y.Z · Mon YYYY` matching it (`docs:build` fails if this line is missing).\n- Ensure markdown renders cleanly and section spacing matches nearby versions.\n- Avoid rewriting old release sections unless explicitly requested.\n- If a commit set only contains tiny UI-only polish, keep it out of changelog by default.\n\n## Command Reference\n\n```bash\ngit tag --sort=-creatordate | head -n 20\nsed -n '1,120p' CHANGELOG.md\nsed -n '1,120p' CHANGELOG.zh_CN.md\ngit log --oneline --no-merges <last_tag>..HEAD\ngit log --oneline --merges <last_tag>..HEAD\ngit show --stat --oneline <sha>\ngit show <last_tag>:store-plugin.json\ngit show <last_tag>:store-theme.json\ngit diff -- CHANGELOG.md CHANGELOG.zh_CN.md\n```\n\nCompare store catalogs by ID, not by file diff hunks. Example:\n\n```bash\npython -c \"\nimport json, subprocess, sys\ntag = sys.argv[1]\ndef load(rev, path):\n    return json.loads(subprocess.check_output(['git', 'show', f'{rev}:{path}']))\nold_p = {p['Id'] for p in load(tag, 'store-plugin.json')}\nnew_p = json.load(open('store-plugin.json', encoding='utf-8'))\nfor p in new_p:\n    if p['Id'] not in old_p:\n        print('plugin', p.get('Name'), p.get('Description'), p.get('Author'), p.get('Website'), p.get('I18n'))\nold_t = {t['ThemeId'] for t in load(tag, 'store-theme.json')}\nnew_t = json.load(open('store-theme.json', encoding='utf-8'))\nfor t in new_t:\n    if t['ThemeId'] not in old_t:\n        print('theme', t.get('ThemeName'), t.get('Description'), t.get('ThemeAuthor'), t.get('ThemeUrl'))\n\" <last_tag>\n```\n\n## Output Rules\n\n- Edit `CHANGELOG.md` and `CHANGELOG.zh_CN.md` together.\n- If the latest stable heading changed, also update the README `Latest: vX.Y.Z · Mon YYYY` line. Do not edit `www/docs` changelog pages or homepage copy.\n- Keep final response short: what section was updated and what categories were changed, including `Store` plugin/theme counts when present.\n- If commit intent is ambiguous, state the assumption briefly in the final response.\n","frontmatter":{"name":"wox-changelog-update","description":"Update Wox CHANGELOG.md and CHANGELOG.zh_CN.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."},"isInternal":false,"tokens":2853,"sizeBytes":12212},{"name":"openai.yaml","path":".agents/skills/wox-commit/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-commit/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `.agents/skills/wox-commit/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-commit/agents/openai.yaml)","tokens":300,"sizeBytes":200},{"name":"SKILL.md","path":".agents/skills/wox-commit/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-commit/SKILL.md","title":"wox-commit","category":"anthropic-skill","format":"markdown","content":"---\nname: wox-commit\ndescription: Generate a repository-style commit message from the current Wox working tree without modifying the repository. Use when the user asks for a commit message or explicitly invokes `$wox-commit`.\n---\n\n# Wox Commit Message\n\n## Contract\n\nTreat explicit invocation as permission to inspect the current Wox diff and generate a commit message only. Do not stage, commit, amend, push, or otherwise modify the repository.\n\n## Workflow\n\n1. Read the repository instructions and inspect `git status --short`, the unstaged and staged diffs, and relevant untracked files.\n2. Infer every distinct behavior change from the actual diff and recent commit style. Do not ask the user to pick one feature when several unrelated changes are present.\n3. Prefer `type(scope): imperative summary` for normal code changes; use the repository's established wording for automated, release, or store updates.\n4. Always return both a subject and a body in one copy-ready block.\n\n## Message Rules\n\n- Describe the reason or behavior change, not a file list.\n- Keep the subject specific, imperative, and free of trailing punctuation.\n- Choose the narrowest accurate scope already used by nearby commits. When the tree spans unrelated areas, omit a misleading narrow scope rather than picking one feature.\n- Use `feat`, `fix`, `refactor`, `docs`, `test`, `build`, or `chore` only when it matches the diff.\n- Cover every distinct change in the same message. Unrelated features still belong in one subject-plus-body: name each behavior so a reviewer can see all of them without reading the file list.\n- When one change dominates, put it in the subject and name the others in the body. When two or more are peer features, name both in the subject if they fit; otherwise use a broader subject and give each change its own sentence in the body.\n- Always write a body that expands the why or the non-obvious behavior. One or two sentences is enough for a single change; use one short sentence per distinct change when the tree contains more than one. Do not leave the body empty.\n- Do not run formatting, tests, hooks, or other validation; the caller has already completed validation before requesting the message.\n\n## Completion\n\nReturn exactly one fenced text block the user can copy as a full commit message: subject, a blank line, then the body. After the block, add a brief note only if the diff is empty. Do not claim that a commit was created.\n\n```text\ntype(scope): imperative summary\n\nBody that explains the why or the non-obvious behavior.\n```\n","frontmatter":{"name":"wox-commit","description":"Generate a repository-style commit message from the current Wox working tree without modifying the repository. Use when the user asks for a commit message or explicitly invokes `$wox-commit`."},"isInternal":false,"tokens":533,"sizeBytes":2545},{"name":"openai.yaml","path":".agents/skills/wox-cpu-debug/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-cpu-debug/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `.agents/skills/wox-cpu-debug/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-cpu-debug/agents/openai.yaml)","tokens":300,"sizeBytes":206},{"name":"SKILL.md","path":".agents/skills/wox-cpu-debug/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-cpu-debug/SKILL.md","title":"wox-cpu-debug","category":"anthropic-skill","format":"markdown","content":"---\nname: wox-cpu-debug\ndescription: Measure CPU usage, attribute CPU hotspots, and optimize them without materially increasing Go or native memory in the real single-process Wox Go UI. Use for continuous-query CPU regressions, high idle or hidden CPU, plugin/query hot paths, renderer or native platform activity, background work that continues after hide, and comparisons of Go pprof data with macOS or Windows process samples.\n---\n\n# Wox CPU Debug\n\n## Goal\n\nRun the real Wox debug build with `wox_automation`, warm the same process, replay deterministic queries, and measure query-active and hidden CPU independently. Use Go CPU profiles for Go ownership and OS process/native samples for whole-process behavior. Keep profilers in separate identical runs so one profiler does not distort another.\n\n## Run the Debug Build\n\n### macOS\n\n1. Stop every other Wox instance.\n2. Start the real debug build under Delve:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\nWOX_AUTOMATION_INFO_FILE=/tmp/wox-cpu-automation.json /Users/qianlifeng/go/bin/dlv debug . --build-flags=-tags=sqlite_fts5,wox_automation\n```\n\n3. Run `continue`, wait for startup and plugin initialization, and record the debuggee PID.\n4. Keep this PID alive and running normally for the complete comparison. Never sample Delve or `debugserver` instead of the debuggee.\n\nBuild the automation workload once before measuring so Go compilation is outside every CPU window:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\ngo build -o /tmp/wox-cpu-workload ../.agents/skills/wox-cpu-debug/scripts/run-cpu-workload.go\n```\n\n### Windows\n\nStart Delve headlessly so the real debuggee can run normally while measurements execute from another PowerShell process:\n\n```powershell\ncd D:\\dev\\Wox\\wox.core\nNew-Item -ItemType Directory -Force .tmp\\cpu-debug | Out-Null\n$env:WOX_AUTOMATION_INFO_FILE = \"D:\\dev\\Wox\\wox.core\\.tmp\\cpu-debug\\automation.json\"\n$env:CGO_ENABLED = \"1\"\n$delve = Start-Process -FilePath (Get-Command dlv).Source `\n  -ArgumentList @(\"debug\", \".\", \"--headless\", \"--listen=127.0.0.1:43001\", \"--api-version=2\", \"--accept-multiclient\", \"--continue\", \"--build-flags=-tags=sqlite_fts5,wox_automation\", \"--output=D:\\dev\\Wox\\wox.core\\.tmp\\cpu-debug\\__debug_bin_wox.exe\") `\n  -WorkingDirectory (Get-Location).Path -WindowStyle Hidden -PassThru\n```\n\nWait for `automation.json`, then identify the `__debug_bin_wox.exe` child PID. Never sample either Delve process:\n\n```powershell\nwhile (-not (Test-Path $env:WOX_AUTOMATION_INFO_FILE)) { Start-Sleep -Milliseconds 100 }\nGet-CimInstance Win32_Process |\n  Where-Object { $_.ParentProcessId -eq $delve.Id -and $_.Name -eq \"__debug_bin_wox.exe\" } |\n  Select-Object ProcessId, ParentProcessId, Name, CommandLine\n```\n\nBuild the workload once before warm-up:\n\n```powershell\ngo build -o .tmp\\cpu-debug\\wox-cpu-workload.exe ..\\.agents\\skills\\wox-cpu-debug\\scripts\\run-cpu-workload.go\n```\n\nKeep the same debuggee PID alive through warm-up and every before/after comparison. When finished, stop only the exact debuggee and Delve PIDs created by this run.\n\n## Warm the Process\n\nRun a 15-second mixed-query block, hide the launcher, and wait 10 seconds:\n\n```bash\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode queries -duration 15s -seed 1\nsleep 10\n```\n\nWarm-up absorbs startup, application indexing, font loading, icon decoding, and lazy caches. Restarting Wox after warm-up invalidates the comparison.\n\nOn Windows, use the corresponding `.exe` and PowerShell sleep command:\n\n```powershell\n& .tmp\\cpu-debug\\wox-cpu-workload.exe -info .tmp\\cpu-debug\\automation.json -mode queries -duration 15s -seed 1\nStart-Sleep -Seconds 10\n```\n\n## Measure Query Latency\n\nUse the workload's `latency` mode for query responsiveness. The `queries` mode only\nchecks input updates and drives CPU activity; its fixed waits are not latency samples.\nBuild the workload before measuring, then warm the same process with 40 completed\nqueries and measure a deterministic sequence:\n\n```powershell\n& .tmp\\cpu-debug\\wox-cpu-workload.exe -info .tmp\\cpu-debug\\automation.json -mode latency -query-count 40 -seed 1 -output .tmp\\cpu-debug\\warmup.json\n& .tmp\\cpu-debug\\wox-cpu-workload.exe -info .tmp\\cpu-debug\\automation.json -mode latency -query-count 160 -seed 11 -output .tmp\\cpu-debug\\latency.json\n```\n\nThe report contains raw per-query samples and nearest-rank p50/p95 for input\ndispatch to the first current result in the retained semantics frame, and to the\ncompleted result frame. Polling is every 5 ms plus RPC/scheduling overhead; these\nare client-observed UI-frame timings, not native presentation or icon-decode\ncompletion timings. Queries with no results contribute only to completion latency.\nEach query has a 10-second timeout; a failed run is invalid and must not contribute\npartial samples to the aggregate. Compare query families as well as aggregate p95.\n\n`perf.query_state` correlates the query generation, result ownership, input value,\nand retained row IDs, so an older retained result or completion cannot satisfy the\nmeasurement. `-mode stats` reads PID, effective GOMAXPROCS, Go heap allocation,\nGo retained memory (`Sys - HeapReleased`), stack allocation, and MemProfileRate\nwithout showing Wox or forcing GC.\n\nWhen comparing startup GOMAXPROCS policies, use a fresh process for each arm,\nwith identical isolated settings, warm-up, query sequence, and GOGC. Preserve each\nPID through that run's warm-up and measurements. Alternate arm order across at\nleast three pairs. Do not compile, run tests, or run another profiler during a\nmeasurement window. Collect process CPU in separate `queries` windows, recording\ncompleted query counts, then sample memory at 45 seconds after hide so both staged\nrelease deadlines have passed. Keep private working set, total working set, private\ncommitted bytes, and Go retained memory distinct. Repeat decisive measurements in\nan optimized production-configured build, where development heap profiling is off.\n\n## Capture Continuous-Query Go CPU\n\nTrigger Wox's built-in 30-second `runtime/pprof` action and keep deterministic queries running for that complete window:\n\n```bash\n/tmp/wox-cpu-workload \\\n  -info /tmp/wox-cpu-automation.json \\\n  -mode profile-queries \\\n  -seed 11 \\\n  -output /tmp/wox-cpu-queries.prof\n```\n\nInspect both self time and cumulative ownership:\n\n```bash\ngo tool pprof -top -nodecount=30 /tmp/wox-cpu-queries.prof\ngo tool pprof -top -cum -nodecount=30 /tmp/wox-cpu-queries.prof\n```\n\nOn macOS and Linux, read the profile header's `Duration` and `Total samples` ratio as average effective core use during the 30-second window. Record the top flat and cumulative owners. Use `go tool pprof -list '<pattern>'` for source-level attribution only after a stable owner appears.\n\nOn Windows, do not trust `Total samples / Duration` until it agrees with process CPU sampling. Go profiles can charge time blocked in `runtime.cgocall`, `syscall.syscalln`, `GetMessage`, or `GetQueuedCompletionStatus` as if it were CPU. When these wait paths dominate and the profile ratio contradicts process CPU, treat the ratio and those cumulative wait owners as profiling artifacts. Use the Windows process sampler as the CPU baseline and use application-owned profile paths only as attribution candidates that require reproduction.\n\nRepeat with `-query terminal` or another fixed query when mixed queries need attribution. Compare mixed and fixed runs from the same PID; do not compare a profile captured during startup with a warmed profile.\n\nThe automation client can time out while waiting for semantics during expensive mixed queries. If that happens:\n\n- Mark the complete process window as contaminated; do not average the idle samples after the workload stalled.\n- Check whether the built-in 30-second profile still completed in `~/.wox/cpu.prof` or `%USERPROFILE%\\.wox\\cpu.prof`, but label it partial-workload evidence.\n- Repeat with a safe fixed query such as `-query terminal`. Only use a run that reports its completed query count for the clean baseline.\n- Record the query and transition (`set` or `clear`) that timed out as a separate automation/query diagnostic.\n\n## Measure macOS Query CPU\n\nUse a separate workload-only run for process CPU percentages:\n\n```bash\nready=$(mktemp /tmp/wox-cpu-query.XXXXXX)\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode queries -duration 35s -seed 11 -ready-file \"$ready\" &\nworkload_pid=$!\nwhile [[ ! -s \"$ready\" ]]; do sleep 0.1; done\n/Users/qianlifeng/Projects/Wox/.agents/skills/wox-cpu-debug/scripts/sample-wox-cpu-macos.sh --pid <PID> --samples 30 --interval 1\nwait \"$workload_pid\"\n```\n\nUse `AverageCPUPercent`, `MedianCPUPercent`, and `MaxCPUPercent`. macOS `%CPU` uses one-core units and may exceed 100 when multiple cores are active.\n\nWhen Go pprof does not explain process CPU, repeat the workload in a separate run and capture native stacks:\n\n```bash\nready=$(mktemp /tmp/wox-cpu-query-native.XXXXXX)\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode queries -duration 35s -seed 11 -ready-file \"$ready\" &\nworkload_pid=$!\nwhile [[ ! -s \"$ready\" ]]; do sleep 0.1; done\n/usr/bin/sample <PID> 30 -file /tmp/wox-cpu-queries-native.txt\nwait \"$workload_pid\"\n```\n\nDo not run `sample` and Go CPU profiling together. Attribute CoreText, CoreGraphics, AppKit, image decoding, cgo, and platform event-loop stacks from the native capture.\n\n## Measure Windows Query CPU\n\nUse a separate workload-only run. Start the workload with a unique ready file, wait for readiness, then sample the debuggee with `TotalProcessorTime` deltas:\n\n```powershell\n$ready = Join-Path $env:TEMP (\"wox-cpu-query-\" + [guid]::NewGuid().ToString(\"N\") + \".ready\")\n$workload = Start-Process -FilePath .tmp\\cpu-debug\\wox-cpu-workload.exe `\n  -ArgumentList @(\"-info\", \".tmp\\cpu-debug\\automation.json\", \"-mode\", \"queries\", \"-duration\", \"35s\", \"-seed\", \"11\", \"-query\", \"terminal\", \"-ready-file\", $ready) `\n  -WorkingDirectory (Get-Location).Path -WindowStyle Hidden -PassThru\nwhile (-not (Test-Path $ready)) { Start-Sleep -Milliseconds 100 }\n& ..\\.agents\\skills\\wox-cpu-debug\\scripts\\sample-wox-cpu-windows.ps1 `\n  -ProcessId <PID> -Samples 30 -IntervalSeconds 1 -CsvPath .tmp\\cpu-debug\\query-samples.csv\nWait-Process -Id $workload.Id\n```\n\nWindows CPU percentages also use one-core units and can exceed 100%. One-second samples can quantize around the Windows scheduler/accounting interval, so interpret the median and repeated pattern rather than a single small non-zero value.\n\nWhen Go pprof does not explain measured process CPU, capture ETW sampled CPU stacks with Windows Performance Recorder/Analyzer or another available native profiler in a separate identical run. Filter to the debuggee PID and verify symbols before attributing DirectComposition, Direct2D, DirectWrite, Win32, image decoding, or cgo work. If no native stack profiler is available, report that limitation instead of inferring a native owner from cumulative cgo time.\n\n## Measure Hidden CPU\n\nHide Wox first, signal readiness only after the hide completes, and sample the settled process:\n\n```bash\nready=$(mktemp /tmp/wox-cpu-hidden.XXXXXX)\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode hidden -duration 35s -ready-file \"$ready\" &\nworkload_pid=$!\nwhile [[ ! -s \"$ready\" ]]; do sleep 0.1; done\nsleep 2\n/Users/qianlifeng/Projects/Wox/.agents/skills/wox-cpu-debug/scripts/sample-wox-cpu-macos.sh --pid <PID> --samples 30 --interval 1\nwait \"$workload_pid\"\n```\n\nCapture hidden native stacks in another identical run when median CPU stays above sampler noise or periodic spikes recur:\n\n```bash\nready=$(mktemp /tmp/wox-cpu-hidden-native.XXXXXX)\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode hidden -duration 35s -ready-file \"$ready\" &\nworkload_pid=$!\nwhile [[ ! -s \"$ready\" ]]; do sleep 0.1; done\nsleep 2\n/usr/bin/sample <PID> 30 -file /tmp/wox-cpu-hidden-native.txt\nwait \"$workload_pid\"\n```\n\nUse `profile-hidden` only as a secondary Go-owner check:\n\n```bash\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode profile-hidden -output /tmp/wox-cpu-hidden.prof\n```\n\nThe CPU-profile action must briefly show the launcher to activate itself, so `profile-hidden` contains one-time activation and hide work at the start. Treat a function as a hidden hotspot only when it also appears in the settled OS/native run or consumes enough repeated samples to dominate that one-time transition.\n\nOn Windows, start the same `hidden` workload with a unique ready file, wait two seconds after readiness, and invoke `sample-wox-cpu-windows.ps1` for the debuggee PID. If a large spike appears while the median is near the sampling floor, capture two more settled 30-second windows. Classify it as periodic activity only if the spike or owner recurs.\n\n## Interpret Hotspots\n\nClassify query and hidden phases separately:\n\n- **Expected query work:** plugin query execution, fuzzy matching, file/application lookup, result adaptation, layout, text measurement, image decode, and rendering that stops after hide.\n- **Query hotspot candidate:** one owner repeatedly dominates flat or cumulative samples across identical profiles and scales with query frequency.\n- **No hidden CPU signal:** median settles at sampler noise, occasional spikes do not repeat, and a 30-second native sample has no recurring application stack.\n- **Possible hidden regression:** CPU remains above noise across three settled windows or recurring stacks show timers, animation/frame scheduling, renderer submission, Glance refresh, query cleanup, indexing, GC pressure, or asynchronous reloads after hide.\n- **Strong hidden regression:** the same owner persists in Go and/or native samples, reproduces after another warm run, and disappears when its feature is disabled or its lifecycle ends.\n\nIf process CPU is high but Go pprof is quiet, investigate native or cgo owners before changing Go query code. If Go pprof is high but process samples are low, verify that the profile was captured from the same PID and that activation/transition work did not dominate a mostly idle window.\n\nOn Windows, a high pprof total dominated by blocked Win32 calls is not evidence of high process CPU. Prefer the process sampler for magnitude and use the profile only to locate application work that scales across clean, identical workloads.\n\nDo not edit production code until the workload and owner reproduce. Add targeted `util.GetLogger()` diagnostics only when profiles identify a narrow lifecycle or scheduling path but cannot prove why it remains active.\n\n## Protect Memory While Optimizing CPU\n\nTreat memory as a required guardrail for every CPU optimization:\n\n- Prefer eliminating duplicate work, coalescing invalidations, stopping unnecessary scheduling, and reusing already-owned bounded resources.\n- Do not trade CPU for unbounded caches, duplicate decoded images or pixel buffers, retained render surfaces, longer-lived queues, or state that survives hide/close without a lifecycle reason.\n- Give every new cache, pool, or buffer a hard bound and an explicit release path. Clear window-scoped native resources on hide or close unless retaining them is required and measured.\n- For changes that alter caching, buffering, pooling, object lifetime, image ownership, or native resources, compare warmed before/after process physical footprint and Go retained heap under the same workload. Use `wox-memory-debug` for repeated-cycle attribution when the delta is unclear.\n- Treat a repeatable increase above 10 MiB or 5% of the warmed process footprint as material. Rework or reject the optimization unless the user explicitly accepts the tradeoff.\n\nDo not conclude that memory is unchanged from Go heap data alone. CoreGraphics, AppKit, IOSurface, decoded images, cgo allocations, and plugin hosts can increase process memory without appearing in the Go heap.\n\n## Report\n\nInclude:\n\n- OS, CPU architecture, debug tags, PID, warm-up, query pool or fixed query, and sample duration.\n- Query average/median/max process CPU and Go profile total samples versus duration.\n- Query top flat and cumulative Go owners, plus native owners when captured.\n- Hidden average/median/max process CPU and recurring Go/native stacks.\n- Before/after process footprint and Go retained-heap deltas when the optimization can affect memory ownership, including cache bounds and hide/close release behavior.\n- Whether activation, compilation, indexing, or another limitation contaminated a window.\n- On Windows, whether blocked Win32 calls contaminated pprof totals and whether native ETW stacks were available.\n- Classification for query CPU and hidden CPU, with the exact evidence supporting each.\n","frontmatter":{"name":"wox-cpu-debug","description":"Measure CPU usage, attribute CPU hotspots, and optimize them without materially increasing Go or native memory in the real single-process Wox Go UI. Use for continuous-query CPU regressions, high idle or hidden CPU, plugin/query hot paths, renderer or native platform activity, background work that continues after hide, and comparisons of Go pprof data with macOS or Windows process samples."},"isInternal":false,"tokens":3931,"sizeBytes":16603},{"name":"openai.yaml","path":".agents/skills/wox-generate-smoke-test-case/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-generate-smoke-test-case/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `.agents/skills/wox-generate-smoke-test-case/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-generate-smoke-test-case/agents/openai.yaml)","tokens":300,"sizeBytes":236},{"name":"SKILL.md","path":".agents/skills/wox-generate-smoke-test-case/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-generate-smoke-test-case/SKILL.md","title":"wox-generate-smoke-test-case","category":"anthropic-skill","format":"markdown","content":"---\nname: wox-generate-smoke-test-case\ndescription: Analyze Wox feature code and plugin-exposed settings, recommend high-value native UI smoke scenarios and user flows, then generate focused Go UI smoke test cases using the automation driver and shared-process harness. Use when the user asks to identify smoke coverage for a Wox feature or plugin, or to design, add, write, or generate a smoke case under wox.core/test/smoke.\n---\n\n# Wox Generate Smoke Test Case\n\nUnderstand the feature before choosing coverage. Recommend the smallest high-value real-process smoke flow, then reuse the current smoke harness and product automation surface instead of building test-only paths.\n\n## Discover the Feature\n\n1. Read the repository `AGENTS.md` and relevant `README.md` files. Inspect `git status`, unstaged changes, staged changes, and relevant untracked files without modifying unrelated work.\n2. Locate the feature's real user entry point, then trace the code end to end: UI component, interaction handler, controller or service, persisted state or side effect, visible result, error path, and cleanup. Search every caller of the shared function before deciding where coverage belongs.\n3. Inspect the smoke infrastructure and nearest existing coverage:\n   - `wox.core/test/smoke/harness.go`\n   - `wox.core/test/automationdriver/client.go`\n   - The closest existing case under `wox.core/test/smoke/`\n   - The UI code that owns the relevant automation IDs and actions\n4. Identify the main functional points, platform branches, important state transitions, failure recovery, and existing unit or smoke coverage. Base the list on concrete code paths, not UI labels or assumptions.\n\n### Interpret Settings Semantics\n\nFor every settings smoke case, determine why the setting exists and trace the runtime path that consumes it before writing the test.\n\n1. State a **setting semantic contract** in user terms: changing the setting from a chosen value to another must alter a specific real product behavior, not merely the displayed or persisted control value.\n2. Build deterministic preconditions that make that behavior observable. Ensure the input data crosses the relevant boundary; for example, a maximum-result setting needs more available results than the tested cap.\n3. Drive the setting through its owning Settings section, then exercise the actual user flow that consumes it. Assert the live UI, runtime artifact, platform effect, or persisted product output that proves the semantic contract.\n4. Do not treat a selected value, a reopened control, or persistence alone as sufficient smoke evidence. Those checks may support the flow, but the final assertion must cover the setting's real user-visible effect.\n5. Account for implementation details that can distort naive evidence, such as virtual-list overscan, pagination, debouncing, asynchronous saves, or cached results. Measure the actual user-visible viewport or outcome rather than incidental semantic-tree node counts when they differ.\n\n### Inspect Plugin Settings\n\nWhen the target is a plugin:\n\n1. Find every exposed setting in the plugin metadata `SettingDefinitions`, dynamic setting callbacks, and query/action forms. Record its key, type, default, validators, options, and visibility conditions.\n2. Search every read of each setting, including `GetSetting` calls, initialization, reload callbacks, and persistence code. Map the setting to the behavior it actually changes.\n3. Build a setting coverage matrix with: setting, affected user behavior, important values or boundaries, existing coverage, smoke value, automation feasibility, and recommendation.\n4. Recommend a smoke case when a setting changes query results, actions, enablement, persistence or reload behavior, platform integration, validation or recovery, or another user-visible cross-process boundary.\n5. Skip separate smoke coverage for headings, labels, layout-only fields, equivalent options already covered by one representative value, and branches better protected by unit tests. Avoid a case for every setting or every option.\n6. Group settings into one user flow only when they naturally belong to the same task and failures remain easy to diagnose. Keep independent high-risk behaviors in separate cases.\n7. Never require real secrets, uncontrolled network services, or unavailable hardware. Prefer deterministic missing/invalid configuration and local persistence behavior unless the dependency is explicitly controlled by the test environment.\n\n## Recommend Coverage\n\nWhen the user asks for coverage design, present:\n\n- **Code map:** Name the main source files, functions, and responsibilities.\n- **Functional points:** Summarize the primary user-visible behaviors and important boundaries.\n- **Candidate cases:** Recommend no more than five flows, ordered by value. For each, include priority, user risk, existing coverage gap, prerequisites, actions, observable expected result, and automation feasibility.\n- **Plugin setting matrix:** For plugin requests, show which exposed settings deserve smoke coverage, which do not, and the source-backed reason for each decision.\n- **Recommended first case:** Select the smallest flow that covers the highest-risk real integration boundary and explain briefly why it belongs in smoke rather than a unit test.\n- **Automation gap:** Identify any missing stable automation ID or action required by the recommended flow.\n\nWhen the user already specified the exact flow, keep the pre-edit design brief: present only the code map, one observable behavior contract, and any automation gap. Do not expand an approved flow into an unnecessary candidate list or full setting matrix.\n\nRecommend smoke coverage only for real-process native UI, lifecycle, persistence, plugin integration, platform, accessibility, or rendering boundaries. Prefer unit tests for local pure logic and skip behavior already covered at the same boundary.\n\nIf the user asked only for design, stop after the recommendation. If the user already named or approved an exact flow, continue. Otherwise ask which recommended case to generate before editing product or test code.\n\n## Generate the Case\n\n1. State one observable behavior contract for the selected flow.\n2. Search all smoke packages for an existing helper before adding a local one. Promote a helper to `automationdriver` or `smoke` when a second consumer uses the same interaction contract; keep plugin-specific behavior in the leaf package. Avoid page-object layers or table-editor DSLs until repeated cases justify them.\n3. Reuse existing automation IDs, actions, `smoke.Case`, and helpers. Before driving a control, confirm its semantics expose a stable ID, role, label, current value or checked state, selected state when relevant, and the correct action. If that contract is missing, modify the smallest shared owning UI component to add a stable automation ID or semantic action, then add a focused component test for that contract. The semantic action must follow the real user interaction path; do not add a test-only bypass around product behavior.\n4. Add the case under the owning functional path. Reserve `wox.core/test/smoke/setting/` for Wox's own settings sections, such as `setting/ui/`. Every plugin-owned case must live under `wox.core/test/smoke/launcher/plugin/<plugin>/`, including flows that configure the plugin through its Settings page before exercising Launcher behavior. Classify by product owner rather than the UI route used during the flow; for example, place Calculator coverage under `launcher/plugin/calculator/`. Use the next unused three-digit number without renumbering existing cases:\n   - File: `NNN_descriptive_name_test.go`\n   - Function: `TestNNNDescriptiveName`\n   - Build constraint: `//go:build wox_ui_smoke`\n5. Immediately above every generated `TestNNN...` function, add a concise English doc comment that states the user-visible intent, the ordered UI flow, and the final evidence that proves the behavior. Mention prerequisites or cleanup only when they are part of the contract. Describe product behavior rather than automation implementation details. Use this shape:\n\n   ```go\n   // TestNNNDescriptiveName verifies <user-visible behavior and boundary>.\n   // Flow: <entry> -> <important actions or state transitions> -> <observable result>.\n   // Evidence: <real UI, runtime, persisted artifact, or log assertion that proves success>.\n   func TestNNNDescriptiveName(t *testing.T) {\n   ```\n\n6. Drive the UI through `automationdriver.Client` semantic actions (`Perform`, `PressKey`, `SetValue`) and `client.WaitFor`. Never use fixed sleeps to guess readiness. Use postconditions such as `Selected`, `Checked`, `Value`, status, or disappearance. Do not use mouse clicks, drags, node bounds, pointer coordinates, or screenshot pixels when a semantic action can produce the same transition. A real pointer or OLE drag is allowed only when the behavior under test is that native gesture and no semantic action exists. Even then, do not assert desktop hit-testing: which other HWND became foreground, title-bar or caption-button coordinates, z-order, or that a fixed client point such as a window center stays uncovered. Developer screens and CI desktops overlap differently. Assert Wox's own outcome (visibility, query result, callback, or file artifact). If a point is unavoidable, derive it at runtime from current window rects and keep it off other windows in the case.\n7. Treat query and result state as generation-bound. Setting the same query value may be a no-op, and refreshes may replace dynamic result IDs. Force a real query transition when freshness matters, wait for both the input value and `launcher.results=complete`, and resolve dynamic IDs again after refresh instead of retaining them across generations.\n8. Treat every command executed by a smoke case as interpreter- and platform-dependent input. Confirm the interpreter the case actually selects or inherits on Windows, macOS, and Linux. Prefer the simplest syntax shared by all targeted interpreters; do not assume Bash operators such as `&&`, `export`, Unix paths, or Unix-only tools work in Windows PowerShell. When no shared command exists, select the command with `runtime.GOOS` and, when configurable, the chosen interpreter, while keeping output and side effects equivalent. Normalize path separators and line endings in assertions. If the behavior is intentionally platform-specific, skip it explicitly with the reason instead of waiting for an impossible state.\n9. Let `smoke.Case` own before/after reset and the shared client, but do not assume reset restores plugin settings or desktop side effects. Explicitly restore changed settings and clean external state. Reopen settings or inspect persisted data before exercising runtime behavior; a locally updated control does not prove an asynchronous save completed.\n10. Keep assertions user-visible and deterministic. Prefer evidence in this order: real runtime artifact or fresh log slice, reloaded persisted value, then live semantic state. Treat relevant snapshot diagnostics as failures. Do not weaken assertions or add retries merely to hide a race.\n11. Do not launch another Wox process or create a second data directory inside a case. Use `automationdriver.SharedDataDirectoryEnvironment` only when the behavior must inspect real persisted output, and poll artifacts independently of UI generation changes.\n12. Format every touched Go file with the repository formatter. Run the new case from the repository root:\n\n   ```text\n   make smoke <functional/path/NNN>\n   ```\n\n13. After the targeted case passes, run `make smoke` to catch leaked state and shared-process cleanup failures. If the full suite fails in an existing case, distinguish that baseline failure from the new selector instead of attributing it to the new coverage. If execution is blocked by the environment, report the exact blocker and do not claim runtime coverage.\n\n## Failure Handling\n\n- Start from the exact command output, logs, snapshot, and failing state.\n- On a wait failure, capture the current values, checked states, status nodes, diagnostics, and relevant fresh log or artifact contents. Report the observed boundary instead of only the timeout.\n- Fix the shared product or automation boundary when that is the root cause; do not patch every case around it.\n- Add diagnostic logging only when the failure path cannot be identified with certainty, then use the new evidence before changing behavior.\n- Preserve unrelated worktree changes and keep the diff limited to the case plus any strictly required automation exposure.\n\n## Completion\n\nReport the behavior covered, the created case selector, every production or automation file changed to support it, and the exact verification commands with pass or failure status.\n","frontmatter":{"name":"wox-generate-smoke-test-case","description":"Analyze Wox feature code and plugin-exposed settings, recommend high-value native UI smoke scenarios and user flows, then generate focused Go UI smoke test cases using the automation driver and shared-process harness. Use when the user asks to identify smoke coverage for a Wox feature or plugin, or to design, add, write, or generate a smoke case under wox.core/test/smoke."},"isInternal":false,"tokens":2478,"sizeBytes":12776},{"name":"openai.yaml","path":".agents/skills/wox-i18n/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-i18n/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `.agents/skills/wox-i18n/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-i18n/agents/openai.yaml)","tokens":300,"sizeBytes":196},{"name":"SKILL.md","path":".agents/skills/wox-i18n/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-i18n/SKILL.md","title":"wox-i18n","category":"anthropic-skill","format":"markdown","content":"---\nname: wox-i18n\ndescription: Add a new Wox language or complete and improve an existing Wox translation. Use for Wox-owned locale registration, translation parity, wording quality, and placeholder-safe updates based on wox.core/resource/lang/en_US.json.\n---\n\n# Wox I18n\n\nUse `wox.core/resource/lang/en_US.json` as the authoritative source for keys, meaning, structure, and placeholders. Work on one requested locale at a time unless the user explicitly asks for several.\n\n## Shared rules\n\n- Read the repository `AGENTS.md` and the relevant locale files before editing.\n- Preserve every placeholder exactly, including `{name}`, Wox placeholders such as `{wox:selected_text}`, printf verbs such as `%s` and `%02d`, newlines, and other formatting tokens. Reordering placeholders is allowed only when the format mechanism supports it and the target language requires it.\n- Resolve ambiguous English by searching for the key's call sites and neighboring translations. Translate the UI meaning, not the key name in isolation.\n- Keep product names, commands, file paths, URLs, keyboard shortcuts, and technical identifiers unchanged when they are proper names or literal input.\n- Match the tone and terminology already used by the target locale. Prefer natural, concise UI text over literal translation.\n- Keep JSON valid, formatted with two-space indentation and a final newline. Preserve English key order; insert missing entries beside their English counterparts instead of reordering unrelated entries.\n- Do not put Wox-owned translations in Go maps. Keep them in `wox.core/resource/lang/*.json` and reference them with `i18n:` keys, as required by the repository instructions.\n- Do not blanket-translate third-party entries in `store-plugin.json`; their translations belong to their authors. Wox-owned catalogs such as `store-ai-command.json` are in scope when they contain the target locale.\n\n## Choose the workflow\n\n### Add a new language\n\nUse commit `0cfb2a346af4278c5cd385aa649cb9ddb641f461` as a concrete checklist, but follow the current tree when it has evolved:\n\n```powershell\ngit show --stat 0cfb2a346af4278c5cd385aa649cb9ddb641f461\ngit show 0cfb2a346af4278c5cd385aa649cb9ddb641f461 -- wox.core/i18n/lang.go store-ai-command.json wox.core/ui/launcher/view/form_table_view_test.go www/docs/.vitepress/theme/components/pluginStore.ts www/docs/development/plugins/specification.md www/docs/zh/development/plugins/specification.md AGENTS.md\n```\n\nThen make the smallest complete current-tree change:\n\n1. Confirm the locale code, English language name, and native display name.\n2. Create `wox.core/resource/lang/<locale>.json` with every key from `en_US.json`, in the same order, fully translated.\n3. Register the `LangCode` and native display name in `wox.core/i18n/lang.go`.\n4. Add the locale to Wox-owned locale maps, currently including `store-ai-command.json`, and to website locale mapping where applicable.\n5. Update current supported-language documentation and any tests that explicitly enumerate languages or translated labels.\n6. Search for the existing locale codes to find registration surfaces added after the reference commit. Update only surfaces whose behavior depends on the complete supported-language list.\n\nDo not create a translated documentation site merely because the app gains a locale; add one only when the user requests and supplies that scope.\n\n### Complete or improve an existing language\n\n1. Run the checker to identify missing, extra, empty, identical-to-English, and placeholder-mismatched values.\n2. Add every missing English key and translate it from the English value. Treat identical values as review candidates, not automatic errors: names and technical terms may legitimately remain English.\n3. For requested quality improvements, inspect awkward or stale values in related groups and their call sites. Change only wording you can improve confidently.\n4. Remove an extra key only after confirming that it is absent from `en_US.json` and unused; otherwise report it for review.\n5. Check Wox-owned auxiliary catalogs, especially `store-ai-command.json`, for missing target-locale entries when the request is to complete the language across Wox.\n\nAvoid replacing the whole locale file when a focused insertion or wording edit produces a clear diff.\n\n## Verification\n\nRun from the repository root:\n\n```powershell\npython .agents/skills/wox-i18n/scripts/check_locale.py <locale>\ngit diff --check\n```\n\nThe checker must pass without missing keys, extra keys, empty values, or placeholder mismatches. Review its identical-value warnings manually.\n\nIf language registration or enumerating tests changed, run the focused Go tests from `wox.core`:\n\n```powershell\ngo test ./i18n ./ui/launcher/view\n```\n\nFinish by reviewing the diff for accidental English fallback text, placeholder damage, unrelated rewrites, and omissions from the reference-commit checklist.\n","frontmatter":{"name":"wox-i18n","description":"Add a new Wox language or complete and improve an existing Wox translation. Use for Wox-owned locale registration, translation parity, wording quality, and placeholder-safe updates based on wox.core/resource/lang/en_US.json."},"isInternal":false,"tokens":1043,"sizeBytes":4891},{"name":"openai.yaml","path":".agents/skills/wox-memory-debug/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-memory-debug/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `.agents/skills/wox-memory-debug/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-memory-debug/agents/openai.yaml)","tokens":300,"sizeBytes":212},{"name":"SKILL.md","path":".agents/skills/wox-memory-debug/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-memory-debug/SKILL.md","title":"wox-memory-debug","category":"anthropic-skill","format":"markdown","content":"---\nname: wox-memory-debug\ndescription: Diagnose memory leaks in the current single-process Wox Go UI by launching the real debug build with its automation endpoint enabled, replaying representative launcher searches and settings-window open/close cycles, sampling the same process across repeated workload blocks, and comparing Go heap profiles when retained memory keeps growing. Use for Wox memory-leak checks, search-result retention, settings cleanup, Go UI memory growth, or repeated UI lifecycle regressions on Windows or macOS.\n---\n\n# Wox Memory Debug\n\n## Goal\n\nRun the real Go UI in debug mode with the `wox_automation` endpoint, exercise normal launcher searches and the independent settings-window lifecycle through the semantics tree, and decide whether memory settles after warm-up or grows with repeated work. Treat Wox as one Go process and use post-warm-up growth rather than an absolute memory budget as the leak criterion.\n\n## Run the Debug Build\n\n1. Stop other Wox instances so sampling cannot select the wrong process.\n2. Start the real Wox debug build under Delve with both production dependencies and the automation endpoint enabled:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\nWOX_AUTOMATION_INFO_FILE=/tmp/wox-memory-automation.json /Users/qianlifeng/go/bin/dlv debug . --build-flags=-tags=sqlite_fts5,wox_automation\n```\n\n3. At the Delve prompt, run `continue`.\n4. Wait until startup and plugin initialization finish, then wait for `WOX_AUTOMATION_INFO_FILE` to be written.\n5. Record the debuggee PID from the debugger. Always pass this PID to the sampler because debugger-built executables may have temporary names.\n\nKeep the debugger running normally. Do not pause at breakpoints while collecting memory samples. This uses the real Wox process with only the automation server compiled in; do not launch the separate Go UI smoke-test runner.\n\n## Establish a Warm Baseline\n\nUse the bundled automation workload driver against the real launcher:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\ngo run ../.agents/skills/wox-memory-debug/scripts/run-query-workload.go -info /tmp/wox-memory-automation.json -mode queries -count 20 -seed 1\n```\n\n1. Run two warm-up blocks before recording the baseline.\n2. In each block, replay 20 queries drawn repeatedly from these safe categories:\n   - Calculator, such as `1+1`.\n   - System command lookup, such as `settings`.\n   - Application or general search, such as `wox`.\n   - File-oriented search, such as `readme`.\n3. Use a different deterministic seed for each block so the workload is reproducible while still varying result types.\n4. The driver waits for the query value, allows results to settle, records the visible result count and semantics generation, clears the query, and continues. It does not execute results or commands.\n5. At the end of the block, the driver hides the launcher. Wait 10 seconds so every checkpoint uses the same idle state.\n\nTake the warm baseline only after these blocks. Initial startup growth, lazy font loading, icon decoding, and cache creation are expected and are not leak evidence.\n\n## Sample the Same Process\n\n### macOS\n\n```bash\n/Users/qianlifeng/Projects/Wox/.agents/skills/wox-memory-debug/scripts/sample-wox-memory-macos.sh --pid <PID> --samples 3 --interval 2\n```\n\nUse `PhysicalFootprintMB`. Absolute debug memory is not the leak criterion.\n\n### Windows\n\n```powershell\npowershell -ExecutionPolicy Bypass -File C:\\dev\\Wox\\.agents\\skills\\wox-memory-debug\\scripts\\sample-wox-memory.ps1 -Pids <PID> -Samples 3 -IntervalSeconds 2\n```\n\nUse `PrivateWorkingSetMB`.\n\nDo not compare macOS physical footprint with Windows private working set. Compare checkpoints from the same PID, OS, debug session, workload, and idle state.\n\n## Run the Measured Query Workload\n\n1. Record the warm baseline.\n2. Run five measured blocks of 10 or 20 queries using distinct seeds and the same query pool.\n3. After each block, clear the query, hide the launcher, wait 10 seconds, and sample the same PID three times.\n4. Record the median of each three-sample checkpoint to reduce sampler noise.\n5. Report cumulative query count, median memory, change from the warm baseline, and the observed shape of the series.\n\nUse more blocks only when the trend is ambiguous. Keep the process alive for the whole run; restarting Wox invalidates the comparison.\n\n## Test Settings Window Cleanup\n\nRun this lifecycle check after the query workload. It opens settings through the real `Open Wox Settings` result, waits for the independent settings semantics host, closes the settings window, waits until the launcher host owns automation again, and clears the opening query:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\ngo run ../.agents/skills/wox-memory-debug/scripts/run-query-workload.go -info /tmp/wox-memory-automation.json -mode settings -count 1\n```\n\n1. Run one settings cycle as warm-up. Wait 10 seconds and record the closed-settings baseline.\n2. Run at least three measured blocks of five open/close cycles:\n\n```bash\ngo run ../.agents/skills/wox-memory-debug/scripts/run-query-workload.go -info /tmp/wox-memory-automation.json -mode settings -count 5\n```\n\n3. After each block, keep both launcher and settings closed, wait 10 seconds, and sample the same PID three times. Record the median.\n4. Confirm every cycle reports both an `opened_generation` and `closed_generation`. The driver considers close complete only after `settings-search-field` disappears and `launcher.query.input` returns, which means `settingsView` and `settingsHost` have left the active automation surface.\n5. Compare measured block medians with the post-warm-up closed-settings baseline. Repeat one identical five-cycle block after a 30-second idle checkpoint when the trend is ambiguous.\n\nThe first settings open may retain shared fonts, icons, and reusable renderer caches. Do not require the process to return to its pre-first-open value. Window-scoped settings state and native resources must not accumulate across later cycles: after warm-up, closed-settings checkpoints should plateau within sampler jitter instead of growing with cumulative open/close count.\n\n## macOS Debug Reference\n\nUse the August 10, 2026 macOS arm64 run as a comparison point for the current settings cleanup behavior, not as an absolute budget. The run used macOS 26.5.2, Go 1.26.2, Delve 1.26.2, the `sqlite_fts5,wox_automation` build tags, real Wox data, one PID, a 10-second hidden/closed wait, and three `PhysicalFootprintMB` samples at two-second intervals.\n\nThe query baseline was recorded after two 20-query warm-up blocks. The settings baseline was recorded after one complete warm-up open/close cycle:\n\n| Checkpoint | Median PhysicalFootprintMB | Change from closed-settings baseline |\n| --- | ---: | ---: |\n| Hidden after 40 warm-up queries | 89.1 MB | N/A |\n| Settings closed warm baseline | 99.5 MB | 0.0 MB |\n| 5 measured settings cycles | 100.9 MB | +1.4 MB |\n| 10 measured settings cycles | 101.4 MB | +1.9 MB |\n| 15 measured settings cycles | 101.7 MB | +2.2 MB |\n| 30-second idle confirmation | 102.3 MB | +2.8 MB |\n\nClassify this series as `no leak signal`: the closed-settings checkpoints remained around 100-102 MB, and the 30-second confirmation stayed within observed sampler and allocator variation. `vmmap` reported no resident IOSurface memory after close; CoreGraphics and IOAccelerator residency was negligible. A Go heap comparison captured during the investigation showed only about 15 KB of retained delta, which redirected attribution to native window ownership rather than Go settings state.\n\nPreserve these cleanup contracts when investigating a regression:\n\n- Keep at most one live `wox.settings` window, while still treating each close/reopen as a new native lifetime.\n- Release settings-only plugin catalogs, search indexes, forms, and application candidates on close, and invalidate in-flight loads so they cannot refill released caches.\n- Load the plugin store and application candidates only when their UI needs them.\n- Release the macOS `NSWindow`, view, and delegate hierarchy synchronously on close. Do not defer them to the application-lifetime autorelease pool.\n\nBefore the native close fix, a separate same-shape debug run rose from 104.8 MB after the warm settings close to 112.8 MB after 15 measured cycles. Treat a return of that cumulative, window-count-scaled shape as a regression even when the absolute starting footprint differs.\n\n## Windows Debug Reference\n\nUse the September 22, 2026 Windows run as a comparison point for hidden idle memory, not as a budget. The run used a dev build with `sqlite_fts5,wox_automation`, real Wox data, two 20-query warm-up blocks, and three `PrivateWorkingSetMB` samples 45 seconds after hide, when both the 10-second and 30-second release stages had run:\n\n| Checkpoint | Median PrivateWorkingSetMB | Live Go heap |\n| --- | ---: | ---: |\n| Staged trims plus prepared search text and pinyin release | 63.8 MB | 17.2 MB |\n| Shared plugin logger and shared fsnotify watcher | 60.8 MB | 15.2 MB |\n| Live-object reductions (`wox.core/ui/README.md`, \"Hidden-state ownership rules\") | 55.4 MB | 11.0 MB |\n\nHidden memory drops in two steps: about 2-4 MB at 10 seconds and about 40 MB at 30 seconds, so sampling before 45 seconds compares different lifecycle states. When attributing what remains, use Delve `goroutines -group userloc` for goroutine ownership and the `woxmemory go` / `woxmemory native` commands for the Go-versus-native split; the largest native owners are NT heap fragmentation from show/hide churn and renderer objects that survive hide.\n\n## Decide Whether Memory Leaks\n\nInterpret the post-warm-up series, not a single number:\n\n- **No leak signal:** memory rises during warm-up and then plateaus, oscillates within a stable range, or drops after an idle checkpoint.\n- **Possible leak:** the settled checkpoint median keeps increasing across at least three consecutive measured blocks and the increase is materially larger than sampler jitter.\n- **Strong leak signal:** retained growth continues after another identical workload, scales with cumulative query or settings-cycle count, and does not settle during a longer 30-60 second idle checkpoint.\n\nApply the same classification independently to cumulative queries and cumulative settings cycles. A stable query series does not rule out a settings-window lifecycle leak.\n\nGo may retain heap arenas after objects become unreachable, so a high or non-decreasing process footprint alone is not proof. Report the result as `no leak signal`, `possible leak`, or `strong leak signal`, together with the measurements that support it.\n\n## Attribute Persistent Growth\n\nOnly profile after the repeated-query or settings-lifecycle run shows a possible or strong leak signal.\n\n1. Trigger the Wox Memory plugin's `woxmemory profile ` command through the automation driver after warm-up:\n\n```bash\ngo run ../.agents/skills/wox-memory-debug/scripts/run-query-workload.go -info /tmp/wox-memory-automation.json -mode profile\n```\n2. Copy the generated profile immediately because the next capture overwrites it:\n\n```bash\ncp ~/.wox/memory.prof /tmp/wox-memory-before.prof\n```\n\nOn Windows, copy `%USERPROFILE%\\.wox\\memory.prof` to a distinct temporary file instead.\n\n3. Repeat the measured workload, run the command again, and copy the second profile:\n\n```bash\ncp ~/.wox/memory.prof /tmp/wox-memory-after.prof\n```\n\n4. Compare retained Go heap growth from `wox.core`:\n\n```bash\ngo tool pprof -top -base /tmp/wox-memory-before.prof /tmp/wox-memory-after.prof\n```\n\nIf process memory grows but the Go heap delta stays small, inspect Go UI native owners next: GPU textures and image caches, decoded result icons, preview resources, platform window allocations, and query-result cleanup. For settings-only growth, inspect `settingsView`, `settingsHost`, settings editors/forms, theme wallpaper previews, cloud/model state, asynchronous reloads, and native window/renderer destruction. On macOS, compare `vmmap <PID> -summary` checkpoints and pay particular attention to `IOAccelerator` and `IOSurface`. If repeated identical queries still grow, inspect lazy-image cache identity, per-draw Metal texture creation, and drawable-size churn before attributing growth to unique query strings.\n\nUse `-query terminal` with query mode for an identical-query control only when the mixed workload needs further attribution.\n\n## Report\n\nInclude:\n\n- OS, debug configuration, PID, workload, and checkpoint timing.\n- A checkpoint table with cumulative queries and median process memory.\n- A separate closed-settings checkpoint table with cumulative open/close cycles and median process memory.\n- The trend classification and whether a longer confirmation block was needed.\n- Go heap delta owners only when profiling was necessary.\n- Any limitation that prevented consistent UI automation or reliable sampling.\n\nDo not edit production code until the measurements identify a reproducible trend and a likely owner.\n","frontmatter":{"name":"wox-memory-debug","description":"Diagnose memory leaks in the current single-process Wox Go UI by launching the real debug build with its automation endpoint enabled, replaying representative launcher searches and settings-window open/close cycles, sampling the same process across repeated workload blocks, and comparing Go heap profiles when retained memory keeps growing. Use for Wox memory-leak checks, search-result retention, settings cleanup, Go UI memory growth, or repeated UI lifecycle regressions on Windows or macOS."},"isInternal":false,"tokens":2873,"sizeBytes":12962},{"name":"hotkeys.md","path":".agents/skills/wox-plugin-creator/references/hotkeys.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/hotkeys.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/hotkeys.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/hotkeys.md)","tokens":300,"sizeBytes":226},{"name":"html_preview_updates.md","path":".agents/skills/wox-plugin-creator/references/html_preview_updates.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/html_preview_updates.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/html_preview_updates.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/html_preview_updates.md)","tokens":300,"sizeBytes":252},{"name":"icons.md","path":".agents/skills/wox-plugin-creator/references/icons.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/icons.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/icons.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/icons.md)","tokens":300,"sizeBytes":222},{"name":"plugin_i18n.md","path":".agents/skills/wox-plugin-creator/references/plugin_i18n.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_i18n.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/plugin_i18n.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_i18n.md)","tokens":300,"sizeBytes":234},{"name":"plugin_json_schema.md","path":".agents/skills/wox-plugin-creator/references/plugin_json_schema.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_json_schema.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/plugin_json_schema.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_json_schema.md)","tokens":300,"sizeBytes":248},{"name":"plugin_overview.md","path":".agents/skills/wox-plugin-creator/references/plugin_overview.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_overview.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/plugin_overview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_overview.md)","tokens":300,"sizeBytes":242},{"name":"plugin_tools.md","path":".agents/skills/wox-plugin-creator/references/plugin_tools.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_tools.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/plugin_tools.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_tools.md)","tokens":300,"sizeBytes":236},{"name":"refinements.md","path":".agents/skills/wox-plugin-creator/references/refinements.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/refinements.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/refinements.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/refinements.md)","tokens":300,"sizeBytes":234},{"name":"scaffold_nodejs.md","path":".agents/skills/wox-plugin-creator/references/scaffold_nodejs.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/scaffold_nodejs.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/scaffold_nodejs.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/scaffold_nodejs.md)","tokens":300,"sizeBytes":242},{"name":"scaffold_python.md","path":".agents/skills/wox-plugin-creator/references/scaffold_python.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/scaffold_python.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/scaffold_python.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/scaffold_python.md)","tokens":300,"sizeBytes":242},{"name":"sdk_nodejs.md","path":".agents/skills/wox-plugin-creator/references/sdk_nodejs.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/sdk_nodejs.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/sdk_nodejs.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/sdk_nodejs.md)","tokens":300,"sizeBytes":232},{"name":"sdk_python.md","path":".agents/skills/wox-plugin-creator/references/sdk_python.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/sdk_python.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/sdk_python.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/sdk_python.md)","tokens":300,"sizeBytes":232},{"name":"settings_patterns.md","path":".agents/skills/wox-plugin-creator/references/settings_patterns.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/settings_patterns.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/settings_patterns.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/settings_patterns.md)","tokens":300,"sizeBytes":246},{"name":"SKILL.md","path":".agents/skills/wox-plugin-creator/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/SKILL.md","title":"wox-plugin-creator","category":"anthropic-skill","format":"markdown","content":"---\nname: wox-plugin-creator\ndescription: Create, scaffold, implement, and package Wox plugins (nodejs, python, singlefile-python, singlefile-nodejs). Use when cloning official SDK templates, generating single-file SDK plugin templates, editing plugin.json metadata, defining SettingDefinitions and validators, wiring i18n, implementing plugin APIs, QueryResponse refinements, refinement and action hotkeys, structured query slots, Plugin Tools (RegisterPluginTool / InvokePluginTool), 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.\n---\n\n# Wox Plugin Creator\n\n## Quick Start\n\n- Scaffold a Node.js plugin (clones template repo):\n  - `python3 scripts/scaffold_wox_plugin.py --type nodejs --output-dir ./MyPlugin --name \"My Plugin\" --trigger-keywords my`\n- Scaffold a Python plugin (clones template repo):\n  - `python3 scripts/scaffold_wox_plugin.py --type python --output-dir ./MyPlugin --name \"My Plugin\" --trigger-keywords my`\n- Scaffold a single-file SDK plugin (uses local templates; plugin-id auto-generated; writes **one** file into the live user plugin directory so a running Wox instance can load it immediately). Omit `--output-dir`; default is `~/.wox/wox-user/plugins/single-file/` (Windows: `%USERPROFILE%\\.wox\\wox-user\\plugins\\single-file\\`):\n  - Auto-detect this machine: `python3 scripts/scaffold_wox_plugin.py --type singlefile --name \"Weather\" --trigger-keywords weather`\n  - Explicit Node.js: `python3 scripts/scaffold_wox_plugin.py --type singlefile-nodejs --name \"Weather\" --trigger-keywords weather`\n  - Explicit Python: `python3 scripts/scaffold_wox_plugin.py --type singlefile-python --name \"Weather\" --trigger-keywords weather`\n\n## Choose a plugin type\n\n- **Single-file SDK plugin**: one `.py` or CommonJS `.js` file with full Public API, loaded into the existing Python/Node runtime host. No extra process per query. Create and edit **only** `~/.wox/wox-user/plugins/single-file/Wox.Plugin.<Name>.js` (or `.py`); Wox watches that directory and reloads on save. Requires Wox 2.4.2+; header `MinWoxVersion` must be `\"2.4.2\"`.\n- **SDK plugin (`.wox`)**: multi-file package with dependencies, resources, TypeScript, and `plugin.json`.\n\nNode.js first version must stay CommonJS (`module.exports.plugin`) and must not import `@wox-launcher/wox-plugin`.\n\n## Choose a runtime language\n\nHonor an explicit Python or Node.js request from the user, including a `.py` or `.js` output filename.\n\nWhen the user does not specify a language, detect this machine before scaffolding. Do not default to Python.\n\n1. Run `python3 scripts/detect_local_runtime.py` (use `python` if `python3` is missing). It prints `nodejs`, `python`, or `none`.\n2. If that script cannot run, check the floors yourself: `node --version` for Node.js 20+, and `python3 --version` for Python 3.10+. On Windows also try `py -3 --version` and `python --version`.\n3. Decision:\n   - Only one runtime meets the floor → use that runtime\n   - Both meet the floor → use Node.js\n   - Neither meets the floor → ask the user which language they want\n4. Map the choice to `--type`: `singlefile-nodejs` / `singlefile-python`, or `nodejs` / `python`. `--type singlefile` applies the same detection inside the scaffold.\n\n## Workflow\n\n### 1) Scaffold plugin files\n\n- Use `scripts/scaffold_wox_plugin.py` for `nodejs`, `python`, `singlefile`, `singlefile-python`, or `singlefile-nodejs`.\n- Pass `--name` and `--trigger-keywords` for every runtime. The scaffold exits without them. `--output-dir` is required for packaged SDK plugins; omit it for single-file SDK plugins so the file lands in `~/.wox/wox-user/plugins/single-file/`.\n- For Node.js and Python packages, the scaffold clones the official template repos and replaces placeholders like `{{.ID}}`, `{{.Name}}`, `{{.Description}}`, `{{.TriggerKeywordsJSON}}`, `{{.Author}}`.\n- Before starting work in a new SDK plugin project, run `make init` in the project root when the project has not been initialized yet.\n- Single-file SDK plugins are **single-file** host-loaded plugins. Prefer filenames like `Wox.Plugin.<Name>.js` or `Wox.Plugin.<Name>.py`.\n- **Single-file SDK destination**: create and implement the plugin as one file in `~/.wox/wox-user/plugins/single-file/` (Windows: `%USERPROFILE%\\.wox\\wox-user\\plugins\\single-file\\`). That directory is what a running Wox instance loads; saving reloads after about 500ms, so the user can query the trigger keyword immediately. Omit `--output-dir` when using the scaffold, or write the file there directly from `assets/single_file_plugin_templates/`. Do not also create a copy under the current repository (`plugins/`, workspace root, or a new folder). Pass `--output-dir` only when the user asks for a different path.\n- Do not put companion files (`*.test.js`, README, extra modules) in the live directory. Wox loads every `.js` and `.py` there as a plugin.\n- Single-file SDK plugins must set header `MinWoxVersion` to `\"2.4.2\"`. The scaffold applies this default when `--min-wox-version` is omitted. Do not lower it; Wox 2.4.2 is the first release that can load this plugin type, and store/CI reject older floors.\n- For single-file SDK plugins, the scaffold copies templates from `~/.wox/ai/skills/wox-plugin-creator/assets/single_file_plugin_templates/` (or the repo `.agents/skills/wox-plugin-creator/assets/single_file_plugin_templates/` fallback).\n- Prefer standard library features; avoid third-party dependencies unless absolutely necessary. Single-file SDK plugins cannot use pip/npm packages.\n- For SDK usage and API details, read `references/sdk_nodejs.md` or `references/sdk_python.md`.\n- For plugins declaring `querySelection`, return results only for selection types and content the plugin can process. Return an empty results list for unsupported, missing, or empty selection data instead of showing usage or help rows for unrelated selections.\n- Keep a result on the row. `Title` is the name to scan. `SubTitle` is one short identity line, such as a code, place, or source. `Tails` are the few facts that must stay visible, such as a price and its change. Use at most three tail tags on one result. A fourth tag can be clipped, so part of a tag is not shown. Put any further fact in the subtitle, the copied text, or a preview. Do not add `Preview` for a quote, status, short record, or anything that fits on that row.\n- A durable result must set `IdentityKey` (Python `identity_key`, script JSON `identity_key`). Wox uses it for usage history, query pins, and MRU. The value must identify that one result and no other result from the plugin, and it must stay the same when the title, subtitle, translation, score, or query text changes. Use the item's own id, such as a path, URL, note id, command id, or record id. Do not use the visible title, a translated string, the current query, a random id, or one shared key for a whole list. The same item returned from search and from MRU restore must use the same key. `score_key` / `ScoreKey` is only the older name. Omit `IdentityKey` on a temporary result: a prompt, an empty or error state, a one-time status, or a row that exists only for the current selection or query and will not be pinned or restored.\n- A text tail already has a theme-aware rounded container. Use an SVG image tail only when that tag must also contain an icon. Match the launcher metrics below, and see [Simulated tail tags](#simulated-tail-tags).\n- Refresh a visible row in place with `UpdateResult` / `update_result`. Remember the results returned by the latest `query()`. Replace that list on the next query. When a background refresh or an action changes a row that is still on screen, call `UpdateResult` with the same result `Id` and only the fields that changed (`Title`, `SubTitle`, `Icon`, `Tails`, `Actions`). The query text stays put and the list does not reload. Use `RefreshQuery` / `refresh_query` only when rows must be added or removed and `UpdateResult` cannot express that. Do not use `ChangeQuery` to redraw results.\n- Add `Preview` only for a large body that cannot fit the row: a long document, many fields, a chart, a gallery, or syntax highlighting. When a preview is required, use `markdown` for prose, lists, links, and images. Use `text` or `image` when that is the whole preview. Use `webview` HTML only after markdown cannot express it, such as syntax highlighting, folding, or an interactive layout. HTML is the last option because the webview can steal query focus, miss launcher theme colors, and hit layout bugs. There is no separate `html` preview type; HTML uses `webview` with a JSON-encoded `html` field and no local HTTP server. See the HTML preview examples in the SDK references.\n- For dynamic updates to an existing HTML WebView, prefer script-mode `UpdateResult` / `update_result` with `{\"updateMode\":\"script\",\"script\":\"...\"}` instead of repeatedly replacing the full HTML. Update existing DOM nodes to preserve scrolling, text selection, and animations. This does not change the rule that HTML is the last preview option. Read [HTML preview updates](references/html_preview_updates.md) for the contract, lifecycle, safe serialization, and Python/Node.js examples.\n- Do not rasterize documents as SVG/`image` previews; those scale as pictures, cannot select text, and do not follow theme colors.\n- When HTML is required, follow the current Wox theme. Call `GetThemeColors` / `get_theme_colors` (Wox >= 2.4.5) when building the HTML and paint opaque `Background`, `Text`, `SecondaryText`, `Border`, `Accent`, `AccentText`, and `Selection`. Use `Dark` to choose a light or dark syntax palette. Do not hardcode only a dark page, and do not rely on `transparent` or `prefers-color-scheme` as a substitute for the launcher palette. Include a theme color in `cacheKey` so the preview refreshes after a theme change. If the API is missing, fall back to a dark and a light default.\n- For inline command arguments or atomic query blocks, read [QueryHint](#queryhint). Command declarations contain suffix templates; `ChangeQuery` contains a complete instance. Keep legacy text parsing when structure is absent.\n- For query-scoped filters or sort controls, return `QueryResponse.Refinements` and read [references/refinements.md](references/refinements.md).\n- Before assigning refinement or result action hotkeys, read [references/hotkeys.md](references/hotkeys.md). Prefer defaults that avoid Wox window commands, launcher bindings, focused-editor commands, and shortcuts for the plugin's preview type. Check refinements and actions together for duplicates; choose another chord or leave `Hotkey` empty when it conflicts. Do not assume adding Shift makes a built-in chord available.\n- For `plugin.json`, `SettingDefinitions`, `QueryRequirements`, validators, dynamic settings, and feature flags, read `references/plugin_json_schema.md` first.\n- When implementing an SDK or single-file SDK plugin, also register Plugin Tools in `init()` for capabilities other plugins should be able to call. Query results and actions stay for the user; tools expose the same work as structured operations. Read `references/plugin_tools.md` first. Requires Wox >= 2.4.5 (`MinWoxVersion` `\"2.4.5\"` or newer). Do not declare tools in `plugin.json`.\n- SDK and single-file SDK plugins should support MRU unless the plugin is clearly unsuitable. Declare the `mru` feature with `HashBy` `identityKey`, put restore identity on action `ContextData`, and register `OnMRURestore` / `on_mru_restore` in `init()`. The restored result must use the same `IdentityKey` as the original result. The restore callback must return immediately from memory or local cache. Wox waits 300ms for each start-page MRU restore, then discards that item, logs the timeout, and shows the next MRU item. Do not fetch, scan disk, or call host APIs inside the callback. Skip MRU only for context-dependent, one-shot, diagnostic, or inbox-style plugins, and say why in the implementation notes.\n- Persist user settings through the Public API (`GetSetting` / `SaveSetting` / `SetSetting` / `OnSettingChanged`, or Python `get_setting` / `save_setting` / `set_setting` / `on_setting_changed`). A normal setting write is cloud-synced and follows the user across machines. Use these APIs for preferences, API keys, favorites, and account configuration.\n\n### Cache stays out of the settings API\n\nAnything the plugin can rebuild is cache: fetched JSON, subject or entity snapshots, search indexes, downloaded files, and thumbnails. Write that data under the plugin cache folder. Do not pass it to `SaveSetting`, `SetSetting`, `save_setting`, or `set_setting`.\n\nPlugin settings are cloud-synced. Each settings write becomes a sync record and is copied to the user's other devices, including a hidden key that is absent from `SettingDefinitions`. A cache blob stored this way is uploaded on every refresh and fills sync history. `IsPlatformSpecific` still syncs; it only keeps a separate value per operating system. `IsLocal` / `is_local` is for a small machine-local preference that must remain in the settings store, such as a window position. It is not a place for cache.\n\n- Call `GetCacheFolder(ctx)` / `get_cache_folder(ctx)` once in `init()`, keep the path, and write cache files under it.\n- The folder is `~/.wox/cache/plugins/<plugin-id>/`. Wox creates it and deletes it when the plugin is uninstalled.\n- Do not invent a `cache/`, `tmp/`, `downloads/`, or `data/` directory beside the plugin file, under user data, or under a hardcoded name.\n- When authoring `SettingDefinitions`, always decide whether each setting is platform-specific before shipping it. Wox cloud sync replicates normal plugin settings across devices, so local paths, executable paths, shell commands, hotkeys, system integrations, browser profiles, and application paths should usually set `IsPlatformSpecific: true`. Account IDs, API keys, remote service hosts, and cross-platform user preferences should usually keep `IsPlatformSpecific: false`.\n- Use `DisabledInPlatforms` only to disable a setting on selected platforms. It does not isolate stored values; use `IsPlatformSpecific` when the value must differ per platform after cloud sync.\n- When a plugin cannot run a query without required settings such as access keys, declare those requirements in metadata `QueryRequirements` instead of returning ad hoc setup results from `query()`.\n- Query refinements (type filters, sort modes, and similar query-scoped chips) belong on `QueryResponse.Refinements`, not in command syntax. When assigning a refinement `Hotkey`, use the platform primary modifier: `cmd+<key>` on macOS and `ctrl+<key>` on Windows/Linux. Detect the OS at runtime and emit the matching string; omit the binding if no suitable chord is available.\n- For ready-to-copy patterns such as validated textbox/select fields, editable tables, AI model selectors, and dynamic preview settings, read `references/settings_patterns.md`.\n- For Python settings APIs, note that helper builders are limited; advanced settings are often created by constructing `PluginSettingDefinitionItem` and value objects directly.\n\n### 2) Author result and action icons\n\n- Read `references/icons.md` before choosing any glyph. Result-row and plugin-identity icons may be colorful; Action Panel leading icons must not.\n- Scaffold templates use inline SVGs for the default plugin and result icons. Keep those defaults as SVG; use emoji or other formats only when deliberately choosing a result identity icon.\n- Prefer a bundled monochrome verb from `assets/iconify/action/` (copy, open, execute/lightning, delete, edit, paste, add, search, settings). These SVGs already use `var(--wox-theme-icon-color)` so the Action Panel can tint them to the row label.\n- Do not use emoji, brand logos, the plugin mark, or mixed-color result art as the leading action icon. The panel only tints SVGs that contain the theme variable; anything else stays authored and looks inconsistent next to system actions.\n- Execute actions use the lightning verb (`action/execute.svg`), not a gear or play triangle. Settings actions use the gear.\n- For a new action metaphor, fetch a monochrome Iconify outline with `scripts/search_iconify.py` (it rewrites `currentColor` to the theme variable by default). Use `--no-wox-theme` only for colorful **result** icons.\n- Single-file SDK plugins cannot use relative image paths. Inline the SVG for actions; emoji/URL/base64 are acceptable for result identity only.\n\n### 3) Package and submit plugin\n\n- For SDK plugins cloned from templates, run `make package` inside the template repo.\n- Single-file SDK plugins embed JSON metadata in the file header. Keep `MinWoxVersion` as `\"2.4.2\"`.\n- **Publish a single-file SDK plugin** on a public GitHub gist. That is the simplest store host. Reference: https://gist.github.com/qianlifeng/04a9609de66eaa582a473f5852450ede\n  1. Create one public gist file named `Wox.Plugin.<Name>.js` or `Wox.Plugin.<Name>.py`. The store `DownloadUrl` path must end with `.js` or `.py` (a gist URL without that suffix will not install). Example: `gh gist create --public --desc \"Wox.Plugin.YouTube\" Wox.Plugin.YouTube.js`\n  2. A screenshot of the plugin running in Wox is required. If the user has not provided one, stop and ask for it; do not continue the store submission without it. Use a cropped Wox launcher screenshot that shows the query and the plugin's real results, like https://raw.githubusercontent.com/Wox-launcher/Wox.Plugin.ColorPicker/main/images/screenshot1.png. Do not submit an icon, a README image, source code, or a full-desktop capture. Upload the screenshot and icon to GitHub (drag them onto the gist page or a gist comment). Copy the resulting `https://gist.github.com/user-attachments/assets/<id>` URLs, for example `https://gist.github.com/user-attachments/assets/7502acdc-1ea5-4ef6-a3fb-31875353dabe`.\n  3. Then follow `wox-plugin-submit2store`: clone Wox and add a `store-plugin.json` entry. `Website` is the gist HTML URL, `DownloadUrl` is the gist raw URL including the filename (`https://gist.githubusercontent.com/<user>/<gist-id>/raw/Wox.Plugin.<Name>.js`), `IconUrl` and `ScreenshotUrls` are the user-attachments URLs. Runtime is `nodejs` or `python`. Do not ship a `.wox` for this plugin type.\n- For packaged SDK plugins, use `wox-plugin-submit2store` with a GitHub repository and `.wox` release. Ask the user before submitting to the store. The store entry still requires at least one public screenshot; do not submit while `ScreenshotUrls` is missing or empty.\n\n## Simulated tail tags\n\nPrefer a native `text` tail whenever the label is only text. Wox draws compact rounded rectangles and owns theme, selected-row colors, font rendering, and density scaling. Use at most three tails on one result; additional facts belong in the subtitle, copied text, or a preview.\n\nUse an SVG `image` tail only when an icon and label must share one tag. Match the current native text-tail geometry; do not reuse the old pill shape or outlined capsule examples. At normal density, the logical dimensions are:\n\n| Property | Value |\n| --- | --- |\n| Height | 22 |\n| Corner radius | 4 (`rx=\"4\"`), not half the height |\n| Side inset | 7 on each side; text-only width is measured text width plus 14 |\n| Font | 11, regular weight |\n| Border | None; omit `stroke` |\n| Default | Row foreground text; background uses the same RGB at alpha 13/255, or 24/255 when selected |\n| Success | Fill `#027A48`, label `#FFFFFF` |\n| Danger | Fill `#B42318`, label `#FFFFFF` |\n| Warning | Fill `#B54708`, label `#FFFFFF` |\n\nUse native `TextCategory` / `text_category` for semantic text tails. Status fills remain solid; ordinary metadata has a subtle background. Do not make every secondary fact a status badge just to add color.\n\nFor an icon-and-label SVG, width is `7 + icon width + gap + measured label width + 7`. Set `ImageWidth` to that width and `ImageHeight` to 22, or the launcher defaults to a 20px image slot. For example, a 90-unit tag starts with `<svg viewBox=\"0 0 90 22\" ...><rect width=\"90\" height=\"22\" rx=\"4\" fill=\"#027A48\"/>...`, with no stroke. Keep the image-tail corners consistent with adjacent native tags.\n\nImage tails keep their authored colors; Wox does not automatically apply text-tail selection or theme styling to them. For neutral metadata, prefer native text instead of hardcoding white text on a transparent SVG. If a custom image is necessary, use `GetThemeColors` / `get_theme_colors` to choose readable light/dark colors and include those colors in its cache key. Avoid claiming an SVG matches selected-row styling when the plugin has no selection state.\n\nDraw side-by-side icon labels as filled glyph paths inside the SVG. The SVG rasterizer does not draw general `<text>`. One `<text text-anchor=\"middle\">` whose `x` is the viewBox center is extracted and painted centered on the whole image; it is unsuitable for a label beside an icon because that shifts the intended spacing.\n\n## QueryHint\n\n`QueryHint` is optional semantic background guidance for `input` queries. It can\ncarry actual argument values, but must never turn continuous input into a mandatory\nform. Preserve normal caret movement, cross-element selection, deletion, clipboard,\nundo and IME behavior. Tab is optional. When editing invalidates a semantic boundary,\nkeep the user's text and discard unreliable metadata rather than blocking input.\n\n- Declare suffix elements in `Commands[].QueryHint`; `Aliases` use the same trigger.\n  Wox inserts the matched command prefix with reserved ID `command`. Static metadata\n  and `RegisterQueryCommands` / `register_query_commands` use the same model.\n- `ChangeQuery` always requires `QueryType` and complete `QueryText` for input,\n  or complete `QuerySelection` for selection. `QueryHint` is optional visual\n  enhancement, never a replacement for query content. An input hint must describe\n  exactly the supplied text, including trigger keyword, command, separators and values.\n  An invalid or mismatching hint is ignored; the supplied `QueryText` is used unchanged. Explicit `QueryText: \"\"` remains valid for clearing.\n  Python uses `ChangeQueryParam(query_type=QueryType.INPUT, query_text=\"set volume 50\",\n  query_hint=QueryHint(elements=[...]))`; `QueryHint` and `QueryElement` are SDK exports.\n- Elements have nonempty, unique `Id` values. `text` uses `Text` (including explicit\n  separators); `argument` uses `Value`, optional `Placeholder` and `Required`;\n  `block` uses atomic `Value`. A highlighted argument remains freely editable.\n- Placeholders support `i18n:` and never enter the query value or clipboard.\n  `Required` is descriptive: validate empty values and business constraints before\n  offering or executing actions. Querying itself must not perform the action.\n- Read values by ID from `query.QueryHint.Elements` (Node.js) or\n  `query.query_hint.elements` (Python). Keep legacy `Search` / `search` parsing when\n  the hint is absent; an empty argument is not an absent hint. Wox supplies a lossy\n  plain-text projection in existing query fields; do not reconstruct boundaries from it.\n- Complete commands preview hints; space or Tab activates the template. Whole-command\n  paste into ordinary text is not parsed into arguments. Reopening selects the entire\n  query for replacement; undo and history preserve hints when possible.\n- Keep the list flat; no nested elements, dropdowns, custom rendering or inline markup.\n  Hints never carry plugin identity or create a scope. Routing uses the normal query\n  text and explicit `QueryScope`; complete instances must include the trigger keyword\n  when needed (for example `gh issues `). If both text and a hint are passed to `ChangeQuery`,\n  the explicit query text remains authoritative; the hint must match it.\n- Use SDK or single-file SDK APIs. Verify the first supporting Wox/SDK release before setting\n  distribution requirements; the single-file runtime version floor alone is insufficient.\n- Validate blank/valid/invalid arguments, multiple arguments, whole-query replacement\n  after reopen, undo and the legacy path. Set Volume is the first built-in example.\n\nExample command suffix (Wox adds the command text):\n\n```json\n{\n  \"Command\": \"set-volume\",\n  \"Aliases\": [\"set volume\", \"volume\"],\n  \"QueryHint\": {\n    \"Elements\": [\n      { \"Id\": \"volume\", \"Kind\": \"argument\", \"Placeholder\": \"Volume (0–100)\", \"Required\": true }\n    ]\n  }\n}\n```\n\n## Runtime Requirements\n\nWox enforces the same interpreter floors for SDK plugins and single-file SDK plugins. Store install fails, and queries show a setup result, when the machine is below these versions:\n\n- **Python**: 3.10 or later\n- **Node.js**: 20 or later\n\nDo not target older interpreters. Single-file SDK plugins run inside Wox's existing Python/Node runtime host and require **Wox 2.4.2 or later** (`MinWoxVersion`: `\"2.4.2\"`).\n\n## Resources\n\n- scripts: `scripts/scaffold_wox_plugin.py`, `scripts/detect_local_runtime.py`, `scripts/search_iconify.py`\n- references: `references/plugin_overview.md`, `references/scaffold_nodejs.md`, `references/scaffold_python.md`, `references/sdk_nodejs.md`, `references/sdk_python.md`, `references/plugin_json_schema.md`, `references/settings_patterns.md`, `references/plugin_i18n.md`, `references/icons.md`, `references/refinements.md`, `references/hotkeys.md`, `references/plugin_tools.md`\n- assets: `assets/single_file_plugin_templates/`, `assets/iconify/action/`\n","frontmatter":{"name":"wox-plugin-creator","description":"Create, scaffold, implement, and package Wox plugins (nodejs, python, singlefile-python, singlefile-nodejs). Use when cloning official SDK templates, generating single-file SDK plugin templates, editing plugin.json metadata, defining SettingDefinitions and validators, wiring i18n, implementing plugin APIs, QueryResponse refinements, refinement and action hotkeys, structured query slots, Plugin Tools (RegisterPluginTool / InvokePluginTool), 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."},"isInternal":false,"tokens":5913,"sizeBytes":25443},{"name":"openai.yaml","path":".agents/skills/wox-plugin-submit2store/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-submit2store/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `.agents/skills/wox-plugin-submit2store/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-submit2store/agents/openai.yaml)","tokens":300,"sizeBytes":226},{"name":"store-plugin-entry.md","path":".agents/skills/wox-plugin-submit2store/references/store-plugin-entry.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-submit2store/references/store-plugin-entry.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/wox-plugin-submit2store/references/store-plugin-entry.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-submit2store/references/store-plugin-entry.md)","tokens":300,"sizeBytes":258},{"name":"SKILL.md","path":".agents/skills/wox-plugin-submit2store/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-submit2store/SKILL.md","title":"wox-plugin-submit2store","category":"anthropic-skill","format":"markdown","content":"---\nname: wox-plugin-submit2store\ndescription: Submit a Wox plugin to the official store by ensuring the user has a reusable fork of Wox-launcher/Wox, checking whether the plugin ID already exists in store-plugin.json, adding a new store entry when missing, and preparing a pull request to Wox-launcher/Wox. Single-file SDK plugins should be hosted on a public GitHub gist. Do not open the store pull request unless ScreenshotUrls contains at least one public screenshot of the plugin running in 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.\n---\n\n# Wox Plugin Submit2store\n\n## Overview\n\nSubmit a plugin 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. A store entry requires at least one public screenshot. Do not submit with an empty or omitted `ScreenshotUrls`, and do not open a PR that says a screenshot will be added later.\n\nFor **single-file SDK plugins**, host the plugin on a public GitHub gist. That is the simplest store delivery. Do not require a GitHub repository, `plugin.json`, or a `.wox` package. Example: https://gist.github.com/qianlifeng/04a9609de66eaa582a473f5852450ede\n\n## Workflow\n\n1. Ensure the user already has a fork of `Wox-launcher/Wox`, or create one.\n2. Read the current plugin (packaged repo, or the single-file `.js`/`.py` header) before touching the store repo.\n3. Validate that the plugin has enough public metadata and release assets for a store entry, including at least one public screenshot of the plugin running in Wox.\n4. Clone the user's fork into a temporary directory and add `upstream` for `https://github.com/Wox-launcher/Wox`.\n5. Check upstream `store-plugin.json` for the current plugin ID.\n6. Stop and tell the user not to submit when the ID already exists.\n7. Add the new store entry when the ID is absent.\n8. Commit on a branch in the fork and open a PR to `Wox-launcher/Wox`.\n\n## Ensure A Fork Exists First\n\nTreat fork setup as the first gate. Do not clone or edit a working copy until one of these is true:\n\n- the user already has a fork of `Wox-launcher/Wox`\n- the current authenticated GitHub user can create one now\n\nUse this order:\n\n1. Check whether the user already has a fork and reuse it when present.\n2. If `gh` is available and authenticated, create the fork from the CLI.\n3. If `gh` is unavailable, unauthenticated, or fails, send the user to the web fork flow and continue only after the fork exists.\n\nFor CLI-driven fork handling:\n\n- prefer reusing an existing fork instead of creating a new one\n- if a fork is missing, create it with GitHub CLI\n- after the fork exists, treat the fork as `origin` and the official repo as `upstream`\n\nFor web fallback:\n\n- direct the user to `https://github.com/Wox-launcher/Wox/fork`\n- wait for the user to confirm the fork is ready\n- continue by cloning the fork repository, not the upstream repository\n\nWhen the user has direct write access to `Wox-launcher/Wox`, a fork is not required. Otherwise, do not assume direct push access.\n\n## Read Local Metadata First\n\nFor a **single-file SDK plugin**, read the JSON metadata header in the live `.js` or `.py` file (usually `~/.wox/wox-user/plugins/single-file/Wox.Plugin.<Name>.js`). Prefer a public gist as `Website` / `DownloadUrl`. Upload the screenshot and icon to GitHub and use `https://gist.github.com/user-attachments/assets/<id>` URLs for `IconUrl` and `ScreenshotUrls`.\n\nFor a **packaged SDK plugin**, read at least:\n\n- `plugin.json`\n- `package.json` when version information needs confirmation\n- local screenshots or icon files when URLs need to be derived\n- git remotes to determine the GitHub repository URL\n\nExtract or derive these values:\n\n- plugin `Id`\n- `Name`\n- `Author`\n- `Version`\n- `MinWoxVersion`\n- `Runtime`\n- `Description`\n- `Website` (gist HTML URL, or GitHub repository URL)\n- `DownloadUrl` (gist raw `.js`/`.py` URL, or `.wox` release asset)\n- public icon URL\n- required screenshot URLs: at least one public image of the plugin running in Wox\n- supported operating systems\n\nStop and ask the user to fix the source first when any of these conditions hold:\n\n- metadata still contains template placeholders such as `{{.Id}}` or `{{.Name}}`\n- a single-file plugin has no public gist whose raw URL path ends with `.js` or `.py`\n- a packaged plugin has no public repository URL or no installable `.wox` release asset\n- there is no screenshot, `ScreenshotUrls` would be empty or omitted, or the only screenshot is local and has no stable public URL\n- the icon is only local and no stable public URL can be formed\n\n## Clone The Fork And Check For Duplicates\n\nClone 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`.\n\nInspect `store-plugin.json` from the current upstream default branch and search by the exact plugin ID from the local metadata.\n\nWhen the ID already exists:\n\n- do not modify `store-plugin.json`\n- tell the user that the plugin is already listed\n- include the existing matching entry or its location so the user can verify it quickly\n\nWhen the ID does not exist:\n\n- continue to create a new entry\n- preserve the file's existing formatting and ordering style\n\n## Build The Store Entry\n\nUse the field template and sourcing rules in [references/store-plugin-entry.md](./references/store-plugin-entry.md).\n\nApply these rules while building the JSON object:\n\n- Keep `Id`, `Name`, `Author`, `Version`, `MinWoxVersion`, and `Runtime` aligned with local plugin metadata.\n- Prefer a plain `Description` string when no i18n payload exists.\n- Add `I18n` only when the repository already has trustworthy localized copy.\n- Convert local OS names to the store style: `Windows`, `Darwin`, `Linux` (`Macos` in plugin headers becomes `Darwin`).\n- Set `DateCreated` and `DateUpdated` to the current local timestamp in `YYYY-MM-DD HH:MM:SS`.\n- For a gist-hosted single-file plugin: `Website` is the gist HTML URL, `DownloadUrl` is the gist raw URL including the `.js` or `.py` filename, and `IconUrl` / `ScreenshotUrls` are `https://gist.github.com/user-attachments/assets/<id>` links. Runtime is lowercase `nodejs` or `python`.\n- For a packaged plugin: use the canonical repository URL for `Website`, the latest `.wox` release asset for `DownloadUrl`, and public raw image URLs for `IconUrl` / `ScreenshotUrls`.\n- `ScreenshotUrls` must contain at least one public URL. Do not omit the field, submit `[]`, or continue while telling the user that no screenshot is included yet. Ask for a screenshot and stop until one is uploaded. Use a cropped Wox launcher screenshot that shows the query and the plugin's real results, like https://raw.githubusercontent.com/Wox-launcher/Wox.Plugin.ColorPicker/main/images/screenshot1.png. Do not submit an icon, a README image, source code, or a full-desktop capture.\n\nBefore editing `store-plugin.json`, re-check that the generated URLs and filenames match the gist file name or the packaged repository layout.\n\n## Prepare The PR\n\nAfter editing the cloned fork workspace:\n\n1. Create a branch such as `codex/add-<plugin-name>-store-entry`.\n2. Commit only the `store-plugin.json` change.\n3. Push to the user's fork.\n4. Open a PR targeting `Wox-launcher/Wox`.\n\nUse a concise PR title such as `Add <Plugin Name> to store`.\n\nUse a PR body that includes:\n\n- what plugin was added\n- the gist or repository URL\n- the download URL\n- every public screenshot URL. Stop instead of opening the PR when this list is empty\n\n## Report Back To The User\n\nAlways end with one of these outcomes:\n\n- `Already listed`: explain that no submission is needed.\n- `Ready to submit`: summarize the new store entry and PR URL.\n- `Waiting for fork`: tell the user to finish the web fork flow before continuing.\n- `Blocked`: list the missing metadata or missing public assets that prevented submission.\n","frontmatter":{"name":"wox-plugin-submit2store","description":"Submit a Wox plugin to the official store by ensuring the user has a reusable fork of Wox-launcher/Wox, checking whether the plugin ID already exists in store-plugin.json, adding a new store entry when missing, and preparing a pull request to Wox-launcher/Wox. Single-file SDK plugins should be hosted on a public GitHub gist. Do not open the store pull request unless ScreenshotUrls contains at least one public screenshot of the plugin running in 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."},"isInternal":false,"tokens":1895,"sizeBytes":8107},{"name":"openai.yaml","path":".agents/skills/wox-test-ensurance/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-test-ensurance/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `.agents/skills/wox-test-ensurance/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-test-ensurance/agents/openai.yaml)","tokens":300,"sizeBytes":216},{"name":"SKILL.md","path":".agents/skills/wox-test-ensurance/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-test-ensurance/SKILL.md","title":"wox-test-ensurance","category":"anthropic-skill","format":"markdown","content":"---\nname: wox-test-ensurance\ndescription: Use when the user invokes Wox test assurance or asks to run Wox tests; direct invocation is explicit permission to execute the current core, Go UI unit, and native smoke suites and fix failures until they pass.\n---\n\n# Wox Test Ensurance\n\n## Overview\n\nDrive Wox test assurance from the repository root until the core tests, headless Go UI tests, and native Go UI smoke tests 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.\n\n## Invocation Contract\n\nIf this skill is explicitly invoked, the user has already authorized the complete Wox test assurance workflow: `make test`, `make test-go-ui-unit`, and `make smoke`. Do not stop after summarizing a plan or ask for extra confirmation.\n\nIf the user asks for one exact command, such as `make test`, run only that requested command and fix its failures. Do not silently expand an exact command request into native UI smoke testing.\n\nUse the active Wox checkout containing the root `Makefile` and `wox.core` directory. Do not assume a fixed drive or checkout path.\n\n## Preflight\n\nBefore running the suite, ensure no local Wox instance or VS Code-launched Wox debug process from the active checkout is still running. Force-stop matching processes; stale processes can hold ports or keep old state alive, and native smoke tests must own the Wox process they exercise.\n\nUse a Windows PowerShell check like this from the repository root:\n\n```powershell\n$repo = (Resolve-Path \".\").Path\n$woxProcesses = Get-CimInstance Win32_Process | Where-Object {\n    $name = $_.Name\n    $cmd = $_.CommandLine\n    $exe = $_.ExecutablePath\n    $isWoxBinary = $name -in @(\"Wox.exe\", \"wox.exe\", \"wox.core.exe\", \"__debug_bin.exe\")\n    $isWoxDebug = $name -in @(\"dlv.exe\", \"__debug_bin.exe\") -and $cmd -like \"*$repo*\"\n    $isRepoRuntime = ($exe -like \"$repo*\") -and ($name -like \"*wox*\")\n    $isWoxBinary -or $isWoxDebug -or $isRepoRuntime\n}\n$woxProcesses | ForEach-Object { Stop-Process -Id $_.ProcessId -Force }\n```\n\nIf stopped processes are found, mention them briefly in the working update or final summary.\n\n## Workflow\n\n1. Confirm the current directory is the Wox repository root, then begin without asking whether to run tests.\n2. Run the preflight process cleanup and force-stop any matching Wox/runtime debug process.\n3. Run `make test` for the core integration suite.\n4. Run `make test-go-ui-unit` for retained-widget, automation-contract, launcher, and driver tests. This suite does not open a native window.\n5. Run `make smoke` for the real single-process Go UI. On headless Linux, set `GO_UI_SMOKE_RUNNER=\"xvfb-run -a\"`.\n6. For each failure, capture the package or smoke case, test name, command output, and relevant logs, then investigate and fix the root cause.\n7. After any fix, format only the files touched according to Wox project style, then rerun the affected command.\n8. Before claiming completion, rerun every command required by the invocation contract from the repository root. Smoke cases may be targeted while diagnosing, but explicit test assurance ends with the complete `make smoke` suite.\n\n## Failure Triage\n\nPrefer this order:\n\n1. Check whether recent implementation changes broke product behavior, API contracts, async ordering, platform handling, or persisted state.\n2. Inspect the failing test's intended behavior and compare it with the current product contract.\n3. Fix production code when the test exposes a real regression.\n4. Change an existing test only when evidence shows the product behavior is correct and the assertion/setup is outdated, flaky, or testing the wrong layer.\n5. Do not add new tests unless the user explicitly asks for new test coverage.\n\nUse targeted reruns only while narrowing a failure. They are not final proof. The final proof is every suite required by the invocation contract passing.\n\n## Wox-Specific Notes\n\n- Wox runs in mixed Windows and WSL environments. Verify the shell, path, and repo root before treating a runner failure as a code failure.\n- If a shell shim or external tool prevents the real command from starting, isolate the environment problem, use the closest repo runner only for diagnosis, and do not report success until the requested `make` command passes.\n\n## Completion Checklist\n\n- Every command required by the invocation contract passed from the Wox repository root.\n- Explicit test assurance includes successful `make test`, `make test-go-ui-unit`, and `make smoke` runs.\n- Any code or test edits are locally formatted with the relevant project formatter.\n- The final response includes the exact commands run and whether they passed.\n","frontmatter":{"name":"wox-test-ensurance","description":"Use when the user invokes Wox test assurance or asks to run Wox tests; direct invocation is explicit permission to execute the current core, Go UI unit, and native smoke suites and fix failures until they pass."},"isInternal":false,"tokens":1061,"sizeBytes":4724},{"name":"SKILL.md","path":".agents/skills/wox-theme-creator/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-theme-creator/SKILL.md","title":"wox-theme-creator","category":"anthropic-skill","format":"markdown","content":"---\nname: wox-theme-creator\ndescription: Design, create, and refine Wox theme JSON files, including schema v2 base colors, optional styles, transparency, platform overrides, and local debugging. Use for authoring themes or converting an existing theme while preserving its appearance.\n---\n\n# Wox Theme Creator\n\nCreate a deliberately designed theme with a coherent palette, readable states, and a valid authored JSON document. Prefer schema v2 for new themes. Preserve the requested output location and existing theme identity when editing; generate a fresh UUID for a new theme.\n\n## Embedded theme editor\n\nWhen invoked by Wox's theme editor, work on the supplied current draft and editable property list. These are the authoritative available fields. Apply the design guidance below; return only the requested JSON patch of changed properties, preserving unrelated values and theme identity. Do not require repository access, filesystem tools, or a new theme file. The editor validates the patch and handles preview, undo, and saving. A normal AI Chat or repository authoring session continues to use the document workflow below.\n\n## Source of truth\n\nPaths below are relative to the Wox repository root. Read the current implementation before choosing fields; do not invent theme tokens or copy resolved runtime values into a new theme.\n\n- `wox.core/common/theme_schema_v2.go`: complete v2 document, accepted fields, color/geometry defaults, validation, and platform resolution.\n- `wox.core/resource/themes/`: built-in themes as working examples.\n- `wox.core/common/theme_surfaces.go` and `theme_package.go`: image surface declarations, resource validation, and package parsing.\n- `wox.core/common/theme_schema_v1.go`: legacy wire format and behavior, needed when converting an old theme.\n- `wox.core/common/theme_runtime.go` and `theme.go`: independent runtime representation, schema dispatch, and Wox version checks. These are not the authored JSON schema.\n\nEach schema owns its complete document and parser. Missing `SchemaVersion` or historical zero means v1. Loading must not rewrite old files. Changing v2 default semantics would change sparse themes; a new format belongs in a separately registered schema, not a retrofit of v1 or v2.\n\n## Image-backed themes\n\nWox 2.4.4 adds optional image surfaces to schema 2. Existing v1/v2 JSON files,\ncolor defaults, window materials, and Action Panel placement are unchanged.\nUse `MinWoxVersion: \"2.4.4\"` when publishing a theme using these fields.\n\n### Package layout\n\nA `.wox-theme` file is a ZIP archive with `theme.json` at its root, not inside\nan enclosing folder:\n\n```text\nming.wox-theme\n  theme.json\n  assets/lacquer.png\n  assets/palace-frame.png\n  assets/crest.png\n```\n\nOpen the package with Wox, or select the file and invoke Wox's selection query.\nThe installer shows its name and an Install action. Installation validates all\nentries before replacing `<theme-directory>/<ThemeId>/`; failed staging leaves\nthe previous package intact. Plain `<ThemeId>.json` themes remain supported.\nResource-backed themes are excluded from Cloud Sync.\nTheme editor color changes and Save As retain the image declarations and assets.\n\nThe package accepts PNG and JPEG images. Paths are case-sensitive, slash-separated,\nrelative to the package root. Absolute paths, traversal, symlinks, Windows device\nnames, and case-colliding archive entries are rejected. Limits are 128 archive\nentries, 32 MiB uncompressed data, and 16 megapixels across all images. Nine-slice\nsource cuts must leave a nonempty center. Assets for inactive platforms must also\nbe included. No network image URLs or executable theme code are supported.\n\n### Example theme.json\n\n```json\n{\n  \"SchemaVersion\": 2,\n  \"MinWoxVersion\": \"2.4.5\",\n  \"ThemeId\": \"6cf090bd-ef04-44e9-aa61-cbe0e1dc2275\",\n  \"ThemeName\": \"明\",\n  \"BaseBackgroundColor\": \"#721D16\",\n  \"BaseTextColor\": \"#FFF0CA\",\n  \"BaseAccentColor\": \"#F4C453\",\n  \"AppBackgroundColor\": \"transparent\",\n  \"OverlayBackgroundColor\": \"#721D16\",\n  \"OverlayFontColor\": \"#FFF0CA\",\n  \"Surfaces\": {\n    \"App\": {\n      \"ContentInsets\": {\"Top\": 110, \"Right\": 48, \"Bottom\": 32, \"Left\": 48},\n      \"Background\": {\n        \"Source\": \"assets/lacquer.png\",\n        \"Mode\": \"tile\",\n        \"Size\": {\"Width\": 128, \"Height\": 128}\n      },\n      \"Frame\": {\n        \"Source\": \"assets/palace-frame.png\",\n        \"Mode\": \"nineSlice\",\n        \"Slice\": {\"Top\": 160, \"Right\": 96, \"Bottom\": 96, \"Left\": 96},\n        \"Insets\": {\"Top\": 80, \"Right\": 48, \"Bottom\": 48, \"Left\": 48}\n      },\n      \"Decorations\": [{\n        \"Source\": \"assets/crest.png\",\n        \"Anchor\": \"topCenter\",\n        \"Offset\": {\"X\": 0, \"Y\": 0},\n        \"Size\": {\"Width\": 120, \"Height\": 110}\n      }]\n    },\n    \"ActionContainer\": {\n      \"Background\": {\"Source\": \"assets/lacquer.png\", \"Mode\": \"tile\"}\n    }\n  }\n}\n```\n\n### Surface contract\n\n`InnerShadow` optionally shades inward over child fills to make a panel appear\nrecessed into its frame. It accepts `Color`, `Width` (0..64 logical units),\n`Radius` and `Insets` (each 0..4096). Insets locate the inner panel relative to\nthe surface; match App ContentInsets and AppContentBorderRadius for an inset\nlauncher. For example: `\"InnerShadow\": {\"Color\":\"rgba(25,42,55,0.25)\",\n\"Width\":7,\"Radius\":10,\"Insets\":{\"Top\":29,\"Right\":29,\"Bottom\":29,\"Left\":29}}`.\nThe shadow fades to transparent inward, follows display density, and allocates\nno image cache. Keep its width within the content padding so text stays clear.\nIt paints after children, unlike image layers; omit it to preserve existing\nappearance. This optional schema 2 extension requires Wox 2.4.5.\n\nThe supported regions are `App`, `QueryBox`, `ResultItemActive`,\n`ActionContainer`, `Preview`, and `Toolbar`. Each accepts the same optional\n`Background`, `Frame`, and `Decorations` declarations. The generic preview shell\nis supported; embedded web/native content and specialized previews still own\ntheir inner rendering.\n\nLayers draw in this order: existing color/material, Background, Frame,\nDecorations, existing borders, interactive contents. Images do not introduce\nhit targets. Transparent image pixels reveal the underlying fill; they do not\nerase it. Author a transparent App background and custom chrome explicitly when\nneeded. AppBorder fields still disable the OS material as before. Native\narbitrary-shape input regions are not part of this extension.\n\n`Background` and `Frame` accept these modes:\n\n| Mode        | Geometry                                                                                             |\n| ----------- | ---------------------------------------------------------------------------------------------------- |\n| `stretch`   | Scale the image to the surface bounds.                                                               |\n| `tile`      | Repeat at `Size` logical units; if absent, use the image's pixel dimensions as logical units.        |\n| `nineSlice` | Cut at `Slice` source pixels, draw borders at `Insets` logical units, stretch the remaining regions. |\n\nStretch and tiled images follow the surface corner radius. Nine-slice images\nretain their authored alpha silhouette; put rounded corners in the asset.\nFour corners retain their destination size unless the surface is too small,\nin which case opposing borders shrink proportionally. A frame's center is\nalso drawn, so use a transparent center when only an outline is wanted.\nTiled backgrounds retain only their latest raster size, at the active display's\nphysical pixel density, capped by the asset's authored density. Moving between\ndisplays rebuilds this cache; `Size` remains in logical units. The limit is 16\nmegapixels per background; larger requests use the existing color fallback.\nNine-slice textures are likewise derived at display density from the shared\ndecoded source: borders and repeated tiles are downsampled to their logical\nsize times the display scale (never upsampled), while an axis that stretches\nto the surface keeps its source pixels. Only the latest display scale is\ncached per surface.\nReuse the same `Source` for shared textures: decoded pixels are shared across\nsurfaces, while each surface keeps its own size cache. PNG file size is not its\nmemory cost: decoded RGBA uses roughly width × height × 4 bytes, plus raster\nand native renderer caches. Use reasonably sized texture tiles.\n\nDecorations require `Source`, `Anchor`, and a positive logical `Size`; `Offset`\ndefaults to zero. Anchors are `topLeft`, `topCenter`, `topRight`, `centerLeft`,\n`center`, `centerRight`, `bottomLeft`, `bottomCenter`, and `bottomRight`.\nOffsets are in logical units and decorations stay clipped to their owner.\nDecorations are static and do not change control layout.\n\nOnly `App` accepts `ContentInsets`. These add to the existing uniform\n`AppContentInset`, outside the inner content panel and existing `AppPadding`.\nThey reserve space for the entire launcher body, including the Toolbar and\nAction Panel. Frame insets do not implicitly add layout padding.\n\nPlatform and variant `Surfaces` objects merge **by region**. A supplied region\nreplaces that region's whole declaration; omitted regions inherit. Set a region\nto `null` to remove it, or `Surfaces: null` to remove every inherited surface.\nExisting scalar platform override semantics are unchanged.\n\n```json\n{\n  \"windows\": {\"Surfaces\": {\"Toolbar\": null}},\n  \"linux\": {\"Surfaces\": null}\n}\n```\n\nThere is no separate package format version; the schema version belongs to\n`theme.json`.\n\nFloating overlays (text notifications, tooltips, image preview, timer, dictation,\nand permission prompts) are not the launcher window. When `Surfaces` uses an\nimage, set `OverlayBackgroundColor` and `OverlayFontColor` explicitly.\nImage-backed themes usually leave `AppBackgroundColor` transparent so the frame\nasset is the window; overlays have no frame, so that transparent color lets the\ndesktop show through and the text becomes unreadable. Use an opaque fill that\nmatches the readable content surface, and a text color that contrasts with it.\nDo not copy the transparent window color. Omitted overlay colors follow the\neffective `AppBackgroundColor` and `ActionItemFontColor`, which is correct only\nfor themes whose window fill is already a readable wash. These fields do not\nrecolor the launcher, Notes, or WebView windows. Authoring them requires Wox\n2.4.5.\n\n## Author the document\n\n### Localized name and description\n\nSchema v2 supports optional inline `I18n`, using the same locale-to-key map as\nplugin.json. Set `ThemeName` and `Description` to `i18n:` keys:\n\n```json\n{\n  \"ThemeName\": \"i18n:theme_name\",\n  \"Description\": \"i18n:theme_description\",\n  \"I18n\": {\n    \"en_US\": {\"theme_name\": \"Ming\", \"theme_description\": \"An imperial red and gold theme.\"},\n    \"zh_CN\": {\"theme_name\": \"明\", \"theme_description\": \"朱红与金黄的皇家主题。\"}\n  }\n}\n```\n\nProvide `en_US` as fallback, plus the intended languages (`zh_CN`, `ru_RU`,\n`pt_BR`, `ko_KR`, `ja_JP`). Missing translations fall back to English, then\nWox's built-in translations, then the original key. Literal text stays literal.\nTranslations are resolved for display and search; saved JSON retains the keys\nand translation map. `I18n` belongs at the root, not in platform overrides.\nThis extension uses schema 2 and requires Wox 2.4.4. Theme translations currently\nuse inline `I18n`; separate `lang/` files are not loaded.\n\nA minimal v2 document looks like this; replace the sample ID and name:\n\n```json\n{\n  \"SchemaVersion\": 2,\n  \"MinWoxVersion\": \"2.4.3\",\n  \"ThemeId\": \"66288aad-d3fa-493b-bc46-7e8e7280c40d\",\n  \"ThemeName\": \"Jade\",\n  \"BaseBackgroundColor\": \"rgba(28, 35, 37, 0.72)\",\n  \"BaseTextColor\": \"#E5ECE9\",\n  \"BaseAccentColor\": \"#70D6A6\"\n}\n```\n\nThe three base colors, ID, and name are required. Explicitly declare schema 2. Set `MinWoxVersion` to the release supporting the features used; check current built-ins rather than lowering the floor to make installation succeed. `Version` is the theme's own version, separate from schema and minimum Wox versions. Include truthful author, description, and URL metadata when available. Do not mark a custom theme as system-installed. Automatic appearance themes use `IsAutoAppearance`, `DarkThemeId`, and `LightThemeId`; their required base colors still provide a fallback.\n\nGroup overrides by surface: window, query/Glance/Attention, result container/items, Action Panel/items/query, preview/tags, toolbar/keycaps. Keep the document sparse; add overrides for intentional design differences.\n\n| Authored value                            | Meaning                                                  |\n| ----------------------------------------- | -------------------------------------------------------- |\n| Missing optional style                    | Inherit parent, or schema default at the root            |\n| `null` at the root                        | Same as omitted: schema default                          |\n| `null` on a platform or variant           | Clear the inherited value and restore the schema default |\n| Integer `0`                               | Explicit zero; never substitute a default                |\n| `transparent` or alpha zero               | Explicit transparency                                    |\n| Empty color, negative/fractional geometry | Invalid                                                  |\n\nColors accept `#RRGGBB`, `#RRGGBBAA` (alpha last), `rgb(r,g,b)`, `rgba(r,g,b,a)`, and `transparent`. RGB channels are 0–255; alpha is 0–1. Geometry uses logical units, not physical screen pixels.\n\nFont sizes are controlled by the application Interface size setting; do not add theme font-size overrides.\n\n## Default window shape and transparency\n\nUnless the user explicitly requests a custom app outline or window corners, omit `AppBorderColor`, `AppBorderWidth`, and `AppBorderRadius` at the root and all platform/variant levels. Do not infer a custom window outline or radius from a reference screenshot or a general request for a rounded visual style. Keep the system/default window shape and use a slightly translucent `AppBackgroundColor` by default (for example, alpha 0.90).\n\nIf the user explicitly requests a custom app outline or window corners, author the requested `AppBorder*` fields and default `AppBackgroundColor` to fully opaque (alpha 1). An explicit request for transparency or opacity overrides that default. QueryBox, result, preview, and Action Panel corner settings do not count as a request for custom window chrome. Toolbar and Action Panel may retain modest in-app translucency in either case.\n\nThese are theme-authoring defaults, not changes to schema parsing. Apply them when creating themes or when the user asks to restyle an existing theme; do not silently rewrite other existing themes. Keep `BaseBackgroundColor` independent when an explicit app background override is sufficient, so changing window alpha does not unintentionally change every derived surface.\n\n## Design the surfaces together\n\nStart with background, text, and accent roles. Optional colors derive independently from these roles; changing one optional token does not change another. Base alpha also affects derived colors. Consult the resolver for exact defaults instead of duplicating its entire catalog here.\n\n- For translucent themes, consider app, query, Action Panel, action query, preview, and toolbar backgrounds together. An opaque surface can hide translucency beneath it; layered alpha and native materials affect the final appearance.\n- V2 `AppContentInset` reserves a uniform logical inset around the entire launcher content, including the toolbar, previews, and floating panels. `AppContentBackgroundColor` paints the inner panel and `AppContentBorderRadius` rounds its background. Defaults are 0, transparent, and 0, preserving existing themes. These fields do not select custom window chrome: use a translucent `AppBackgroundColor` and omit `AppBorder*` to expose a native-material rim. Existing `AppPadding*` remains spacing inside the content panel. Child surfaces retain their own corner styles; the toolbar follows the panel's bottom corners.\n- Floating overlays use `OverlayBackgroundColor` and `OverlayFontColor`. Omitted values follow the effective `AppBackgroundColor` and `ActionItemFontColor`. They do not change the launcher, Notes, or WebView windows. Image-backed themes must set both explicitly; see Image-backed themes.\n- Set `ResultContainerPaddingTop` and `ResultContainerPaddingBottom` to the same value, normally 8, so the result list matches the built-in themes. The schema default is top 8 and bottom 0, so write both fields explicitly; omitting the bottom padding does not produce a matching gutter. Keep left and right at 0 unless a side inset is part of the design. Leave an existing theme's values unchanged unless that spacing is being authored.\n- V2 uses `ResultItemActiveIndicatorColor`, `ResultItemActiveIndicatorWidth`, `ResultItemActiveIndicatorInsetLeft`, `ResultItemActiveIndicatorInsetTop`, `ResultItemActiveIndicatorInsetBottom`, and `ResultItemActiveIndicatorBorderRadius` for the selected-result marker. Width defaults to 0, color to the base accent, and insets/radius to 0. Zero insets/radius reproduce the edge strip; use positive insets and radius for a short rounded marker. Reserve icon space with result-item padding; marker geometry does not shift content. The unreleased v2 `ResultItemActiveBorderLeftWidth/Color` fields were removed; v1 keeps its original fields. Check normal, selected, and hovered rows separately; `ResultItemHoverBackgroundColor` controls hover.\n- `QuerySeparatorColor`, `QuerySeparatorThickness`, `QuerySeparatorPaddingLeft`, and `QuerySeparatorPaddingRight` draw the line under the query. Thickness is the stroke size in logical pixels; omitted thickness draws nothing. Left and right padding inset the line from the window edges, and omitted padding runs it across the window. The line does not follow the query box corner radius.\n- Action Panel border fields are `ActionContainerBorderColor`, `ActionContainerBorderWidth`, and `ActionContainerBorderRadius`. `ActionContainerDividerColor` controls internal separators independently of `PreviewSplitLineColor`.\n- Toolbar primary actions (default/bare Enter) support `ToolbarPrimaryFontColor` and `ToolbarPrimaryHotkey{Font,Background,Border}Color`. Omitted values inherit the corresponding effective toolbar colors; explicit transparency is preserved. Configure emphasis here rather than relying on automatic dimming of other actions.\n- Keycaps have three independent v2 groups: `ToolbarHotkey{Font,Background,Border}Color`, `ActionItemHotkey{Font,Background,Border}Color`, and `ActionItemActiveHotkey{Font,Background,Border}Color`. All accept explicit transparency. Omitted values derive from base colors, not another surface's overrides: normal text uses secondary text and border uses divider; active text/border use base text; backgrounds default transparent. Set active colors explicitly for contrasting selection backgrounds (for example, white keycaps on blue). The unreleased shared `Hotkey*` fields were removed. Keep keycaps readable without competing with labels.\n- `PreviewBorderRadius` and `PreviewTagBorderRadius` control generic preview and metadata-tag corners in logical units. Omitted values retain 8; zero is square.\n- Preview has `PreviewBackgroundColor`, `PreviewBorderColor`, existing text/property/selection colors, and `PreviewTagFontColor`, `PreviewTagBackgroundColor`, `PreviewTagBorderColor`. Generic preview tokens do not necessarily control specialized chat, terminal, media, or native/web surfaces.\n- Glance has `GlanceFontColor`, `GlanceIconColor`, `GlanceBackgroundColor`, and `GlanceHoverBackgroundColor`. Raster images retain their own colors.\n- Attention has `AttentionFontColor`, `AttentionIconColor`, `AttentionBackgroundColor`, `AttentionBorderColor`, `AttentionHoverBackgroundColor`, and `AttentionHoverBorderColor`. Omitted values match Glance: transparent idle fill/border and a query-text hover wash. Raster images retain their own colors.\n- Shared scrollbars expose `ScrollbarThumbColor`, `ScrollbarThumbHoverColor`, `ScrollbarThumbActiveColor`, `ScrollbarWidth`, `ScrollbarHoverWidth`, and `ScrollbarBorderRadius`. Widths default to 3/7 logical units; omitted radius follows half the animated thickness. Zero width/radius and transparent colors are explicit. Horizontal bars use width as thickness. Native/web-owned scrollbars remain outside this contract.\n- Filters use `RefinementButton{Font,Icon,Background,Border,HoverBackground}Color` and their `RefinementButtonActive...Color` counterparts. Active means expanded or a non-default filter is applied. The expanded strip uses `Refinement{Background,Border,Title,Divider,Hotkey}Color`; options use `RefinementItem{Font,Background,HoverBackground}Color` and `RefinementItemActive...Color`. These are JSON overrides; preserve explicit alpha for every state, including selected-hovered options. Control dimensions remain launcher-density geometry.\n- `AppBorderColor`, `AppBorderWidth`, and `AppBorderRadius` control launcher outer chrome. Width and radius use logical units. Zero width disables the outline. Zero radius is an explicit square corner for the painted outline. Omitted fields keep the previous platform behavior. Set width explicitly when designing an outline. If any one of these three fields is authored, every platform disables system window material (Windows Acrylic, macOS Liquid Glass/vibrancy, Linux compositor blur) so Go UI can paint the outline. Windows applies a DPI-scaled region plus DirectComposition clip only when a radius is authored, including 0; color or width alone leaves DWM's default corners. macOS detaches the glass/vibrancy wrapper and clips the renderer layer to the authored radius, but the launcher stays a titled window, so AppKit still masks the window and its shadow to the system corner radius. `AppBorderRadius: 0` therefore cannot produce fully square corners on macOS. Linux turns compositor blur off and paints the authored radius, including 0. Result, query, preview, and Action Panel radii are in-app geometry and can be square. Theme-color alpha still controls ordinary window transparency. Verify shadow and transparency on each target OS before promising identical results.\n\n## Explain the custom-chrome tradeoff\n\nWhen creating, editing, or recommending a theme that authors any of `AppBorderColor`, `AppBorderWidth`, or `AppBorderRadius`, explicitly tell the user that this disables system window material on every platform (Acrylic, Liquid Glass, Linux compositor blur). The native window switches to transparent composition; theme-color alpha controls ordinary window transparency. This does not disable Wox's own in-app frosted-glass surfaces. Include this limitation in the delivery message, not only in JSON or internal notes.\n\nToolbar and Action Panel retain their application-rendered frosted-glass transparency independently of the native window material. When designing custom-chrome themes, consider modest transparency in `ToolbarBackgroundColor` and `ActionContainerBackgroundColor` (for example, alpha around 0.88–0.90), while keeping text readable. Do not make these surfaces opaque merely because custom window chrome is enabled. An opaque `AppBackgroundColor` can remain intentional: these panels reveal or blur underlying app content, not the desktop through that opaque background.\n\nAn explicit zero (`AppBorderWidth: 0` or `AppBorderRadius: 0`) also selects this path. To restore system material, omit all three fields. A child platform or variant can restore material after a parent outline by setting those fields to `null`; that clears the inherited chrome instead of painting a square window. Assigning a default-looking number does not restore the material. Background colors still need alpha below 1 to reveal anything underneath.\n\nSuggested user-facing wording: “主题只要设置了 AppBorderColor、AppBorderWidth 或 AppBorderRadius 中的任意一项，所有平台都不会再使用系统窗口材质（Windows Acrylic、macOS Liquid Glass、Linux 合成器模糊）。窗口改用普通透明合成，透明程度由主题颜色的 Alpha 决定。Toolbar 和 Action Panel 的应用内磨玻璃效果仍保留，可以适度保留透明度。若要恢复系统材质，需要移除这三项配置。子级平台或变体可以把这三项设为 null，用来取消父级圆角/描边并重新打开系统材质。”\n\nWhen `AppBorderRadius` is 0 at the root or on `macos`, including an explicit request for square window corners, also tell the user about the macOS window-shape limit in that same delivery message. Do not attach this warning to a positive radius, or to square result, query, preview, or Action Panel corners.\n\nSuggested user-facing wording: “在 macOS 上，启动器窗口外形和阴影仍由系统标题栏窗口决定。AppBorderRadius 设为 0 只会让 Wox 按直角绘制内容，系统仍会把窗口裁成圆角，无法得到完全直角。”\n\n## Platform overrides and compatibility\n\nResolution order is root authored values, then `windows`/`macos`/`linux`, then that platform's matching `variants` entry, then defaults. Read `theme_platform.go` for supported variant names. Omitted platform fields inherit the parent. JSON `null` on a platform or variant clears the inherited value so the schema default applies; this is how Hyprland can keep compositor blur after a shared Linux `AppBorderRadius`. Base colors may be overridden so dependent defaults derive from the effective palette. All platform variants are validated, including inactive ones.\n\nPreserve authored values and platform nodes when editing or saving. Never flatten a resolved platform theme into the source document. When explicitly converting v1, retain its effective appearance with explicit v2 overrides where defaults differ; verify zero values, aliases, and legacy contextual color behavior rather than only changing `SchemaVersion`.\n\n## Deliver and check\n\nFor local debugging, use the user's requested path; the normal user theme directory is `~/.wox/wox-user/themes/`. Use `<ThemeId>.json` for a plain color theme. For image-backed themes, deliver a `.wox-theme` package containing root `theme.json` and its assets; installed packages live under `<ThemeId>/`. Do not overwrite an unrelated theme or publish to the store as part of local authoring.\n\nValidate JSON and use Wox's actual parser/resolver to check fields, colors, platform nodes, and version compatibility. Existing checks live in `wox.core/common/theme_v2_test.go` and `theme_document_test.go`; for changes to parsing run `go test -tags 'sqlite_fts5,wox_automation' ./common` from `wox.core`. That suite validates the implementation, not an arbitrary new file: load the authored file through Wox or a focused parser check as well.\n\nWhen a running preview is available, inspect selected/hovered results, the Action Panel, keycaps, toolbar, preview/tags, and Glance. For transparency, compare against light and dark desktop content. Report which platforms were actually observed; do not claim native material behavior from a static JSON check.\n\nResource-backed themes are local-only for now: Cloud Sync skips their install, update, deletion, and snapshot payloads. Ordinary JSON themes continue to sync. Share image themes using the `.wox-theme` file.\n\n## Resizable frames: stretch versus repeat\n\nSchema v2 nine-slice images accept optional `\"Repeat\": {\"X\": \"tile\", \"Y\": \"stretch\"}`.\nEach omitted axis defaults to `stretch`; accepted values are `stretch` and `tile`.\n`Repeat` is invalid on whole-image `stretch` or `tile` modes. Existing declarations are unchanged.\n\nCorners retain their authored logical Insets. X controls the top/bottom middle strips;\nY controls the left/right middle strips. The center follows both axes. Tiling starts\nat the left/top of each slice; the final partial tile is clipped, never squeezed.\nTop/bottom tile width equals source strip width multiplied by actual logical strip\nheight divided by source strip height. Left/right tile height uses the corresponding\nwidth ratio. The center uses the first positive Insets/Slice ratio in Top, Bottom,\nLeft, Right order (or 1 if all are zero). Keep these ratios consistent for a uniform\nmaterial density. DPI is applied by the renderer; do not multiply Insets by display scale.\nVery small windows shrink opposing borders proportionally. A pathological slice that\nwould require more than 4096 tile draws falls back to stretching that slice; avoid tiny\nrepeat units and verify the maximum supported window size.\n\nUse stretching for flat fills and simple straight rules, tiling for roof tiles, woven\npatterns, rivets or bamboo, and fixed-size Decorations for crests, lettering and figures.\nNine-slice does not turn an arbitrary illustration into a seamless material. The full\nmiddle strip is the repeat unit: its two ends must match in height, color, lighting,\nalpha and motif phase. Do not include isolated statues in it. Keep curved-to-straight\ntransitions entirely within fixed corner slices; put cut lines only in straight,\nregular sections and preserve tangent continuity. Corners and adjacent strips need\nmatching scale as well as matching pixels. Inspect the join at both ends, not only\nrepeat-to-repeat seams. A clipped final motif can meet the far corner at a different\nphase; prefer a neutral join or a fixed decorative cap where this would be visible.\n\nFor an irregular Action/About panel, set ActionContainerBackgroundColor and its border\ncolor to transparent, remove the separate rectangular Background image, and provide\nan opaque interior inside a transparent-exterior Frame. This also skips the rectangular\nfloating material. Leave padding for the ornaments. App ContentInsets reserve draggable\nouter chrome; controls remain inside the reserved content bounds.\n\nVerify minimum, default and wide launcher widths, short and tall result lists, fractional\nDPI (125%, 150%), fixed crest proportions, partial tiles, alpha silhouette, and Action/\nAbout content clearance. Check the actual rendered UI before claiming seamless joins;\nimage generation and parser validation alone cannot establish that.\n","frontmatter":{"name":"wox-theme-creator","description":"Design, create, and refine Wox theme JSON files, including schema v2 base colors, optional styles, transparency, platform overrides, and local debugging. Use for authoring themes or converting an existing theme while preserving its appearance."},"isInternal":false,"tokens":6517,"sizeBytes":30167},{"name":"openai.yaml","path":".agents/skills/wox-visual-style/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-visual-style/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `.agents/skills/wox-visual-style/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-visual-style/agents/openai.yaml)","tokens":300,"sizeBytes":212},{"name":"visual-style-guide.md","path":".agents/skills/wox-visual-style/references/visual-style-guide.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-visual-style/references/visual-style-guide.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/wox-visual-style/references/visual-style-guide.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-visual-style/references/visual-style-guide.md)","tokens":300,"sizeBytes":244},{"name":"SKILL.md","path":".agents/skills/wox-visual-style/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-visual-style/SKILL.md","title":"wox-visual-style","category":"anthropic-skill","format":"markdown","content":"---\nname: wox-visual-style\ndescription: Design, implement, refactor, or review the visual style of Wox's portable Go UI under wox.core/ui. Use for Settings, dialogs, forms, tables, catalogs, management pages, shared Wox controls, typography, semantic colors, spacing, alignment, icons, control sizing, and default, hover, pressed, selected, focused, disabled, loading, empty, and error states. Also use to audit visual consistency or decide whether appearance belongs in launcher/component or launcher/view. Treat the Launcher query surface and Action Panel as explicit special contracts instead of forcing the ordinary Settings control-size system onto them.\n---\n\n# Wox Visual Style\n\nApply one coherent visual language to Wox Go UI without changing business behavior accidentally.\n\n## Load the visual contract\n\nRead [references/visual-style-guide.md](references/visual-style-guide.md) completely before designing, reviewing, or editing UI. Treat it as the sole visual policy for Wox Go UI. Treat production components and tests as implementation evidence; when they disagree with the guide, report or fix the implementation drift instead of silently redefining the guide from current code.\n\nKeep the guide at the level of cross-feature design principles and shared control conventions. Record feature-specific colors, dimensions, theme-field behavior, and bug-fix rationale in the owning code, tests, or domain documentation instead of appending them to the guide.\n\nAlso read the repository `AGENTS.md`, `README.md`, `Wox.code-workspace`, and `wox.core/ui/README.md` before refactors.\n\n## Classify the surface\n\nClassify the requested surface before applying size rules:\n\n- Apply the ordinary control system to Settings, dialogs, forms, tables, catalogs, onboarding management controls, and other application-management pages.\n- Keep the Launcher query, its accessories, results, toolbar, refinements, Glance, and Attention under launcher density and theme geometry.\n- Keep the complete Action Panel, including its filter and rows, under its own geometry contract.\n- Scale every interface element's text, line box, and the control that holds that text with `UiDensity`. Keep normal-density bases in `typography.go` and multiply them at draw time with `ControlTheme.Scaled` or the launcher density scale. Do not bake the current density into those bases, and do not multiply a size that was already scaled.\n- Keep native window controls and platform-owned dialogs under the platform contract.\n\nDo not use a special-surface exception to justify page-local styling elsewhere.\n\n## Inspect the current contract\n\n1. Inspect the nearest shared `Wox*` component and its focused tests.\n2. Inspect `launcher/component/wox_theme.go`, `launcher/component/typography.go`, and `launcher/theme.go` when colors or type are involved.\n3. Inspect relevant views for repeated literals, primitive interactive controls, and inconsistent state handling.\n4. Check whether the same semantic control exists on other production pages.\n5. Record current values separately from target values when auditing known drift.\n\nUseful focused searches include:\n\n```bash\nrg -n 'Wox(Button|TextField|Dropdown|Checkbox|Switch|IconButton)' wox.core/ui/launcher\nrg -n 'woxwidget\\.Gesture\\{' wox.core/ui/launcher/view\nrg -n 'TextStyle\\{Size:|Height:|Radius:|Color: woxui\\.Color' wox.core/ui/launcher/view\nrg -n 'BorderWidth: [0-9]+\\.|Radius: [0-9]+\\.|LineHeight: [0-9]+\\.|TextStyle\\{Size: [0-9]+\\.[0-9]' wox.core/ui/launcher\n```\n\nInterpret results in context. Primitive gestures are valid for page-specific pointer regions and tooltips; they are a defect when they recreate a reusable control contract.\n\n## Design or review the change\n\n1. Identify each element's semantic role, size tier, visual state, and alignment group.\n2. Use semantic theme roles and shared typography instead of raw colors or page-local type scales.\n3. Use the ordinary 32-unit control height only inside its defined scope. Preserve special Launcher and Action Panel geometry. Author only whole logical units for size, padding, gap, radius, border, font size, and line height.\n4. Align controls by interaction frame and centerline. Preserve the internal geometry of checkboxes and switches.\n5. Cover every applicable state from the state matrix, including non-color cues and accessibility semantics.\n6. Prefer an existing catalog name from `wox/common/icons` via `icons.Get`; add a new semantic name there before introducing a local asset. For theme-adaptive SVG paints, use `var(--wox-theme-icon-color)` explicitly; follow the SVG theme-color contract in [Components, icons, and content](references/visual-style-guide.md#components-icons-and-content).\n7. Check light and dark themes, long or translated text, narrow widths, scrolling, logical units, DPI boundaries, and disabled/error content.\n\nExpress alignment through layout primitives first: use `Align`, Flex main/cross-axis alignment, `Expanded`, or `Constrained` to center and place controls. Do not hand-calculate offsets such as `(rowHeight-controlHeight)/2`, or use padding as a substitute for alignment; improve the owning layout/component boundary when the existing primitives cannot express the relationship.\n\nWhen reviewing only, report concrete violations with the owning layer and recommended shared fix. Do not mutate files unless the user requested implementation.\n\n## Implement at the correct layer\n\n- Put reusable geometry, appearance, pointer states, focus treatment, and accessibility in `launcher/component`.\n- Keep page hierarchy, responsive composition, and genuinely page-specific spacing in `launcher/view`.\n- Keep mutable interaction state below `launcher.App` and preserve `widget.Boundary.Build` purity.\n- Centralize stable metrics used by multiple production surfaces. Do not add a token for a single local constraint.\n- Keep ordinary control size explicit through shared defaults or a semantic size API; do not copy the same height into call sites.\n- Keep Launcher and Action Panel metrics independent so ordinary component changes cannot alter their geometry accidentally.\n- Prefer layout components over manual alignment math. Center controls with `Align` or Flex alignment and reserve padding for actual content insets, not positional compensation.\n- Add English intent comments only for non-obvious visual constraints or exceptions.\n\nPreserve existing behavior unless the request includes interaction changes. A visual refactor must not alter values, callbacks, focus order, IME ownership, keyboard activation, scrolling, or window lifecycle.\n\n## Validate proportionally\n\n1. Format changed Go files with `gofmt`.\n2. Run the narrowest affected component and view tests from `wox.core`.\n3. Run `GOCACHE=/tmp/wox-go-cache make test-go-ui-unit` from the repository root when shared components, widget behavior, or broad launcher UI changed.\n4. Add focused source tests for size tiers, alignment, states, semantics, and special-surface isolation.\n5. Review the diff for duplicated literals and accidental Launcher or Action Panel changes.\n\nSource inspection is the default. Request permission before launching Wox for runtime comparison unless the user already requested it. Escalate to serial screenshots when font measurement, DPI, animation, clipping, compositing, native focus, or platform rendering leaves a meaningful visual ambiguity.\n\n## Report completion\n\nReport:\n\n- surface classification and size tier;\n- shared component or view ownership;\n- visual states covered;\n- known implementation drift found or fixed;\n- formatting and tests actually run;\n- whether validation was source-only or included an approved runtime comparison.\n","frontmatter":{"name":"wox-visual-style","description":"Design, implement, refactor, or review the visual style of Wox's portable Go UI under wox.core/ui. Use for Settings, dialogs, forms, tables, catalogs, management pages, shared Wox controls, typography, semantic colors, spacing, alignment, icons, control sizing, and default, hover, pressed, selected, focused, disabled, loading, empty, and error states. Also use to audit visual consistency or decide whether appearance belongs in launcher/component or launcher/view. Treat the Launcher query surface and Action Panel as explicit special contracts instead of forcing the ordinary Settings control-size system onto them."},"isInternal":false,"tokens":1551,"sizeBytes":7652},{"name":"application.md","path":"www/docs/guide/plugins/system/application.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/application.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/application.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/application.md)","tokens":300,"sizeBytes":200},{"name":"backup.md","path":"www/docs/guide/plugins/system/backup.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/backup.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/backup.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/backup.md)","tokens":300,"sizeBytes":190},{"name":"browser-bookmark.md","path":"www/docs/guide/plugins/system/browser-bookmark.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/browser-bookmark.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/browser-bookmark.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/browser-bookmark.md)","tokens":300,"sizeBytes":210},{"name":"browser.md","path":"www/docs/guide/plugins/system/browser.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/browser.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/browser.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/browser.md)","tokens":300,"sizeBytes":192},{"name":"calculator.md","path":"www/docs/guide/plugins/system/calculator.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/calculator.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/calculator.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/calculator.md)","tokens":300,"sizeBytes":198},{"name":"chat.md","path":"www/docs/guide/plugins/system/chat.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/chat.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/chat.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/chat.md)","tokens":300,"sizeBytes":186},{"name":"clipboard.md","path":"www/docs/guide/plugins/system/clipboard.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/clipboard.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/clipboard.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/clipboard.md)","tokens":300,"sizeBytes":196},{"name":"cloudsync.md","path":"www/docs/guide/plugins/system/cloudsync.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/cloudsync.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/cloudsync.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/cloudsync.md)","tokens":300,"sizeBytes":196},{"name":"color.md","path":"www/docs/guide/plugins/system/color.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/color.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/color.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/color.md)","tokens":300,"sizeBytes":188},{"name":"converter.md","path":"www/docs/guide/plugins/system/converter.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/converter.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/converter.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/converter.md)","tokens":300,"sizeBytes":196},{"name":"doctor.md","path":"www/docs/guide/plugins/system/doctor.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/doctor.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/doctor.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/doctor.md)","tokens":300,"sizeBytes":190},{"name":"emoji.md","path":"www/docs/guide/plugins/system/emoji.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/emoji.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/emoji.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/emoji.md)","tokens":300,"sizeBytes":188},{"name":"explorer.md","path":"www/docs/guide/plugins/system/explorer.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/explorer.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/explorer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/explorer.md)","tokens":300,"sizeBytes":194},{"name":"feedback.md","path":"www/docs/guide/plugins/system/feedback.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/feedback.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/feedback.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/feedback.md)","tokens":300,"sizeBytes":194},{"name":"file.md","path":"www/docs/guide/plugins/system/file.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/file.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/file.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/file.md)","tokens":300,"sizeBytes":186},{"name":"folder.md","path":"www/docs/guide/plugins/system/folder.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/folder.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/folder.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/folder.md)","tokens":300,"sizeBytes":190},{"name":"hotkey-overview.md","path":"www/docs/guide/plugins/system/hotkey-overview.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/hotkey-overview.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/hotkey-overview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/hotkey-overview.md)","tokens":300,"sizeBytes":208},{"name":"mediaplayer.md","path":"www/docs/guide/plugins/system/mediaplayer.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/mediaplayer.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/mediaplayer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/mediaplayer.md)","tokens":300,"sizeBytes":200},{"name":"query-history.md","path":"www/docs/guide/plugins/system/query-history.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/query-history.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/query-history.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/query-history.md)","tokens":300,"sizeBytes":204},{"name":"shell.md","path":"www/docs/guide/plugins/system/shell.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/shell.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/shell.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/shell.md)","tokens":300,"sizeBytes":188},{"name":"sys.md","path":"www/docs/guide/plugins/system/sys.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/sys.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/sys.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/sys.md)","tokens":300,"sizeBytes":184},{"name":"theme.md","path":"www/docs/guide/plugins/system/theme.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/theme.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/theme.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/theme.md)","tokens":300,"sizeBytes":188},{"name":"update.md","path":"www/docs/guide/plugins/system/update.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/update.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/update.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/update.md)","tokens":300,"sizeBytes":190},{"name":"url.md","path":"www/docs/guide/plugins/system/url.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/url.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/url.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/url.md)","tokens":300,"sizeBytes":184},{"name":"websearch.md","path":"www/docs/guide/plugins/system/websearch.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/websearch.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/websearch.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/websearch.md)","tokens":300,"sizeBytes":196},{"name":"webview.md","path":"www/docs/guide/plugins/system/webview.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/webview.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/webview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/webview.md)","tokens":300,"sizeBytes":192},{"name":"wpm.md","path":"www/docs/guide/plugins/system/wpm.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/wpm.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/guide/plugins/system/wpm.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/guide/plugins/system/wpm.md)","tokens":300,"sizeBytes":184},{"name":"application.md","path":"www/docs/zh/guide/plugins/system/application.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/application.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/application.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/application.md)","tokens":300,"sizeBytes":206},{"name":"backup.md","path":"www/docs/zh/guide/plugins/system/backup.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/backup.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/backup.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/backup.md)","tokens":300,"sizeBytes":196},{"name":"browser-bookmark.md","path":"www/docs/zh/guide/plugins/system/browser-bookmark.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/browser-bookmark.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/browser-bookmark.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/browser-bookmark.md)","tokens":300,"sizeBytes":216},{"name":"browser.md","path":"www/docs/zh/guide/plugins/system/browser.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/browser.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/browser.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/browser.md)","tokens":300,"sizeBytes":198},{"name":"calculator.md","path":"www/docs/zh/guide/plugins/system/calculator.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/calculator.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/calculator.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/calculator.md)","tokens":300,"sizeBytes":204},{"name":"chat.md","path":"www/docs/zh/guide/plugins/system/chat.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/chat.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/chat.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/chat.md)","tokens":300,"sizeBytes":192},{"name":"clipboard.md","path":"www/docs/zh/guide/plugins/system/clipboard.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/clipboard.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/clipboard.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/clipboard.md)","tokens":300,"sizeBytes":202},{"name":"cloudsync.md","path":"www/docs/zh/guide/plugins/system/cloudsync.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/cloudsync.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/cloudsync.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/cloudsync.md)","tokens":300,"sizeBytes":202},{"name":"color.md","path":"www/docs/zh/guide/plugins/system/color.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/color.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/color.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/color.md)","tokens":300,"sizeBytes":194},{"name":"converter.md","path":"www/docs/zh/guide/plugins/system/converter.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/converter.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/converter.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/converter.md)","tokens":300,"sizeBytes":202},{"name":"doctor.md","path":"www/docs/zh/guide/plugins/system/doctor.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/doctor.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/doctor.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/doctor.md)","tokens":300,"sizeBytes":196},{"name":"emoji.md","path":"www/docs/zh/guide/plugins/system/emoji.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/emoji.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/emoji.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/emoji.md)","tokens":300,"sizeBytes":194},{"name":"explorer.md","path":"www/docs/zh/guide/plugins/system/explorer.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/explorer.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/explorer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/explorer.md)","tokens":300,"sizeBytes":200},{"name":"feedback.md","path":"www/docs/zh/guide/plugins/system/feedback.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/feedback.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/feedback.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/feedback.md)","tokens":300,"sizeBytes":200},{"name":"file.md","path":"www/docs/zh/guide/plugins/system/file.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/file.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/file.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/file.md)","tokens":300,"sizeBytes":192},{"name":"folder.md","path":"www/docs/zh/guide/plugins/system/folder.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/folder.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/folder.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/folder.md)","tokens":300,"sizeBytes":196},{"name":"hotkey-overview.md","path":"www/docs/zh/guide/plugins/system/hotkey-overview.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/hotkey-overview.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/hotkey-overview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/hotkey-overview.md)","tokens":300,"sizeBytes":214},{"name":"mediaplayer.md","path":"www/docs/zh/guide/plugins/system/mediaplayer.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/mediaplayer.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/mediaplayer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/mediaplayer.md)","tokens":300,"sizeBytes":206},{"name":"query-history.md","path":"www/docs/zh/guide/plugins/system/query-history.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/query-history.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/query-history.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/query-history.md)","tokens":300,"sizeBytes":210},{"name":"shell.md","path":"www/docs/zh/guide/plugins/system/shell.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/shell.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/shell.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/shell.md)","tokens":300,"sizeBytes":194},{"name":"sys.md","path":"www/docs/zh/guide/plugins/system/sys.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/sys.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/sys.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/sys.md)","tokens":300,"sizeBytes":190},{"name":"theme.md","path":"www/docs/zh/guide/plugins/system/theme.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/theme.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/theme.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/theme.md)","tokens":300,"sizeBytes":194},{"name":"update.md","path":"www/docs/zh/guide/plugins/system/update.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/update.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/update.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/update.md)","tokens":300,"sizeBytes":196},{"name":"url.md","path":"www/docs/zh/guide/plugins/system/url.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/url.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/url.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/url.md)","tokens":300,"sizeBytes":190},{"name":"websearch.md","path":"www/docs/zh/guide/plugins/system/websearch.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/websearch.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/websearch.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/websearch.md)","tokens":300,"sizeBytes":202},{"name":"webview.md","path":"www/docs/zh/guide/plugins/system/webview.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/webview.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/webview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/webview.md)","tokens":300,"sizeBytes":198},{"name":"wpm.md","path":"www/docs/zh/guide/plugins/system/wpm.md","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/wpm.md","title":"System Skill","category":"anthropic-skill","format":"markdown","content":"# System Skill\n\nPath: `www/docs/zh/guide/plugins/system/wpm.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/www/docs/zh/guide/plugins/system/wpm.md)","tokens":300,"sizeBytes":190},{"name":"store-plugin.json","path":"store-plugin.json","rawUrl":"https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/store-plugin.json","title":"Plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# Plugin Plugin Manifest\n\nPath: `store-plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/store-plugin.json)","tokens":300,"sizeBytes":156}],"systemPromptSnippet":"<yakaai_skills repo=\"Wox-launcher/Wox\">\n<!-- File: AGENTS.md (Tokens: ~300 | Category: root-instruction) -->\n# AI Agent Protocol & Instructions\n\nPath: `AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/AGENTS.md)\n\n<!-- File: .agents/skills/wox-blog/agents/openai.yaml (Tokens: ~300 | Category: anthropic-skill) -->\n# Agents Skill\n\nPath: `.agents/skills/wox-blog/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/agents/openai.yaml)\n\n<!-- File: .agents/skills/wox-blog/assets/article-template.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Assets Skill\n\nPath: `.agents/skills/wox-blog/assets/article-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/assets/article-template.md)\n\n<!-- File: .agents/skills/wox-blog/references/cover-style.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/wox-blog/references/cover-style.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/references/cover-style.md)\n\n<!-- File: .agents/skills/wox-blog/references/writing-style.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/wox-blog/references/writing-style.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-blog/references/writing-style.md)\n\n<!-- File: .agents/skills/wox-blog/SKILL.md (Tokens: ~1231 | Category: anthropic-skill) -->\n---\nname: wox-blog\ndescription: Create or revise Wox blog articles with practical workflows, paired English and Chinese Markdown, and consistent illustrated covers. Use for Wox blog writing and editorial standards, not release changelogs or general documentation.\n---\n\n# Wox Blog\n\nWrite for people using Wox: one concrete task, its useful outcome, and enough detail to reproduce it. Support product stories and engineering articles when requested; practical tips and workflows are the default.\n\n## Establish the facts\n\n- Read relevant feature documentation and implementation before describing commands, setting labels, defaults, or platform support. Distinguish released behavior from development-only changes; do not imply unreleased features are available in the current release.\n- Inspect nearby articles and `www/docs/.vitepress/theme/components/blog.data.mts` for the metadata contract. Do not turn a blog request into an app feature change.\n- For existing articles, preserve the slug, publication date, and useful media unless the request explicitly changes them.\n\n## Write the article pair\n\n- Read [the writing style guide](references/writing-style.md) before drafting or substantially rewriting. It contains the Mole sample analysis, Wox-specific examples, and an editorial review. Borrow explanatory techniques rather than copying an author's voice.\n- Default to English in `www/docs/blog/<slug>.md` and Simplified Chinese in `www/docs/zh/blog/<slug>.md`, using the same slug, date, category, and cover. Honor explicit single-language requests.\n- Use [the article template](assets/article-template.md) for frontmatter and a starting point, replacing every template token. It is not a mandatory outline.\n- Choose a specific title about a task or benefit. Avoid a repeated “Did You Know” / “你知道吗” prefix, exaggerated claims, and generic introductions. The description should add useful context rather than repeat the title.\n- Develop the situation, a concrete example, the reason for consequential settings, and the observable result as needed. Use connected prose for the explanation and steps for actions. Add useful context where an article feels thin; do not pad it with adjectives, repeated benefits, or a mandatory FAQ/conclusion. Keep length and structure proportional to the task.\n- Use a calm, conversational voice with specific nouns and verbs. Do not fabricate personal experience, measured improvements, user quotations, or test results to make the writing lively. Keep card descriptions compact; put the fuller explanation in the body.\n- Translate naturally. Keep commands, setting semantics, platform constraints, and outcomes equivalent across languages. Make frontmatter `title` match the article H1.\n- New articles use the actual publication date in `YYYY-MM-DD`. Use a stable descriptive kebab-case slug; omit the legacy `did-you-know-` prefix for new articles.\n\n## Supply card metadata and a cover\n\nRequired frontmatter: `title`, `description`, `date`, `category`, `cover`, and `coverAlt`.\n\n| Category ID | English label | Chinese label |\n| --- | --- | --- |\n| `workspace` | Windows & apps | 窗口与应用 |\n| `preview` | Files & previews | 文件与预览 |\n| `automation` | Shortcuts & automation | 快捷键与自动化 |\n| `product` | Inside Wox | Wox 动态 |\n\nChoose the closest category. Add a category only when the article genuinely falls outside these themes, updating loader validation and both localized labels in `BlogIndex.vue` together.\n\n- The default cover style is the approved flat illustration family: front-facing 2D shapes, thin charcoal-blue outlines, pale gray backgrounds, muted blue/sage/peach accents, and generous whitespace. Avoid clay-like 3D materials, bevels, thick keys, perspective, and heavy shadows. Use no text or logos in covers.\n- Read [the cover style reference](references/cover-style.md) when creating or replacing a cover. Use the built-in image generation tool for original illustrations; inspect an existing cover as a style reference when useful.\n- Save selected images under `www/docs/public/images/blog/` and reference `/images/blog/<name>.webp` (or the actual image extension). Localize `coverAlt` concisely.\n- Covers express the topic, not evidence of product behavior. Preserve real screenshots and videos in the body. Never substitute generated mock UI for factual screenshots.\n- When a real Wox product screenshot is needed but unavailable, continue drafting with a descriptive text placeholder at the intended position, such as `> Screenshot needed: Wox workspace settings showing the saved window layout on Windows.` Specify the screen, relevant state or action, and what the image should demonstrate; use the article language. Do not create an image link to a nonexistent file. At delivery, notify the user and list the article locations and screenshots they need to supply. These intentional screenshot placeholders may remain in the draft; they do not block completing the text and local validation.\n- If image generation is unavailable, finish text preparation and report the missing cover. Do not leave broken references or silently switch to a different medium.\n- The homepage discovers Markdown automatically and sorts by date, then URL. Do not manually add links to the blog indexes or hard-code cards.\n\n## Verify and deliver\n\n- Run the editorial pass in the writing guide: check that the reader can recognize the situation, follow the example, and tell what success looks like; remove unsupported claims and repeated filler.\n- Check both languages, links, actual asset paths, metadata, and claims against the source feature. Preserve existing URLs when revising.\n- From `www`, run `pnpm docs:build`; run `git diff --check` from the repository root.\n- Verify the article appears on its language homepage with its cover, complete title, and correct date. Inspect article media and the card at desktop and mobile widths.\n- Report article paths and verification limits. Default to local files and local verification; do not commit, push, or deploy unless requested.\n\n<!-- File: .agents/skills/wox-changelog-update/agents/openai.yaml (Tokens: ~300 | Category: anthropic-skill) -->\n# Agents Skill\n\nPath: `.agents/skills/wox-changelog-update/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-changelog-update/agents/openai.yaml)\n\n<!-- File: .agents/skills/wox-changelog-update/SKILL.md (Tokens: ~2853 | Category: anthropic-skill) -->\n---\nname: wox-changelog-update\ndescription: Update Wox CHANGELOG.md and CHANGELOG.zh_CN.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.\n---\n\n# Wox Update Changelog\n\n## Overview\n\nUpdate `CHANGELOG.md` and `CHANGELOG.zh_CN.md` from the latest released version to `HEAD` and keep wording, section order, and markdown style consistent with existing entries. The two files must describe the same release with the same structure; only the language of user-facing prose changes.\n\n## Workflow\n\n1. Identify the release boundary.\n\n- Read the top of `CHANGELOG.md` and `CHANGELOG.zh_CN.md` and detect the target section (usually newest version at the top).\n- Detect the last released tag with `git tag --sort=-creatordate`.\n- Use commit range `last_release_tag..HEAD` by default.\n- If changelog heading and git tag disagree, prefer changelog context and state the assumption.\n\n2. Collect candidate changes.\n\n- Run `git log --oneline --no-merges <range>`.\n- Open key commits with `git show --stat --oneline <sha>` to classify user-facing impact.\n- Check whether each included change came through a pull request. Inspect merge commits as well as the non-merge log, and use GitHub's commit-to-PR lookup or PR metadata for squash/rebase merges or unclear local history. Record the PR URL and the contributor's verified GitHub login; use the PR author, not the person who merged it. Do not infer a login from a commit display name or email. If attribution cannot be verified, report that gap instead of guessing or silently omitting it.\n- Ignore pure build/version bump commits unless they change user-visible behavior.\n- Collect store catalog additions separately from app/core commits. Compare `store-plugin.json` and `store-theme.json` at `last_release_tag` vs `HEAD`. A store item is new only when its `Id` (plugin) or `ThemeId` (theme) is absent from the last release file. Ignore version bumps, field edits, and other updates to existing store entries. Ignore bundled script plugin version bumps.\n- Do not put third-party store catalog changes in `Add`, `Improve`, or `Fix`. List only newly added store plugins and themes in `Store`.\n\n3. Classify into changelog buckets.\n\n- `Add`: major, clearly new user-visible capabilities, workflows, plugins, or standalone feature areas.\n- `Improve`: behavioral or UX improvements without new core capability.\n- `Fix`: user-facing bug fixes/regressions.\n- `Store`: plugins and themes newly listed in the Wox store during this range.\n- Omit the `Add` section when the release does not contain a substantial new feature. Prefer `Improve` for additions that extend an existing feature area rather than creating a new user workflow.\n- Omit the `Store` section when no new store plugin or theme IDs appeared in range.\n- Treat platform-specific implementations, provider additions, runtime dependency checks, searchable metadata, theme overrides, and similar support for existing systems as `Improve` unless the commit introduces a large new user-facing feature.\n- Exclude internal refactors/tests/docs/chore unless directly user-visible.\n- Exclude tiny UI-only polish by default (for example spacing, alignment, minor color/wording tweaks) unless it fixes a functional UX issue or the user explicitly asks to include small UI changes.\n\n4. Write changelog entries in repository style.\n\n- Preserve header pattern exactly (for example: `## v2.0.1 -`). Use the same heading, date, screenshots, issue links, and section keys in both files.\n- Keep section titles in English in both files: `- Add`, `- Improve`, `- Fix`, `- Store`. The client already localizes these labels.\n- Add a short highlight paragraph directly below every release heading you create or update, before screenshots and `Add`/`Improve`/`Fix`/`Store` sections. Follow the `v2.4.4` style: one or two short everyday sentences about the visible change, not the implementation. Example: a new Jade theme and Liquid Glass on macOS 26; Settings keep their own look so themes no longer change that window.\n- Write for ordinary users, not developers or reviewers. Describe what someone sees or can do after updating. Do not explain schemas, APIs, caches, indexes, host restarts, platform variants, or other internals unless that is the user-facing name of the feature (for example Liquid Glass, `cb paste`, `.wox`).\n- Prefer plain words over implementation labels: say \"Settings keep their own look\" instead of \"independent chrome\", \"every word must match\" instead of \"AND matching\", \"theme previews match the launcher\" instead of \"schema v2 sparse authoring\".\n- Keep section order: `Add`, `Improve`, `Fix`, `Store`.\n- Use bullet nesting style already used in file.\n- Keep wording concise, everyday, and factual. If a sentence needs a term a typical user would not know, rewrite it or drop that detail.\n- Match wording to the bucket. English `Improve` entries should say \"Improve\", \"Expand\", \"Support\", or similar, not \"Add\", unless the entry is intentionally describing a small added option inside an improvement.\n- For new `Add` features, explain what the feature is for and why a user would use it. Do not reduce major features to one terse implementation phrase.\n- Keep the same feature in one bullet whenever possible. For example, combine Screenshot scrolling capture, pinning, and plugin API changes into one `[`Screenshot`]` bullet instead of splitting them into separate bullets.\n- If a new feature needs screenshots but the images are not available yet, leave clearly named screenshot placeholder image lines in the same bullet so the screenshots can be added later.\n- Prefer plugin/module prefix when clear, e.g. ``[`Shell`]`` or ``[`Clipboard`]``.\n- Write issue references as Markdown links, e.g. `[#4339](https://github.com/Wox-launcher/Wox/issues/4339)`. Do not leave a bare `#4339` for the preview to rewrite later.\n- Every changelog item originating from a PR must credit its contributor with `[@username](https://github.com/username)` and link the PR as `[#1234](https://github.com/Wox-launcher/Wox/pull/1234)`. Apply this to `Add`, `Improve`, `Fix`, and `Store`, with identical attribution in both languages. When a bullet combines contributions from several PRs, credit each relevant PR author once. Keep store author credits; if that author is also the PR contributor, reuse the existing mention, otherwise append the PR contributor separately. For example: ``  - [`Notes`] Fix typing `- [ ] ` not creating a task. [#4618](https://github.com/Wox-launcher/Wox/pull/4618) [@lmgarret](https://github.com/lmgarret)``.\n- Keep existing screenshots. Add new screenshot lines when screenshots already exist, or when a user explicitly asks to reserve screenshot positions for upcoming images.\n- Write `Store` as two nested groups, omitting an empty group: `Plugin` then `Theme`. Each item is already-clickable Markdown: `[Name](page_url) Description [@github_username](https://github.com/github_username)`. Resolve `i18n:` names and descriptions from `I18n.en_US` in `CHANGELOG.md` and from `I18n.zh_CN` in `CHANGELOG.zh_CN.md` (`plugin_name`, `plugin_desc` or `plugin_description`). If a locale is missing, fall back to `en_US`, then `Name` / `Description`. Use `ThemeName` and `Description` for themes. Link the name to `Website` (plugin) or `ThemeUrl` (theme). If that URL is empty, write the plain name without a link. Append the author as a GitHub profile link. Prefer the username from a `github.com` / `gist.github.com` `Website` or `ThemeUrl`; otherwise use `Author` or `ThemeAuthor` when it is a single handle. Skip the author link when the author is only a display name. Do not add store screenshots, download URLs, or version numbers.\n\n  ```markdown\n  - Store\n    - Plugin\n      - [Color Picker](https://github.com/author/wox-plugin-color) Wox plugin to pick colors [@author](https://github.com/author)\n      - [Strava](https://github.com/author/wox-plugin-strava) A plugin to interact with Strava workouts [@author](https://github.com/author)\n    - Theme\n      - [Wox Dracula](https://github.com/author/wox-theme-dracula) Wox theme inspired by the Dracula color scheme [@author](https://github.com/author)\n  ```\n\n- Write the English file first, then produce the Chinese file as a line-for-line counterpart. Do not add or drop bullets in only one language.\n- Both files now contain the full version history. Keep new headings in both files and do not leave a new release in only one language.\n\n5. Keep README in sync only when the latest **stable** heading changes.\n\n- Update the line next to the Release badge to `Latest: vX.Y.Z · Mon YYYY`, matching that heading (for example `Latest: v2.4.3 · Sep 2026`). GitHub README is not generated.\n- Skip this when you only add bullets under an existing heading, or when the newest heading is a beta (`vX.Y.Z-beta.N`).\n- Do not hand-edit `www/docs`. Homepage version text, compare stamps, and `/changelog/*` pages are generated from `CHANGELOG.md` and `CHANGELOG.zh_CN.md` during `docs:dev` / `docs:build`.\n\n6. Validate before finishing.\n\n- Ensure no duplicate bullets.\n- Ensure every `Add`/`Improve`/`Fix` bullet maps to at least one commit in range.\n- Ensure every PR-derived item includes its PR link and verified contributor mention in both languages, including when the same feature combines direct commits and PR contributions. Check merge history or GitHub associations so `--no-merges` does not hide attribution.\n- Ensure every `Store` bullet maps to a plugin `Id` or theme `ThemeId` that is new since `last_release_tag`.\n- Ensure every release section you create or update has a biggest-highlight paragraph under the version heading in both files, written in everyday language a typical user can understand.\n- Reread new bullets as a user: drop leftover implementation terms such as schema, chrome, prefetch, incremental index, DirectWrite, overlay, conversion mode, or host restart unless they are the feature name.\n- Ensure English and Chinese newest sections have the same headings, screenshots, issue links, and bullet count.\n- If the latest stable heading is new or its date changed, ensure README contains `Latest: vX.Y.Z · Mon YYYY` matching it (`docs:build` fails if this line is missing).\n- Ensure markdown renders cleanly and section spacing matches nearby versions.\n- Avoid rewriting old release sections unless explicitly requested.\n- If a commit set only contains tiny UI-only polish, keep it out of changelog by default.\n\n## Command Reference\n\n```bash\ngit tag --sort=-creatordate | head -n 20\nsed -n '1,120p' CHANGELOG.md\nsed -n '1,120p' CHANGELOG.zh_CN.md\ngit log --oneline --no-merges <last_tag>..HEAD\ngit log --oneline --merges <last_tag>..HEAD\ngit show --stat --oneline <sha>\ngit show <last_tag>:store-plugin.json\ngit show <last_tag>:store-theme.json\ngit diff -- CHANGELOG.md CHANGELOG.zh_CN.md\n```\n\nCompare store catalogs by ID, not by file diff hunks. Example:\n\n```bash\npython -c \"\nimport json, subprocess, sys\ntag = sys.argv[1]\ndef load(rev, path):\n    return json.loads(subprocess.check_output(['git', 'show', f'{rev}:{path}']))\nold_p = {p['Id'] for p in load(tag, 'store-plugin.json')}\nnew_p = json.load(open('store-plugin.json', encoding='utf-8'))\nfor p in new_p:\n    if p['Id'] not in old_p:\n        print('plugin', p.get('Name'), p.get('Description'), p.get('Author'), p.get('Website'), p.get('I18n'))\nold_t = {t['ThemeId'] for t in load(tag, 'store-theme.json')}\nnew_t = json.load(open('store-theme.json', encoding='utf-8'))\nfor t in new_t:\n    if t['ThemeId'] not in old_t:\n        print('theme', t.get('ThemeName'), t.get('Description'), t.get('ThemeAuthor'), t.get('ThemeUrl'))\n\" <last_tag>\n```\n\n## Output Rules\n\n- Edit `CHANGELOG.md` and `CHANGELOG.zh_CN.md` together.\n- If the latest stable heading changed, also update the README `Latest: vX.Y.Z · Mon YYYY` line. Do not edit `www/docs` changelog pages or homepage copy.\n- Keep final response short: what section was updated and what categories were changed, including `Store` plugin/theme counts when present.\n- If commit intent is ambiguous, state the assumption briefly in the final response.\n\n<!-- File: .agents/skills/wox-commit/agents/openai.yaml (Tokens: ~300 | Category: anthropic-skill) -->\n# Agents Skill\n\nPath: `.agents/skills/wox-commit/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-commit/agents/openai.yaml)\n\n<!-- File: .agents/skills/wox-commit/SKILL.md (Tokens: ~533 | Category: anthropic-skill) -->\n---\nname: wox-commit\ndescription: Generate a repository-style commit message from the current Wox working tree without modifying the repository. Use when the user asks for a commit message or explicitly invokes `$wox-commit`.\n---\n\n# Wox Commit Message\n\n## Contract\n\nTreat explicit invocation as permission to inspect the current Wox diff and generate a commit message only. Do not stage, commit, amend, push, or otherwise modify the repository.\n\n## Workflow\n\n1. Read the repository instructions and inspect `git status --short`, the unstaged and staged diffs, and relevant untracked files.\n2. Infer every distinct behavior change from the actual diff and recent commit style. Do not ask the user to pick one feature when several unrelated changes are present.\n3. Prefer `type(scope): imperative summary` for normal code changes; use the repository's established wording for automated, release, or store updates.\n4. Always return both a subject and a body in one copy-ready block.\n\n## Message Rules\n\n- Describe the reason or behavior change, not a file list.\n- Keep the subject specific, imperative, and free of trailing punctuation.\n- Choose the narrowest accurate scope already used by nearby commits. When the tree spans unrelated areas, omit a misleading narrow scope rather than picking one feature.\n- Use `feat`, `fix`, `refactor`, `docs`, `test`, `build`, or `chore` only when it matches the diff.\n- Cover every distinct change in the same message. Unrelated features still belong in one subject-plus-body: name each behavior so a reviewer can see all of them without reading the file list.\n- When one change dominates, put it in the subject and name the others in the body. When two or more are peer features, name both in the subject if they fit; otherwise use a broader subject and give each change its own sentence in the body.\n- Always write a body that expands the why or the non-obvious behavior. One or two sentences is enough for a single change; use one short sentence per distinct change when the tree contains more than one. Do not leave the body empty.\n- Do not run formatting, tests, hooks, or other validation; the caller has already completed validation before requesting the message.\n\n## Completion\n\nReturn exactly one fenced text block the user can copy as a full commit message: subject, a blank line, then the body. After the block, add a brief note only if the diff is empty. Do not claim that a commit was created.\n\n```text\ntype(scope): imperative summary\n\nBody that explains the why or the non-obvious behavior.\n```\n\n<!-- File: .agents/skills/wox-cpu-debug/agents/openai.yaml (Tokens: ~300 | Category: anthropic-skill) -->\n# Agents Skill\n\nPath: `.agents/skills/wox-cpu-debug/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-cpu-debug/agents/openai.yaml)\n\n<!-- File: .agents/skills/wox-cpu-debug/SKILL.md (Tokens: ~3931 | Category: anthropic-skill) -->\n---\nname: wox-cpu-debug\ndescription: Measure CPU usage, attribute CPU hotspots, and optimize them without materially increasing Go or native memory in the real single-process Wox Go UI. Use for continuous-query CPU regressions, high idle or hidden CPU, plugin/query hot paths, renderer or native platform activity, background work that continues after hide, and comparisons of Go pprof data with macOS or Windows process samples.\n---\n\n# Wox CPU Debug\n\n## Goal\n\nRun the real Wox debug build with `wox_automation`, warm the same process, replay deterministic queries, and measure query-active and hidden CPU independently. Use Go CPU profiles for Go ownership and OS process/native samples for whole-process behavior. Keep profilers in separate identical runs so one profiler does not distort another.\n\n## Run the Debug Build\n\n### macOS\n\n1. Stop every other Wox instance.\n2. Start the real debug build under Delve:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\nWOX_AUTOMATION_INFO_FILE=/tmp/wox-cpu-automation.json /Users/qianlifeng/go/bin/dlv debug . --build-flags=-tags=sqlite_fts5,wox_automation\n```\n\n3. Run `continue`, wait for startup and plugin initialization, and record the debuggee PID.\n4. Keep this PID alive and running normally for the complete comparison. Never sample Delve or `debugserver` instead of the debuggee.\n\nBuild the automation workload once before measuring so Go compilation is outside every CPU window:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\ngo build -o /tmp/wox-cpu-workload ../.agents/skills/wox-cpu-debug/scripts/run-cpu-workload.go\n```\n\n### Windows\n\nStart Delve headlessly so the real debuggee can run normally while measurements execute from another PowerShell process:\n\n```powershell\ncd D:\\dev\\Wox\\wox.core\nNew-Item -ItemType Directory -Force .tmp\\cpu-debug | Out-Null\n$env:WOX_AUTOMATION_INFO_FILE = \"D:\\dev\\Wox\\wox.core\\.tmp\\cpu-debug\\automation.json\"\n$env:CGO_ENABLED = \"1\"\n$delve = Start-Process -FilePath (Get-Command dlv).Source `\n  -ArgumentList @(\"debug\", \".\", \"--headless\", \"--listen=127.0.0.1:43001\", \"--api-version=2\", \"--accept-multiclient\", \"--continue\", \"--build-flags=-tags=sqlite_fts5,wox_automation\", \"--output=D:\\dev\\Wox\\wox.core\\.tmp\\cpu-debug\\__debug_bin_wox.exe\") `\n  -WorkingDirectory (Get-Location).Path -WindowStyle Hidden -PassThru\n```\n\nWait for `automation.json`, then identify the `__debug_bin_wox.exe` child PID. Never sample either Delve process:\n\n```powershell\nwhile (-not (Test-Path $env:WOX_AUTOMATION_INFO_FILE)) { Start-Sleep -Milliseconds 100 }\nGet-CimInstance Win32_Process |\n  Where-Object { $_.ParentProcessId -eq $delve.Id -and $_.Name -eq \"__debug_bin_wox.exe\" } |\n  Select-Object ProcessId, ParentProcessId, Name, CommandLine\n```\n\nBuild the workload once before warm-up:\n\n```powershell\ngo build -o .tmp\\cpu-debug\\wox-cpu-workload.exe ..\\.agents\\skills\\wox-cpu-debug\\scripts\\run-cpu-workload.go\n```\n\nKeep the same debuggee PID alive through warm-up and every before/after comparison. When finished, stop only the exact debuggee and Delve PIDs created by this run.\n\n## Warm the Process\n\nRun a 15-second mixed-query block, hide the launcher, and wait 10 seconds:\n\n```bash\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode queries -duration 15s -seed 1\nsleep 10\n```\n\nWarm-up absorbs startup, application indexing, font loading, icon decoding, and lazy caches. Restarting Wox after warm-up invalidates the comparison.\n\nOn Windows, use the corresponding `.exe` and PowerShell sleep command:\n\n```powershell\n& .tmp\\cpu-debug\\wox-cpu-workload.exe -info .tmp\\cpu-debug\\automation.json -mode queries -duration 15s -seed 1\nStart-Sleep -Seconds 10\n```\n\n## Measure Query Latency\n\nUse the workload's `latency` mode for query responsiveness. The `queries` mode only\nchecks input updates and drives CPU activity; its fixed waits are not latency samples.\nBuild the workload before measuring, then warm the same process with 40 completed\nqueries and measure a deterministic sequence:\n\n```powershell\n& .tmp\\cpu-debug\\wox-cpu-workload.exe -info .tmp\\cpu-debug\\automation.json -mode latency -query-count 40 -seed 1 -output .tmp\\cpu-debug\\warmup.json\n& .tmp\\cpu-debug\\wox-cpu-workload.exe -info .tmp\\cpu-debug\\automation.json -mode latency -query-count 160 -seed 11 -output .tmp\\cpu-debug\\latency.json\n```\n\nThe report contains raw per-query samples and nearest-rank p50/p95 for input\ndispatch to the first current result in the retained semantics frame, and to the\ncompleted result frame. Polling is every 5 ms plus RPC/scheduling overhead; these\nare client-observed UI-frame timings, not native presentation or icon-decode\ncompletion timings. Queries with no results contribute only to completion latency.\nEach query has a 10-second timeout; a failed run is invalid and must not contribute\npartial samples to the aggregate. Compare query families as well as aggregate p95.\n\n`perf.query_state` correlates the query generation, result ownership, input value,\nand retained row IDs, so an older retained result or completion cannot satisfy the\nmeasurement. `-mode stats` reads PID, effective GOMAXPROCS, Go heap allocation,\nGo retained memory (`Sys - HeapReleased`), stack allocation, and MemProfileRate\nwithout showing Wox or forcing GC.\n\nWhen comparing startup GOMAXPROCS policies, use a fresh process for each arm,\nwith identical isolated settings, warm-up, query sequence, and GOGC. Preserve each\nPID through that run's warm-up and measurements. Alternate arm order across at\nleast three pairs. Do not compile, run tests, or run another profiler during a\nmeasurement window. Collect process CPU in separate `queries` windows, recording\ncompleted query counts, then sample memory at 45 seconds after hide so both staged\nrelease deadlines have passed. Keep private working set, total working set, private\ncommitted bytes, and Go retained memory distinct. Repeat decisive measurements in\nan optimized production-configured build, where development heap profiling is off.\n\n## Capture Continuous-Query Go CPU\n\nTrigger Wox's built-in 30-second `runtime/pprof` action and keep deterministic queries running for that complete window:\n\n```bash\n/tmp/wox-cpu-workload \\\n  -info /tmp/wox-cpu-automation.json \\\n  -mode profile-queries \\\n  -seed 11 \\\n  -output /tmp/wox-cpu-queries.prof\n```\n\nInspect both self time and cumulative ownership:\n\n```bash\ngo tool pprof -top -nodecount=30 /tmp/wox-cpu-queries.prof\ngo tool pprof -top -cum -nodecount=30 /tmp/wox-cpu-queries.prof\n```\n\nOn macOS and Linux, read the profile header's `Duration` and `Total samples` ratio as average effective core use during the 30-second window. Record the top flat and cumulative owners. Use `go tool pprof -list '<pattern>'` for source-level attribution only after a stable owner appears.\n\nOn Windows, do not trust `Total samples / Duration` until it agrees with process CPU sampling. Go profiles can charge time blocked in `runtime.cgocall`, `syscall.syscalln`, `GetMessage`, or `GetQueuedCompletionStatus` as if it were CPU. When these wait paths dominate and the profile ratio contradicts process CPU, treat the ratio and those cumulative wait owners as profiling artifacts. Use the Windows process sampler as the CPU baseline and use application-owned profile paths only as attribution candidates that require reproduction.\n\nRepeat with `-query terminal` or another fixed query when mixed queries need attribution. Compare mixed and fixed runs from the same PID; do not compare a profile captured during startup with a warmed profile.\n\nThe automation client can time out while waiting for semantics during expensive mixed queries. If that happens:\n\n- Mark the complete process window as contaminated; do not average the idle samples after the workload stalled.\n- Check whether the built-in 30-second profile still completed in `~/.wox/cpu.prof` or `%USERPROFILE%\\.wox\\cpu.prof`, but label it partial-workload evidence.\n- Repeat with a safe fixed query such as `-query terminal`. Only use a run that reports its completed query count for the clean baseline.\n- Record the query and transition (`set` or `clear`) that timed out as a separate automation/query diagnostic.\n\n## Measure macOS Query CPU\n\nUse a separate workload-only run for process CPU percentages:\n\n```bash\nready=$(mktemp /tmp/wox-cpu-query.XXXXXX)\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode queries -duration 35s -seed 11 -ready-file \"$ready\" &\nworkload_pid=$!\nwhile [[ ! -s \"$ready\" ]]; do sleep 0.1; done\n/Users/qianlifeng/Projects/Wox/.agents/skills/wox-cpu-debug/scripts/sample-wox-cpu-macos.sh --pid <PID> --samples 30 --interval 1\nwait \"$workload_pid\"\n```\n\nUse `AverageCPUPercent`, `MedianCPUPercent`, and `MaxCPUPercent`. macOS `%CPU` uses one-core units and may exceed 100 when multiple cores are active.\n\nWhen Go pprof does not explain process CPU, repeat the workload in a separate run and capture native stacks:\n\n```bash\nready=$(mktemp /tmp/wox-cpu-query-native.XXXXXX)\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode queries -duration 35s -seed 11 -ready-file \"$ready\" &\nworkload_pid=$!\nwhile [[ ! -s \"$ready\" ]]; do sleep 0.1; done\n/usr/bin/sample <PID> 30 -file /tmp/wox-cpu-queries-native.txt\nwait \"$workload_pid\"\n```\n\nDo not run `sample` and Go CPU profiling together. Attribute CoreText, CoreGraphics, AppKit, image decoding, cgo, and platform event-loop stacks from the native capture.\n\n## Measure Windows Query CPU\n\nUse a separate workload-only run. Start the workload with a unique ready file, wait for readiness, then sample the debuggee with `TotalProcessorTime` deltas:\n\n```powershell\n$ready = Join-Path $env:TEMP (\"wox-cpu-query-\" + [guid]::NewGuid().ToString(\"N\") + \".ready\")\n$workload = Start-Process -FilePath .tmp\\cpu-debug\\wox-cpu-workload.exe `\n  -ArgumentList @(\"-info\", \".tmp\\cpu-debug\\automation.json\", \"-mode\", \"queries\", \"-duration\", \"35s\", \"-seed\", \"11\", \"-query\", \"terminal\", \"-ready-file\", $ready) `\n  -WorkingDirectory (Get-Location).Path -WindowStyle Hidden -PassThru\nwhile (-not (Test-Path $ready)) { Start-Sleep -Milliseconds 100 }\n& ..\\.agents\\skills\\wox-cpu-debug\\scripts\\sample-wox-cpu-windows.ps1 `\n  -ProcessId <PID> -Samples 30 -IntervalSeconds 1 -CsvPath .tmp\\cpu-debug\\query-samples.csv\nWait-Process -Id $workload.Id\n```\n\nWindows CPU percentages also use one-core units and can exceed 100%. One-second samples can quantize around the Windows scheduler/accounting interval, so interpret the median and repeated pattern rather than a single small non-zero value.\n\nWhen Go pprof does not explain measured process CPU, capture ETW sampled CPU stacks with Windows Performance Recorder/Analyzer or another available native profiler in a separate identical run. Filter to the debuggee PID and verify symbols before attributing DirectComposition, Direct2D, DirectWrite, Win32, image decoding, or cgo work. If no native stack profiler is available, report that limitation instead of inferring a native owner from cumulative cgo time.\n\n## Measure Hidden CPU\n\nHide Wox first, signal readiness only after the hide completes, and sample the settled process:\n\n```bash\nready=$(mktemp /tmp/wox-cpu-hidden.XXXXXX)\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode hidden -duration 35s -ready-file \"$ready\" &\nworkload_pid=$!\nwhile [[ ! -s \"$ready\" ]]; do sleep 0.1; done\nsleep 2\n/Users/qianlifeng/Projects/Wox/.agents/skills/wox-cpu-debug/scripts/sample-wox-cpu-macos.sh --pid <PID> --samples 30 --interval 1\nwait \"$workload_pid\"\n```\n\nCapture hidden native stacks in another identical run when median CPU stays above sampler noise or periodic spikes recur:\n\n```bash\nready=$(mktemp /tmp/wox-cpu-hidden-native.XXXXXX)\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode hidden -duration 35s -ready-file \"$ready\" &\nworkload_pid=$!\nwhile [[ ! -s \"$ready\" ]]; do sleep 0.1; done\nsleep 2\n/usr/bin/sample <PID> 30 -file /tmp/wox-cpu-hidden-native.txt\nwait \"$workload_pid\"\n```\n\nUse `profile-hidden` only as a secondary Go-owner check:\n\n```bash\n/tmp/wox-cpu-workload -info /tmp/wox-cpu-automation.json -mode profile-hidden -output /tmp/wox-cpu-hidden.prof\n```\n\nThe CPU-profile action must briefly show the launcher to activate itself, so `profile-hidden` contains one-time activation and hide work at the start. Treat a function as a hidden hotspot only when it also appears in the settled OS/native run or consumes enough repeated samples to dominate that one-time transition.\n\nOn Windows, start the same `hidden` workload with a unique ready file, wait two seconds after readiness, and invoke `sample-wox-cpu-windows.ps1` for the debuggee PID. If a large spike appears while the median is near the sampling floor, capture two more settled 30-second windows. Classify it as periodic activity only if the spike or owner recurs.\n\n## Interpret Hotspots\n\nClassify query and hidden phases separately:\n\n- **Expected query work:** plugin query execution, fuzzy matching, file/application lookup, result adaptation, layout, text measurement, image decode, and rendering that stops after hide.\n- **Query hotspot candidate:** one owner repeatedly dominates flat or cumulative samples across identical profiles and scales with query frequency.\n- **No hidden CPU signal:** median settles at sampler noise, occasional spikes do not repeat, and a 30-second native sample has no recurring application stack.\n- **Possible hidden regression:** CPU remains above noise across three settled windows or recurring stacks show timers, animation/frame scheduling, renderer submission, Glance refresh, query cleanup, indexing, GC pressure, or asynchronous reloads after hide.\n- **Strong hidden regression:** the same owner persists in Go and/or native samples, reproduces after another warm run, and disappears when its feature is disabled or its lifecycle ends.\n\nIf process CPU is high but Go pprof is quiet, investigate native or cgo owners before changing Go query code. If Go pprof is high but process samples are low, verify that the profile was captured from the same PID and that activation/transition work did not dominate a mostly idle window.\n\nOn Windows, a high pprof total dominated by blocked Win32 calls is not evidence of high process CPU. Prefer the process sampler for magnitude and use the profile only to locate application work that scales across clean, identical workloads.\n\nDo not edit production code until the workload and owner reproduce. Add targeted `util.GetLogger()` diagnostics only when profiles identify a narrow lifecycle or scheduling path but cannot prove why it remains active.\n\n## Protect Memory While Optimizing CPU\n\nTreat memory as a required guardrail for every CPU optimization:\n\n- Prefer eliminating duplicate work, coalescing invalidations, stopping unnecessary scheduling, and reusing already-owned bounded resources.\n- Do not trade CPU for unbounded caches, duplicate decoded images or pixel buffers, retained render surfaces, longer-lived queues, or state that survives hide/close without a lifecycle reason.\n- Give every new cache, pool, or buffer a hard bound and an explicit release path. Clear window-scoped native resources on hide or close unless retaining them is required and measured.\n- For changes that alter caching, buffering, pooling, object lifetime, image ownership, or native resources, compare warmed before/after process physical footprint and Go retained heap under the same workload. Use `wox-memory-debug` for repeated-cycle attribution when the delta is unclear.\n- Treat a repeatable increase above 10 MiB or 5% of the warmed process footprint as material. Rework or reject the optimization unless the user explicitly accepts the tradeoff.\n\nDo not conclude that memory is unchanged from Go heap data alone. CoreGraphics, AppKit, IOSurface, decoded images, cgo allocations, and plugin hosts can increase process memory without appearing in the Go heap.\n\n## Report\n\nInclude:\n\n- OS, CPU architecture, debug tags, PID, warm-up, query pool or fixed query, and sample duration.\n- Query average/median/max process CPU and Go profile total samples versus duration.\n- Query top flat and cumulative Go owners, plus native owners when captured.\n- Hidden average/median/max process CPU and recurring Go/native stacks.\n- Before/after process footprint and Go retained-heap deltas when the optimization can affect memory ownership, including cache bounds and hide/close release behavior.\n- Whether activation, compilation, indexing, or another limitation contaminated a window.\n- On Windows, whether blocked Win32 calls contaminated pprof totals and whether native ETW stacks were available.\n- Classification for query CPU and hidden CPU, with the exact evidence supporting each.\n\n<!-- File: .agents/skills/wox-generate-smoke-test-case/agents/openai.yaml (Tokens: ~300 | Category: anthropic-skill) -->\n# Agents Skill\n\nPath: `.agents/skills/wox-generate-smoke-test-case/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-generate-smoke-test-case/agents/openai.yaml)\n\n<!-- File: .agents/skills/wox-generate-smoke-test-case/SKILL.md (Tokens: ~2478 | Category: anthropic-skill) -->\n---\nname: wox-generate-smoke-test-case\ndescription: Analyze Wox feature code and plugin-exposed settings, recommend high-value native UI smoke scenarios and user flows, then generate focused Go UI smoke test cases using the automation driver and shared-process harness. Use when the user asks to identify smoke coverage for a Wox feature or plugin, or to design, add, write, or generate a smoke case under wox.core/test/smoke.\n---\n\n# Wox Generate Smoke Test Case\n\nUnderstand the feature before choosing coverage. Recommend the smallest high-value real-process smoke flow, then reuse the current smoke harness and product automation surface instead of building test-only paths.\n\n## Discover the Feature\n\n1. Read the repository `AGENTS.md` and relevant `README.md` files. Inspect `git status`, unstaged changes, staged changes, and relevant untracked files without modifying unrelated work.\n2. Locate the feature's real user entry point, then trace the code end to end: UI component, interaction handler, controller or service, persisted state or side effect, visible result, error path, and cleanup. Search every caller of the shared function before deciding where coverage belongs.\n3. Inspect the smoke infrastructure and nearest existing coverage:\n   - `wox.core/test/smoke/harness.go`\n   - `wox.core/test/automationdriver/client.go`\n   - The closest existing case under `wox.core/test/smoke/`\n   - The UI code that owns the relevant automation IDs and actions\n4. Identify the main functional points, platform branches, important state transitions, failure recovery, and existing unit or smoke coverage. Base the list on concrete code paths, not UI labels or assumptions.\n\n### Interpret Settings Semantics\n\nFor every settings smoke case, determine why the setting exists and trace the runtime path that consumes it before writing the test.\n\n1. State a **setting semantic contract** in user terms: changing the setting from a chosen value to another must alter a specific real product behavior, not merely the displayed or persisted control value.\n2. Build deterministic preconditions that make that behavior observable. Ensure the input data crosses the relevant boundary; for example, a maximum-result setting needs more available results than the tested cap.\n3. Drive the setting through its owning Settings section, then exercise the actual user flow that consumes it. Assert the live UI, runtime artifact, platform effect, or persisted product output that proves the semantic contract.\n4. Do not treat a selected value, a reopened control, or persistence alone as sufficient smoke evidence. Those checks may support the flow, but the final assertion must cover the setting's real user-visible effect.\n5. Account for implementation details that can distort naive evidence, such as virtual-list overscan, pagination, debouncing, asynchronous saves, or cached results. Measure the actual user-visible viewport or outcome rather than incidental semantic-tree node counts when they differ.\n\n### Inspect Plugin Settings\n\nWhen the target is a plugin:\n\n1. Find every exposed setting in the plugin metadata `SettingDefinitions`, dynamic setting callbacks, and query/action forms. Record its key, type, default, validators, options, and visibility conditions.\n2. Search every read of each setting, including `GetSetting` calls, initialization, reload callbacks, and persistence code. Map the setting to the behavior it actually changes.\n3. Build a setting coverage matrix with: setting, affected user behavior, important values or boundaries, existing coverage, smoke value, automation feasibility, and recommendation.\n4. Recommend a smoke case when a setting changes query results, actions, enablement, persistence or reload behavior, platform integration, validation or recovery, or another user-visible cross-process boundary.\n5. Skip separate smoke coverage for headings, labels, layout-only fields, equivalent options already covered by one representative value, and branches better protected by unit tests. Avoid a case for every setting or every option.\n6. Group settings into one user flow only when they naturally belong to the same task and failures remain easy to diagnose. Keep independent high-risk behaviors in separate cases.\n7. Never require real secrets, uncontrolled network services, or unavailable hardware. Prefer deterministic missing/invalid configuration and local persistence behavior unless the dependency is explicitly controlled by the test environment.\n\n## Recommend Coverage\n\nWhen the user asks for coverage design, present:\n\n- **Code map:** Name the main source files, functions, and responsibilities.\n- **Functional points:** Summarize the primary user-visible behaviors and important boundaries.\n- **Candidate cases:** Recommend no more than five flows, ordered by value. For each, include priority, user risk, existing coverage gap, prerequisites, actions, observable expected result, and automation feasibility.\n- **Plugin setting matrix:** For plugin requests, show which exposed settings deserve smoke coverage, which do not, and the source-backed reason for each decision.\n- **Recommended first case:** Select the smallest flow that covers the highest-risk real integration boundary and explain briefly why it belongs in smoke rather than a unit test.\n- **Automation gap:** Identify any missing stable automation ID or action required by the recommended flow.\n\nWhen the user already specified the exact flow, keep the pre-edit design brief: present only the code map, one observable behavior contract, and any automation gap. Do not expand an approved flow into an unnecessary candidate list or full setting matrix.\n\nRecommend smoke coverage only for real-process native UI, lifecycle, persistence, plugin integration, platform, accessibility, or rendering boundaries. Prefer unit tests for local pure logic and skip behavior already covered at the same boundary.\n\nIf the user asked only for design, stop after the recommendation. If the user already named or approved an exact flow, continue. Otherwise ask which recommended case to generate before editing product or test code.\n\n## Generate the Case\n\n1. State one observable behavior contract for the selected flow.\n2. Search all smoke packages for an existing helper before adding a local one. Promote a helper to `automationdriver` or `smoke` when a second consumer uses the same interaction contract; keep plugin-specific behavior in the leaf package. Avoid page-object layers or table-editor DSLs until repeated cases justify them.\n3. Reuse existing automation IDs, actions, `smoke.Case`, and helpers. Before driving a control, confirm its semantics expose a stable ID, role, label, current value or checked state, selected state when relevant, and the correct action. If that contract is missing, modify the smallest shared owning UI component to add a stable automation ID or semantic action, then add a focused component test for that contract. The semantic action must follow the real user interaction path; do not add a test-only bypass around product behavior.\n4. Add the case under the owning functional path. Reserve `wox.core/test/smoke/setting/` for Wox's own settings sections, such as `setting/ui/`. Every plugin-owned case must live under `wox.core/test/smoke/launcher/plugin/<plugin>/`, including flows that configure the plugin through its Settings page before exercising Launcher behavior. Classify by product owner rather than the UI route used during the flow; for example, place Calculator coverage under `launcher/plugin/calculator/`. Use the next unused three-digit number without renumbering existing cases:\n   - File: `NNN_descriptive_name_test.go`\n   - Function: `TestNNNDescriptiveName`\n   - Build constraint: `//go:build wox_ui_smoke`\n5. Immediately above every generated `TestNNN...` function, add a concise English doc comment that states the user-visible intent, the ordered UI flow, and the final evidence that proves the behavior. Mention prerequisites or cleanup only when they are part of the contract. Describe product behavior rather than automation implementation details. Use this shape:\n\n   ```go\n   // TestNNNDescriptiveName verifies <user-visible behavior and boundary>.\n   // Flow: <entry> -> <important actions or state transitions> -> <observable result>.\n   // Evidence: <real UI, runtime, persisted artifact, or log assertion that proves success>.\n   func TestNNNDescriptiveName(t *testing.T) {\n   ```\n\n6. Drive the UI through `automationdriver.Client` semantic actions (`Perform`, `PressKey`, `SetValue`) and `client.WaitFor`. Never use fixed sleeps to guess readiness. Use postconditions such as `Selected`, `Checked`, `Value`, status, or disappearance. Do not use mouse clicks, drags, node bounds, pointer coordinates, or screenshot pixels when a semantic action can produce the same transition. A real pointer or OLE drag is allowed only when the behavior under test is that native gesture and no semantic action exists. Even then, do not assert desktop hit-testing: which other HWND became foreground, title-bar or caption-button coordinates, z-order, or that a fixed client point such as a window center stays uncovered. Developer screens and CI desktops overlap differently. Assert Wox's own outcome (visibility, query result, callback, or file artifact). If a point is unavoidable, derive it at runtime from current window rects and keep it off other windows in the case.\n7. Treat query and result state as generation-bound. Setting the same query value may be a no-op, and refreshes may replace dynamic result IDs. Force a real query transition when freshness matters, wait for both the input value and `launcher.results=complete`, and resolve dynamic IDs again after refresh instead of retaining them across generations.\n8. Treat every command executed by a smoke case as interpreter- and platform-dependent input. Confirm the interpreter the case actually selects or inherits on Windows, macOS, and Linux. Prefer the simplest syntax shared by all targeted interpreters; do not assume Bash operators such as `&&`, `export`, Unix paths, or Unix-only tools work in Windows PowerShell. When no shared command exists, select the command with `runtime.GOOS` and, when configurable, the chosen interpreter, while keeping output and side effects equivalent. Normalize path separators and line endings in assertions. If the behavior is intentionally platform-specific, skip it explicitly with the reason instead of waiting for an impossible state.\n9. Let `smoke.Case` own before/after reset and the shared client, but do not assume reset restores plugin settings or desktop side effects. Explicitly restore changed settings and clean external state. Reopen settings or inspect persisted data before exercising runtime behavior; a locally updated control does not prove an asynchronous save completed.\n10. Keep assertions user-visible and deterministic. Prefer evidence in this order: real runtime artifact or fresh log slice, reloaded persisted value, then live semantic state. Treat relevant snapshot diagnostics as failures. Do not weaken assertions or add retries merely to hide a race.\n11. Do not launch another Wox process or create a second data directory inside a case. Use `automationdriver.SharedDataDirectoryEnvironment` only when the behavior must inspect real persisted output, and poll artifacts independently of UI generation changes.\n12. Format every touched Go file with the repository formatter. Run the new case from the repository root:\n\n   ```text\n   make smoke <functional/path/NNN>\n   ```\n\n13. After the targeted case passes, run `make smoke` to catch leaked state and shared-process cleanup failures. If the full suite fails in an existing case, distinguish that baseline failure from the new selector instead of attributing it to the new coverage. If execution is blocked by the environment, report the exact blocker and do not claim runtime coverage.\n\n## Failure Handling\n\n- Start from the exact command output, logs, snapshot, and failing state.\n- On a wait failure, capture the current values, checked states, status nodes, diagnostics, and relevant fresh log or artifact contents. Report the observed boundary instead of only the timeout.\n- Fix the shared product or automation boundary when that is the root cause; do not patch every case around it.\n- Add diagnostic logging only when the failure path cannot be identified with certainty, then use the new evidence before changing behavior.\n- Preserve unrelated worktree changes and keep the diff limited to the case plus any strictly required automation exposure.\n\n## Completion\n\nReport the behavior covered, the created case selector, every production or automation file changed to support it, and the exact verification commands with pass or failure status.\n\n<!-- File: .agents/skills/wox-i18n/agents/openai.yaml (Tokens: ~300 | Category: anthropic-skill) -->\n# Agents Skill\n\nPath: `.agents/skills/wox-i18n/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-i18n/agents/openai.yaml)\n\n<!-- File: .agents/skills/wox-i18n/SKILL.md (Tokens: ~1043 | Category: anthropic-skill) -->\n---\nname: wox-i18n\ndescription: Add a new Wox language or complete and improve an existing Wox translation. Use for Wox-owned locale registration, translation parity, wording quality, and placeholder-safe updates based on wox.core/resource/lang/en_US.json.\n---\n\n# Wox I18n\n\nUse `wox.core/resource/lang/en_US.json` as the authoritative source for keys, meaning, structure, and placeholders. Work on one requested locale at a time unless the user explicitly asks for several.\n\n## Shared rules\n\n- Read the repository `AGENTS.md` and the relevant locale files before editing.\n- Preserve every placeholder exactly, including `{name}`, Wox placeholders such as `{wox:selected_text}`, printf verbs such as `%s` and `%02d`, newlines, and other formatting tokens. Reordering placeholders is allowed only when the format mechanism supports it and the target language requires it.\n- Resolve ambiguous English by searching for the key's call sites and neighboring translations. Translate the UI meaning, not the key name in isolation.\n- Keep product names, commands, file paths, URLs, keyboard shortcuts, and technical identifiers unchanged when they are proper names or literal input.\n- Match the tone and terminology already used by the target locale. Prefer natural, concise UI text over literal translation.\n- Keep JSON valid, formatted with two-space indentation and a final newline. Preserve English key order; insert missing entries beside their English counterparts instead of reordering unrelated entries.\n- Do not put Wox-owned translations in Go maps. Keep them in `wox.core/resource/lang/*.json` and reference them with `i18n:` keys, as required by the repository instructions.\n- Do not blanket-translate third-party entries in `store-plugin.json`; their translations belong to their authors. Wox-owned catalogs such as `store-ai-command.json` are in scope when they contain the target locale.\n\n## Choose the workflow\n\n### Add a new language\n\nUse commit `0cfb2a346af4278c5cd385aa649cb9ddb641f461` as a concrete checklist, but follow the current tree when it has evolved:\n\n```powershell\ngit show --stat 0cfb2a346af4278c5cd385aa649cb9ddb641f461\ngit show 0cfb2a346af4278c5cd385aa649cb9ddb641f461 -- wox.core/i18n/lang.go store-ai-command.json wox.core/ui/launcher/view/form_table_view_test.go www/docs/.vitepress/theme/components/pluginStore.ts www/docs/development/plugins/specification.md www/docs/zh/development/plugins/specification.md AGENTS.md\n```\n\nThen make the smallest complete current-tree change:\n\n1. Confirm the locale code, English language name, and native display name.\n2. Create `wox.core/resource/lang/<locale>.json` with every key from `en_US.json`, in the same order, fully translated.\n3. Register the `LangCode` and native display name in `wox.core/i18n/lang.go`.\n4. Add the locale to Wox-owned locale maps, currently including `store-ai-command.json`, and to website locale mapping where applicable.\n5. Update current supported-language documentation and any tests that explicitly enumerate languages or translated labels.\n6. Search for the existing locale codes to find registration surfaces added after the reference commit. Update only surfaces whose behavior depends on the complete supported-language list.\n\nDo not create a translated documentation site merely because the app gains a locale; add one only when the user requests and supplies that scope.\n\n### Complete or improve an existing language\n\n1. Run the checker to identify missing, extra, empty, identical-to-English, and placeholder-mismatched values.\n2. Add every missing English key and translate it from the English value. Treat identical values as review candidates, not automatic errors: names and technical terms may legitimately remain English.\n3. For requested quality improvements, inspect awkward or stale values in related groups and their call sites. Change only wording you can improve confidently.\n4. Remove an extra key only after confirming that it is absent from `en_US.json` and unused; otherwise report it for review.\n5. Check Wox-owned auxiliary catalogs, especially `store-ai-command.json`, for missing target-locale entries when the request is to complete the language across Wox.\n\nAvoid replacing the whole locale file when a focused insertion or wording edit produces a clear diff.\n\n## Verification\n\nRun from the repository root:\n\n```powershell\npython .agents/skills/wox-i18n/scripts/check_locale.py <locale>\ngit diff --check\n```\n\nThe checker must pass without missing keys, extra keys, empty values, or placeholder mismatches. Review its identical-value warnings manually.\n\nIf language registration or enumerating tests changed, run the focused Go tests from `wox.core`:\n\n```powershell\ngo test ./i18n ./ui/launcher/view\n```\n\nFinish by reviewing the diff for accidental English fallback text, placeholder damage, unrelated rewrites, and omissions from the reference-commit checklist.\n\n<!-- File: .agents/skills/wox-memory-debug/agents/openai.yaml (Tokens: ~300 | Category: anthropic-skill) -->\n# Agents Skill\n\nPath: `.agents/skills/wox-memory-debug/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-memory-debug/agents/openai.yaml)\n\n<!-- File: .agents/skills/wox-memory-debug/SKILL.md (Tokens: ~2873 | Category: anthropic-skill) -->\n---\nname: wox-memory-debug\ndescription: Diagnose memory leaks in the current single-process Wox Go UI by launching the real debug build with its automation endpoint enabled, replaying representative launcher searches and settings-window open/close cycles, sampling the same process across repeated workload blocks, and comparing Go heap profiles when retained memory keeps growing. Use for Wox memory-leak checks, search-result retention, settings cleanup, Go UI memory growth, or repeated UI lifecycle regressions on Windows or macOS.\n---\n\n# Wox Memory Debug\n\n## Goal\n\nRun the real Go UI in debug mode with the `wox_automation` endpoint, exercise normal launcher searches and the independent settings-window lifecycle through the semantics tree, and decide whether memory settles after warm-up or grows with repeated work. Treat Wox as one Go process and use post-warm-up growth rather than an absolute memory budget as the leak criterion.\n\n## Run the Debug Build\n\n1. Stop other Wox instances so sampling cannot select the wrong process.\n2. Start the real Wox debug build under Delve with both production dependencies and the automation endpoint enabled:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\nWOX_AUTOMATION_INFO_FILE=/tmp/wox-memory-automation.json /Users/qianlifeng/go/bin/dlv debug . --build-flags=-tags=sqlite_fts5,wox_automation\n```\n\n3. At the Delve prompt, run `continue`.\n4. Wait until startup and plugin initialization finish, then wait for `WOX_AUTOMATION_INFO_FILE` to be written.\n5. Record the debuggee PID from the debugger. Always pass this PID to the sampler because debugger-built executables may have temporary names.\n\nKeep the debugger running normally. Do not pause at breakpoints while collecting memory samples. This uses the real Wox process with only the automation server compiled in; do not launch the separate Go UI smoke-test runner.\n\n## Establish a Warm Baseline\n\nUse the bundled automation workload driver against the real launcher:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\ngo run ../.agents/skills/wox-memory-debug/scripts/run-query-workload.go -info /tmp/wox-memory-automation.json -mode queries -count 20 -seed 1\n```\n\n1. Run two warm-up blocks before recording the baseline.\n2. In each block, replay 20 queries drawn repeatedly from these safe categories:\n   - Calculator, such as `1+1`.\n   - System command lookup, such as `settings`.\n   - Application or general search, such as `wox`.\n   - File-oriented search, such as `readme`.\n3. Use a different deterministic seed for each block so the workload is reproducible while still varying result types.\n4. The driver waits for the query value, allows results to settle, records the visible result count and semantics generation, clears the query, and continues. It does not execute results or commands.\n5. At the end of the block, the driver hides the launcher. Wait 10 seconds so every checkpoint uses the same idle state.\n\nTake the warm baseline only after these blocks. Initial startup growth, lazy font loading, icon decoding, and cache creation are expected and are not leak evidence.\n\n## Sample the Same Process\n\n### macOS\n\n```bash\n/Users/qianlifeng/Projects/Wox/.agents/skills/wox-memory-debug/scripts/sample-wox-memory-macos.sh --pid <PID> --samples 3 --interval 2\n```\n\nUse `PhysicalFootprintMB`. Absolute debug memory is not the leak criterion.\n\n### Windows\n\n```powershell\npowershell -ExecutionPolicy Bypass -File C:\\dev\\Wox\\.agents\\skills\\wox-memory-debug\\scripts\\sample-wox-memory.ps1 -Pids <PID> -Samples 3 -IntervalSeconds 2\n```\n\nUse `PrivateWorkingSetMB`.\n\nDo not compare macOS physical footprint with Windows private working set. Compare checkpoints from the same PID, OS, debug session, workload, and idle state.\n\n## Run the Measured Query Workload\n\n1. Record the warm baseline.\n2. Run five measured blocks of 10 or 20 queries using distinct seeds and the same query pool.\n3. After each block, clear the query, hide the launcher, wait 10 seconds, and sample the same PID three times.\n4. Record the median of each three-sample checkpoint to reduce sampler noise.\n5. Report cumulative query count, median memory, change from the warm baseline, and the observed shape of the series.\n\nUse more blocks only when the trend is ambiguous. Keep the process alive for the whole run; restarting Wox invalidates the comparison.\n\n## Test Settings Window Cleanup\n\nRun this lifecycle check after the query workload. It opens settings through the real `Open Wox Settings` result, waits for the independent settings semantics host, closes the settings window, waits until the launcher host owns automation again, and clears the opening query:\n\n```bash\ncd /Users/qianlifeng/Projects/Wox/wox.core\ngo run ../.agents/skills/wox-memory-debug/scripts/run-query-workload.go -info /tmp/wox-memory-automation.json -mode settings -count 1\n```\n\n1. Run one settings cycle as warm-up. Wait 10 seconds and record the closed-settings baseline.\n2. Run at least three measured blocks of five open/close cycles:\n\n```bash\ngo run ../.agents/skills/wox-memory-debug/scripts/run-query-workload.go -info /tmp/wox-memory-automation.json -mode settings -count 5\n```\n\n3. After each block, keep both launcher and settings closed, wait 10 seconds, and sample the same PID three times. Record the median.\n4. Confirm every cycle reports both an `opened_generation` and `closed_generation`. The driver considers close complete only after `settings-search-field` disappears and `launcher.query.input` returns, which means `settingsView` and `settingsHost` have left the active automation surface.\n5. Compare measured block medians with the post-warm-up closed-settings baseline. Repeat one identical five-cycle block after a 30-second idle checkpoint when the trend is ambiguous.\n\nThe first settings open may retain shared fonts, icons, and reusable renderer caches. Do not require the process to return to its pre-first-open value. Window-scoped settings state and native resources must not accumulate across later cycles: after warm-up, closed-settings checkpoints should plateau within sampler jitter instead of growing with cumulative open/close count.\n\n## macOS Debug Reference\n\nUse the August 10, 2026 macOS arm64 run as a comparison point for the current settings cleanup behavior, not as an absolute budget. The run used macOS 26.5.2, Go 1.26.2, Delve 1.26.2, the `sqlite_fts5,wox_automation` build tags, real Wox data, one PID, a 10-second hidden/closed wait, and three `PhysicalFootprintMB` samples at two-second intervals.\n\nThe query baseline was recorded after two 20-query warm-up blocks. The settings baseline was recorded after one complete warm-up open/close cycle:\n\n| Checkpoint | Median PhysicalFootprintMB | Change from closed-settings baseline |\n| --- | ---: | ---: |\n| Hidden after 40 warm-up queries | 89.1 MB | N/A |\n| Settings closed warm baseline | 99.5 MB | 0.0 MB |\n| 5 measured settings cycles | 100.9 MB | +1.4 MB |\n| 10 measured settings cycles | 101.4 MB | +1.9 MB |\n| 15 measured settings cycles | 101.7 MB | +2.2 MB |\n| 30-second idle confirmation | 102.3 MB | +2.8 MB |\n\nClassify this series as `no leak signal`: the closed-settings checkpoints remained around 100-102 MB, and the 30-second confirmation stayed within observed sampler and allocator variation. `vmmap` reported no resident IOSurface memory after close; CoreGraphics and IOAccelerator residency was negligible. A Go heap comparison captured during the investigation showed only about 15 KB of retained delta, which redirected attribution to native window ownership rather than Go settings state.\n\nPreserve these cleanup contracts when investigating a regression:\n\n- Keep at most one live `wox.settings` window, while still treating each close/reopen as a new native lifetime.\n- Release settings-only plugin catalogs, search indexes, forms, and application candidates on close, and invalidate in-flight loads so they cannot refill released caches.\n- Load the plugin store and application candidates only when their UI needs them.\n- Release the macOS `NSWindow`, view, and delegate hierarchy synchronously on close. Do not defer them to the application-lifetime autorelease pool.\n\nBefore the native close fix, a separate same-shape debug run rose from 104.8 MB after the warm settings close to 112.8 MB after 15 measured cycles. Treat a return of that cumulative, window-count-scaled shape as a regression even when the absolute starting footprint differs.\n\n## Windows Debug Reference\n\nUse the September 22, 2026 Windows run as a comparison point for hidden idle memory, not as a budget. The run used a dev build with `sqlite_fts5,wox_automation`, real Wox data, two 20-query warm-up blocks, and three `PrivateWorkingSetMB` samples 45 seconds after hide, when both the 10-second and 30-second release stages had run:\n\n| Checkpoint | Median PrivateWorkingSetMB | Live Go heap |\n| --- | ---: | ---: |\n| Staged trims plus prepared search text and pinyin release | 63.8 MB | 17.2 MB |\n| Shared plugin logger and shared fsnotify watcher | 60.8 MB | 15.2 MB |\n| Live-object reductions (`wox.core/ui/README.md`, \"Hidden-state ownership rules\") | 55.4 MB | 11.0 MB |\n\nHidden memory drops in two steps: about 2-4 MB at 10 seconds and about 40 MB at 30 seconds, so sampling before 45 seconds compares different lifecycle states. When attributing what remains, use Delve `goroutines -group userloc` for goroutine ownership and the `woxmemory go` / `woxmemory native` commands for the Go-versus-native split; the largest native owners are NT heap fragmentation from show/hide churn and renderer objects that survive hide.\n\n## Decide Whether Memory Leaks\n\nInterpret the post-warm-up series, not a single number:\n\n- **No leak signal:** memory rises during warm-up and then plateaus, oscillates within a stable range, or drops after an idle checkpoint.\n- **Possible leak:** the settled checkpoint median keeps increasing across at least three consecutive measured blocks and the increase is materially larger than sampler jitter.\n- **Strong leak signal:** retained growth continues after another identical workload, scales with cumulative query or settings-cycle count, and does not settle during a longer 30-60 second idle checkpoint.\n\nApply the same classification independently to cumulative queries and cumulative settings cycles. A stable query series does not rule out a settings-window lifecycle leak.\n\nGo may retain heap arenas after objects become unreachable, so a high or non-decreasing process footprint alone is not proof. Report the result as `no leak signal`, `possible leak`, or `strong leak signal`, together with the measurements that support it.\n\n## Attribute Persistent Growth\n\nOnly profile after the repeated-query or settings-lifecycle run shows a possible or strong leak signal.\n\n1. Trigger the Wox Memory plugin's `woxmemory profile ` command through the automation driver after warm-up:\n\n```bash\ngo run ../.agents/skills/wox-memory-debug/scripts/run-query-workload.go -info /tmp/wox-memory-automation.json -mode profile\n```\n2. Copy the generated profile immediately because the next capture overwrites it:\n\n```bash\ncp ~/.wox/memory.prof /tmp/wox-memory-before.prof\n```\n\nOn Windows, copy `%USERPROFILE%\\.wox\\memory.prof` to a distinct temporary file instead.\n\n3. Repeat the measured workload, run the command again, and copy the second profile:\n\n```bash\ncp ~/.wox/memory.prof /tmp/wox-memory-after.prof\n```\n\n4. Compare retained Go heap growth from `wox.core`:\n\n```bash\ngo tool pprof -top -base /tmp/wox-memory-before.prof /tmp/wox-memory-after.prof\n```\n\nIf process memory grows but the Go heap delta stays small, inspect Go UI native owners next: GPU textures and image caches, decoded result icons, preview resources, platform window allocations, and query-result cleanup. For settings-only growth, inspect `settingsView`, `settingsHost`, settings editors/forms, theme wallpaper previews, cloud/model state, asynchronous reloads, and native window/renderer destruction. On macOS, compare `vmmap <PID> -summary` checkpoints and pay particular attention to `IOAccelerator` and `IOSurface`. If repeated identical queries still grow, inspect lazy-image cache identity, per-draw Metal texture creation, and drawable-size churn before attributing growth to unique query strings.\n\nUse `-query terminal` with query mode for an identical-query control only when the mixed workload needs further attribution.\n\n## Report\n\nInclude:\n\n- OS, debug configuration, PID, workload, and checkpoint timing.\n- A checkpoint table with cumulative queries and median process memory.\n- A separate closed-settings checkpoint table with cumulative open/close cycles and median process memory.\n- The trend classification and whether a longer confirmation block was needed.\n- Go heap delta owners only when profiling was necessary.\n- Any limitation that prevented consistent UI automation or reliable sampling.\n\nDo not edit production code until the measurements identify a reproducible trend and a likely owner.\n\n<!-- File: .agents/skills/wox-plugin-creator/references/hotkeys.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/hotkeys.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/hotkeys.md)\n\n<!-- File: .agents/skills/wox-plugin-creator/references/html_preview_updates.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/html_preview_updates.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/html_preview_updates.md)\n\n<!-- File: .agents/skills/wox-plugin-creator/references/icons.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/icons.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/icons.md)\n\n<!-- File: .agents/skills/wox-plugin-creator/references/plugin_i18n.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/plugin_i18n.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_i18n.md)\n\n<!-- File: .agents/skills/wox-plugin-creator/references/plugin_json_schema.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/plugin_json_schema.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_json_schema.md)\n\n<!-- File: .agents/skills/wox-plugin-creator/references/plugin_overview.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/plugin_overview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_overview.md)\n\n<!-- File: .agents/skills/wox-plugin-creator/references/plugin_tools.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/plugin_tools.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/plugin_tools.md)\n\n<!-- File: .agents/skills/wox-plugin-creator/references/refinements.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/refinements.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/refinements.md)\n\n<!-- File: .agents/skills/wox-plugin-creator/references/scaffold_nodejs.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/scaffold_nodejs.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/scaffold_nodejs.md)\n\n<!-- File: .agents/skills/wox-plugin-creator/references/scaffold_python.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/scaffold_python.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/scaffold_python.md)\n\n<!-- File: .agents/skills/wox-plugin-creator/references/sdk_nodejs.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/sdk_nodejs.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/sdk_nodejs.md)\n\n<!-- File: .agents/skills/wox-plugin-creator/references/sdk_python.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/wox-plugin-creator/references/sdk_python.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/Wox-launcher/Wox/HEAD/.agents/skills/wox-plugin-creator/references/sdk_python.md)\n\n<!-- ... +66 more modular skills available via /api/skills/Wox-launcher/Wox?path={path} -->\n</yakaai_skills>"}