openInvest

Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.

Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.

Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.

Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

The skill explicitly instructs the agent to execute shell commands (run.sh, curl) but does not declare any tool scope such as permissions or allowed-tools. That makes invocation boundaries implicit, increasing the chance an agent or host grants broader shell access than intended and enabling unintended command execution paths.

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Including .env in backup archives causes API keys, SMTP credentials, and other secrets to be copied into a zip file under $ROOT/.backups. That materially expands the attack surface: anyone who can read the backup directory, move the archive off-host, or ingest it into logs/artifacts gains access to credentials that may enable broader compromise.

The skill explicitly includes .env in backups, which commonly contains SMTP/API credentials and other secrets. Even though the purpose is legitimate disaster recovery, packaging credentials into portable zip archives increases the risk of credential exposure through weak storage permissions, accidental sharing, or restore artifacts being copied to less trusted systems.

The README explicitly instructs users to edit the skill protocol and scripts, and notes that symlinked contents become live immediately with no reinstall. In an agent-skill context, encouraging direct self-modification of prompts and execution scripts raises the risk of persistence, unsafe customization, or accidental weakening of security boundaries, especially because changes affect future invocations immediately.

Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

This is a real session/credential persistence concern because the skill directs durable storage of API endpoint and authentication material in $INVEST_HOME/.env. Persistent plaintext secrets increase the chance of later compromise from local attackers, misconfigured permissions, backups, or accidental exfiltration by other tools.

Referencing uvx openinvest without a pinned package version creates a supply-chain and integrity risk: future upstream releases could change behavior, introduce breaking changes, or ship malicious code. Because this skill is intended for daily use and can affect portfolio state, unpinned execution materially raises risk.

The README instructs users to invoke uvx openinvest without pinning a specific package version or artifact digest, which creates a supply-chain risk. A compromised or malicious future release on PyPI could be pulled automatically and executed in the user's environment, and this skill is explicitly intended for frequent/daily use, increasing exposure.

This is the same unpinned uvx openinvest execution path repeated later in the README, again exposing users to unintended execution of whatever version is current on PyPI. Because the backend is fetched on demand, the trust boundary extends to the package registry and maintainer account security.

The manifest and top-level guidance repeatedly constrain the skill to one-time onboarding and say it should step aside after setup. The FAQ nevertheless instructs the agent to run run.sh update, which is a software maintenance/upgrade capability outside the stated onboarding-only scope. Even if presented as troubleshooting advice, it expands the skill's practical role beyond initial setup.

The manifest description narrows the skill to first-time onboarding via the canonical 5-question init flow. However, the body of the skill defines a second operational mode, 'Path B', that skips init entirely and instead configures remote connectivity by persisting INVEST_API_BASE and optional authentication tokens into $INVEST_HOME/.env. That is a materially different behavior than 'wraps run.sh init --from-stdin'.

The documentation exposes wealth-context and account-profile management capabilities that go beyond simple investment analysis and verdict generation. Expanding the agent's authority into sensitive profile fields increases the chance of unauthorized modification, privacy overreach, and harmful decision-making based on altered user context.

The statement that the agent has access to ALL backend functionality materially broadens authority beyond the manifest's described workflows. In a tool-using agent, this creates a confused-deputy risk where the model may invoke powerful write or admin-like operations that the user did not intend when activating an analysis-oriented investment skill.

The skill collects remote authentication material and persists it locally in .env, which expands its access from simple onboarding to credential handling for a remote service. That broader capability increases the blast radius if the workstation, skill runtime, or config files are exposed, especially because the manifest does not clearly foreground this secret-management behavior.

Claiming the command set is closed while later referencing additional native commands creates inconsistent tool boundaries. Ambiguity in what tools exist can cause agents to hallucinate, fall back to undocumented endpoints, or bypass intended safety constraints because the authoritative interface is unclear.

The trigger phrases are very broad and include normal conversational language such as 'analyze X' or 'show portfolio', which can cause accidental invocation in unrelated contexts. In a skill that can read financial data, write ledger entries, and run shell-backed workflows, overbroad activation increases the chance of unintended sensitive actions.

The protocol explicitly treats broad natural-language phrases like 'should I buy/sell X' and 'analyze X' as triggers for a multi-step investment workflow that can invoke shell commands and spawn delegated subtasks. In a daily-use financial skill, overly broad trigger phrases increase the chance of accidental activation from ordinary conversation, causing unintended analysis runs, persistence of decision artifacts, and potentially nudging users toward financial actions they did not intend to initiate.

This README is a markdown file, so vague trigger guidance applies. The listed activation examples include generic phrases like "show portfolio" and "analyze X," which are common requests and the README does not provide negative examples or constraints explaining when these phrases should or should not invoke this specific skill.