masterplan-executor

• Outcome: Review
• Latest audit: Jul 25, 2026 · 4:58 AM UTC
• Version: 1.0.0

Overview

The skill is coherent, but it needs review because it can make broad project changes and use web research automatically without asking first.

Install only if you are comfortable with an agent reading the project masterplan and codebase, making code changes, updating an execution log, committing phase work, and using external web research automatically. For private or regulated projects, ask the agent to use a local-only mode, confirm before web access or commits, and avoid logging secrets, customer data, internal URLs, or proprietary implementation details.

SkillSpector

By NVIDIA

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (5)

Vague Triggers

Medium

• Confidence: 87% confidence
• Finding: The invocation examples are broad enough to overlap with ordinary development requests such as 'build this' or 'continue where we left off', which can cause the skill to activate in situations where the user did not explicitly intend its full workflow. In this skill's context, unintended activation is more dangerous because the skill is designed to read project plans, modify code, keep persistent logs, and perform automatic web research, increasing the chance of unwanted code changes or data exposure.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The README advertises automatic web searching to resolve ambiguity but does not warn users that external network access may occur or that project-derived details could be exposed to third-party services. In this skill's context, that omission is meaningful because the skill is intended to inspect source code and planning documents, so automatic research could transmit sensitive implementation details, internal paths, or proprietary context outside the local environment.

Missing User Warnings

Low

• Confidence: 89% confidence
• Finding: The skill states that it maintains a persistent execution log but does not warn users that project information, implementation state, or possibly sensitive operational notes may be written to disk. In this context the risk is lower than network exposure, but it still matters because resumable logs can retain sensitive details longer than the user expects and may be committed, shared, or accessed by others.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The skill explicitly instructs automatic web_search/web_fetch during implementation without requiring notice, consent, or minimization of what project details may be sent to external services. In a coding/execution skill, this can expose proprietary code, internal architecture, secrets-adjacent context, or sensitive business logic through outbound queries, making the context materially more dangerous than ordinary documentation lookups.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

Follow `references/phase-execution-checklist.md` for the mechanical steps. For each phase, in strict roadmap order:

1. **Re-read the plan sections that scope this phase** — the relevant features with their acceptance criteria, tech-stack entries, data-model pieces, API contract, adaptive-system requirements, and the specific production-readiness items that apply to this phase's surface area.
2. **Resolve ambiguity via research, automatically, never via guessing.** If anything needed to implement this phase correctly is unclear, underspecified, contradicts something else in the plan, or the plan's stated approach seems outdated or wrong now that you're actually implementing it — `web_search` (and `web_fetch` official docs/changelogs/release notes) to find the current, valid, correct way to do it before writing the code. This covers: exact current API/syntax of a chosen library or framework, current security best practice for a specific mechanism, resolving an internal contradiction in the plan, or confirming a version/approach is still the right one. Do this without asking the user's permission first — it's the default behavior, not an escalation. Only surface it to the user afterward if the research changes something user-facing or a major architecture decision (see Phase 3).
3. **Implement to the standard in `references/execution-standards.md`** — real error handling, real config/secrets management, real input validation, real structured logging, environment-adaptive behavior wherever the plan calls for it, no dead code, no silent failures. Not a version "to be hardened later" — the version that ships. If this step is done surgically via subagents/parallel workers, gate concurrency per `references/resource-safety.md` — recompute the safe concurrency budget from freshly detected available RAM before spawning each batch, never from a fixed number or a prior session's reading. When in doubt or detection is unavailable, execute sequentially instead of risking an OOM.

...[truncated 25 chars]

• Confidence: 88% confidence
• Finding: without asking

VirusTotal

VirusTotal findings are pending for this skill version.

Static analysis

No suspicious patterns detected.