Security audit
Security checks for vulnerabilities and agentic risk
This is a simple OpenAPI documentation helper skill with loose trigger wording but no hidden execution, persistence, credential access, or destructive behavior.
Installers should be aware that the skill may activate on broad API or developer-experience phrasing. Use it for explicit OpenAPI, Swagger, REST API documentation generation, validation, or improvement tasks, and prefer clearer trigger text if maintaining the package.
The trigger sentences are highly generic and partly malformed, and they overlap with ordinary user requests about OpenAPI or workflows. This can cause the skill to activate unintentionally in contexts where the user did not explicitly request it, leading to wrong-tool selection, prompt hijacking exposure, or unexpected handling of user input.
The trigger phrases are broad enough to match ordinary requests about APIs, documentation, or developer experience, which can cause this skill to activate outside its intended scope. In an agent system, overbroad activation can route unrelated user tasks into this skill, increasing the chance of incorrect behavior, prompt interference, or unintended handling of user input.
The manifest description uses broad activation terms like 'workflow,' 'artifact,' 'checklist,' 'analysis,' and 'implementation support' alongside common API-related words. This can cause the skill to activate on loosely related developer requests, leading to inappropriate routing, prompt-scope expansion, or interception of tasks not specifically about OpenAPI/Swagger documentation.
The trigger keywords include generic terms such as 'software-and-data' and 'developer experience' that are too broad to safely distinguish this skill from unrelated engineering tasks. Overbroad triggers increase the chance of accidental invocation, which can misroute user requests and expose the system to prompt-scope abuse through inappropriate skill selection.
The skill description defines usage conditions with a very wide scope and unclear boundaries, covering broad categories like software-and-data and general API-related requests. This ambiguity can lead to inappropriate routing, where the skill is selected for tasks beyond documentation support, reducing reliability and potentially causing unsafe or irrelevant actions.
The trigger keywords include broad generic terms such as "software-and-data", "openapi", and "rest api", which can match many unrelated user requests and cause the skill to be invoked outside its intended scope. Over-broad activation increases the chance that the agent applies the wrong workflow, mishandles user intent, or exposes downstream tooling and prompts to contexts they were not designed for.
The default prompt contains a very broad natural-language trigger phrase about helping with OpenAPI/Swagger documentation, and the policy explicitly allows implicit invocation. That combination increases the chance the skill will auto-trigger during ordinary API-related conversations, causing unintended routing, context injection, or unexpected tool use without clear user intent.
The trigger sentence begins with a very broad everyday phrase ('Help me ...'), which can cause the skill to activate for loosely related requests instead of only for OpenAPI/Swagger documentation tasks. In agent-routing systems, ambiguous activation boundaries increase the chance of unintended invocation, context capture, and execution of the wrong skill, which can mis-handle user input or expose downstream workflows to prompt-confusion risks.
The trigger sentence 'I need a practical workflow for ...' is still too generic and does not clearly constrain activation to OpenAPI/Swagger documentation work. Such ambiguity can cause accidental skill selection for unrelated workflow requests, creating routing errors and increasing the chance that an adversarial or irrelevant prompt is processed under the wrong operational assumptions.
The file lists separate English and Chinese documentation files but does not state how language selection occurs or that users can choose their preferred locale. Because locale choice is not explicitly offered in the user-facing text, this can be read as an undocumented language-handling policy gap.
This file is presented as a Chinese README, but key descriptive content and user-facing trigger phrases are written in English. That creates a locale consistency issue because the skill appears to impose English-language interaction in a zh-CN context without explicit user opt-in or documented justification.
The example triggers are truncated and awkwardly phrased, such as 'Help me Backend and platform teams need practical help...,' which does not provide a clear, realistic activation pattern. Poorly formed examples increase ambiguity about what should actually invoke the skill.
The example trigger phrases are not discriminative and largely repeat the broad requirement statement without showing clear boundaries or non-triggering cases. This makes it harder for routing logic or operators to understand when the skill should not activate, increasing accidental invocation risk.
