Security audit
Security checks for vulnerabilities and agentic risk
This appears to be a disclosed Windows window-switching helper, but it can list window titles and switch focus automatically.
Install only if you are comfortable with a skill enumerating visible window titles and changing the active window. Prefer explicit app names, require confirmation for short or ambiguous aliases, and verify the missing d-switch.ps1/d-switch.cmd files before relying on the package.
Hidden instructions were detected in comments or invisible text. These could contain malicious directives. Manual review is recommended.
# TOOLS.md
## Runtime
Hidden instructions were detected in comments or invisible text. These could contain malicious directives. Manual review is recommended.
# TOOLS.md
## Runtime
The skill explicitly instructs the agent to directly activate windows and even says that on a 'high-confidence' match it should proceed without asking the user. That creates a user-consent and UI-safety issue: the agent may unexpectedly steal focus, interrupt the user, or switch to the wrong window based on fuzzy matching, which can expose private content or trigger unintended downstream actions in the newly focused application.
The activation intent uses very broad natural-language examples such as switching to common apps, which can easily overlap with ordinary conversation and cause unintended invocation. In a skill that manipulates OS window focus, accidental activation can disrupt user workflow, expose on-screen content, or redirect input to an unintended application.
The tab-switching intent is defined with generic phrases like 'switch tab' and 'next tab' without strong contextual constraints, making accidental matching more likely. Because the skill sends UI-navigation actions to the active window, a false trigger could change context in another application and lead to unintended user actions or data exposure.
The window-listing intent includes broad examples such as 'show current program list,' which may collide with normal assistance requests. In this skill's context, unintended execution could enumerate running applications and reveal sensitive user activity or application names to an unintended consumer of the output.
The operational instructions are written as mandatory directives in Chinese, indicating the skill's behavior is constrained to a specific language/locale. There is no indication that the user can choose another language or that the Chinese-only behavior is justified by a region-specific purpose.
The checklist items are written in Chinese with no indication that the skill is region-specific or that users may choose another language. The policy explicitly flags language or locale constraints when they are imposed without opt-in or documented justification.
The skill explicitly sets the agent identity and behavior in Chinese without indicating that language choice should follow user preference. This can override or conflict with the user's requested language, reducing usability and potentially causing unsafe misunderstandings if instructions are delivered in an unexpected language.
The safety and usage warnings in the Gotchas section are written only in Chinese, while the rest of the document is in English. This imposes a locale/language constraint on users without opt-in or an explicit justification, which is a natural-language policy violation under the stated rules.
The preference entry "Communication: 简洁直给" is written as a fixed communication setting in Chinese, which can imply a language/locale constraint without offering the user a choice. The policy allows locale constraints only when user opt-in is explicit or the constraint is clearly justified.
The instructions, test cases, and expected AI behaviors are entirely specified in Chinese, with no indication that users may interact in other languages or that the skill is intentionally restricted to a Chinese-language context. Under the policy, forcing a specific language without opt-in or clear justification is a natural-language policy concern.
The onboarding steps are written as mandatory Chinese-language user interactions ('询问用户...') with no indication that the user can choose another language. This creates a natural-language locale policy concern because it implicitly forces a specific language without user opt-in or justification.
The file's operational instructions and examples are presented entirely in Chinese, which effectively forces a specific language for users reading or following the skill guidance. There is no indication that this is a region-specific skill or that users can choose another language.
The aliases include broad terms like "vs" and other generic product abbreviations that can match ordinary speech or references to unrelated tools. In a skill that uses these aliases to select or focus windows, accidental activation can cause actions to be directed at the wrong application, which is a real security and safety issue when later automation performs clicks, keystrokes, or data entry.
This section contains highly generic triggers such as "py", "ws", "as", and similar shorthand that are not uniquely tied to one application. If downstream automation trusts these mappings, normal user language can invoke the wrong target and redirect privileged UI actions into an unintended process.
Single- and two-letter aliases like "st", "ps", and similar entries are extremely ambiguous in natural language and across software ecosystems. In an agent skill that maps speech or text to active applications, this can reliably produce unintended invocation and misdirect subsequent automated actions.
Keywords such as common tool categories or ordinary words can overlap with normal requests rather than intentionally naming an application. That increases the chance that benign conversation is interpreted as a command target, which is dangerous in a window-control or app-selection skill.
Using "api" as an alias is especially unsafe because it is a common technical term that appears in many unrelated requests. In a developer-oriented skill, this context makes false activation more likely, not less, because users frequently discuss APIs without intending to select Postman or another app.
Aliases like "wt", "terminal", and especially "ps" are common abbreviations and ordinary technical words, making them poor secure triggers. Because terminal and shell windows often hold sensitive sessions, accidental focus or command routing to the wrong console can have outsized consequences compared with ordinary desktop apps.
Category-level terms like general CRM or business descriptors do not uniquely identify a single product and can match many unrelated user intents. In a sales/business workflow, misrouting actions into the wrong CRM or document tool can expose customer data or modify records unintentionally.
The acronym "crm" is reused for multiple products, so the same user input can resolve ambiguously to different applications. Ambiguous resolution in enterprise tooling is a genuine security risk because it may direct automation to the wrong customer database or communication platform.
Creative-tool aliases such as "pr", "ae", "ps", "ai", "au", "me", and "lr" are short, overloaded abbreviations that frequently occur in unrelated contexts. In media-production workflows, accidental activation can redirect edits, recordings, or exports to the wrong application, causing data leakage, destructive actions, or operational mistakes.
This markdown file instructs the AI to directly execute window-activation commands such as activate-window and says no user query is needed for a high-confidence match. Because the behavior changes the active desktop window and can affect the user's current workflow, the skill description should disclose that it may switch focus automatically.
This markdown file documents Dalt/Dctrl shortcut simulation and a fallback to Dalt -1, which can alter the user's active application or tab. The section explains usage but does not include a user-facing warning about possible unintended focus changes or interference with current work.