Stock-Decision

This skill generally does what it says (technical indicators, macro web-search, backtests), but there are implementation-level risks you should consider before installing or running it: - Command-injection risk: Several scripts construct shell commands with user-supplied strings and call subprocess.run(..., shell=True). If you or others can pass arbitrary stock names/codes to the skill, those inputs could include shell metacharacters and execute unexpected commands. Prefer running in a sandbox or patch scripts to use subprocess.run([...], shell=False) with argument lists or to sanitize inputs. - Local dependency risk: The scripts call a local skill at ~/.workbuddy/skills/westock-data/scripts/index.js. Ensure that the referenced westock-data code is genuine and not replaced by an attacker — otherwise the skill could run arbitrary Node code when invoked. - Network and privacy: macro_analyzer scrapes Bing search results directly (requests to bing.com) and sends company/industry queries. That is expected for macro analysis, but be aware that queried company names and search keywords will be sent to external services. If you have confidentiality concerns, disable network or review/meter outbound traffic. - Fragile scraping & high thresholds: macro_analyzer uses regex HTML scraping which is brittle; also some thresholds (e.g., requiring >=5 severe keywords) may produce false negatives/positives. This is an operational/data-quality concern, not necessarily malicious. Recommendations before use: 1. Review and/or modify scripts to remove shell=True and pass command arguments as lists to subprocess.run (or validate/escape inputs). 2. Verify the integrity and provenance of the westock-data skill at the hardcoded path. 3. Run the code in an isolated environment (container/VM) with limited permissions and controlled network access; monitor outbound connections. 4. If you plan to accept inputs from untrusted users, add input validation and stricter sanitization. 5. If you need to trust external web results less, consider configuring or restricting the search endpoints and logging the queries for audit. Because the issues are implementation vulnerabilities rather than clear malicious intent, I classify this as 'suspicious' (medium confidence). Reviewing the scripts and running them in a sandboxed environment will reduce risk; if you want, I can point out the exact lines to change to remove shell usage and hardcoded-path assumptions.