Runtime Debug Skill

The stated purpose (collect and analyze runtime traces for Python/Node/Java) aligns with many of the instructions (install SDK, instrument entrypoint, collect traces). However the skill metadata declares no required environment variables or credentials while the instructions repeatedly require an API_KEY, apiKey/projectId/appName values, and even advise adding repository tokens to pom.xml — an internal inconsistency. Requiring a private Maven/GitHub token in pom.xml is plausible if the SDK is hosted in a private registry, but the skill metadata should declare that. Because the declared requirements don't match what the SKILL.md expects, this is a concern.

The SKILL.md instructs modifying project entrypoints (inserting initialization code that includes API keys), creating reproduction tests, adding instrumentation files, editing project- and user-level IDE config (e.g., ~/.vscode/settings.json, .cursor/mcp.json) to register an MCP server that runs 'npx @syncause/debug-mcp@latest', and contacting network endpoints (wss://api.syn-cause.com/codeproxy/ws). These are invasive, persist in the repository or user config, and place secrets in code/config. The instructions also demand generating an installation patch (.syncause/installation.patch) and explicitly advise not to use git diff — an odd instruction that increases suspicion. Overall the scope goes beyond benign guidance and allows large changes and remote execution.

There is no packaged install spec in the registry metadata (instruction-only), but the included language guides instruct running remote installers: 'curl https://raw.githubusercontent.com/... | bash', installing a wheel from a GitHub release URL, and running 'npx -y @syncause/debug-mcp@latest'. These are high-risk operations: piping remote scripts to bash and executing packages from npm are common but inherently risky unless you fully trust and review the source. The Java flow also instructs adding a repository URL with embedded tokens to pom.xml to pull artifacts from GitHub Packages. All of these downloads/executions write code to disk and may run arbitrary code.

The skill metadata declares no required env vars/credentials, but the instructions require and propagate API keys (apiKey/projectId/appName) into injected code and config, and explicitly show an example of two concatenated tokens added to pom.xml properties (syncause.repo.token.p1/p2) — the samples look like real tokens. The skill also asks to set API_KEY in multiple IDE/user config files for the MCP server. Asking users to place long-lived tokens into project files or pom.xml (committed config) is disproportionate and dangerous. The lack of declared primaryEnv is an inconsistency.

The skill doesn't require 'always: true', but its instructions explicitly instruct writing persistent files and configs in both project and user home directories (e.g., .syncause/installation.patch, instrumentation files, .vscode/.mcp configs, ~/.cursor/mcp.json). It also instructs adding instrumentation that opens a WebSocket (wss://api.syn-cause.com/codeproxy/ws) and configuring Maven plugins that will run at build time. These actions create persistent agent-like behavior and modify global IDE settings, increasing long-term privilege and attack surface. The skill itself doesn't request platform-level privileges, but the instructions grant broad persistent presence if followed.