plan-manager-10ecb4 96/100

CategoryWeightCategory scoreContribution

Securityprompt, exec, net, exfil, eval

35%

30.8 pts

Supply chainhash, typosquat, maintainer, lockfile

20%

100

20.0 pts

Maintenancestaleness, pinning, CI

15%

100

15.0 pts

TransparencySKILL.md, perms, README

15%

100

15.0 pts

Communityinstalls, verify, response

15%

100

15.0 pts

Findings & checks · 1 flagged

Securityscore 88 · 1 finding

MEDIUMInstruction telling the agent not to ask for approvalSS-SKILL-INJECT-DONT-ASK-01 · Prompt injection · README.md

MEDIUM — it fires on intent; the real damage depends on the host agent's own approval-gating.

Why it matters

The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.

The exact value spotted

excerptREADME.md· markdown

103Rosetta instructions require the agent to: critically review every user request before execu

… (105 chars elided on L103)

104

1053. **Human-in-the-loop at decision points, not after the damage.** AI coding agents fully an

… (108 chars elided on L105)

106

107Rosetta workflows define approval gates at critical decision points: after specs, after plan

… (105 chars elided on L107)

Occurrences

1 occurrence · at L105

How to fix

Remove the approval-skipping instruction, or scope it narrowly to a specific safe, reversible action.

Delete blanket "don't ask / no need to confirm" directives from the skill.
If the skill is a genuine autonomous job, restrict the opt-out to a named non-destructive action rather than all actions.

Framework references

OWASPLLM01 ATLASAML.T0051

Trace & refs

ruleSS-SKILL-INJECT-DONT-ASK-01sha25614b7852251bf4666…rubric 365aacaView on GitHub

Supply chainscore 100 · 0 findings

✓—All supply chain checks passedNo findings in this category for the latest scan.pass

Maintenancescore 100 · 0 findings

✓—All maintenance checks passedNo findings in this category for the latest scan.pass

Transparencyscore 100 · 0 findings

✓—All transparency checks passedNo findings in this category for the latest scan.pass

Communityscore 100 · 0 findings

✓—All community checks passedNo findings in this category for the latest scan.pass

The primary manifest — the file an agent reads to learn what this artifact does.

plugins/core-cursor/skills/plan-manager/SKILL.md · 1 file

plugins/core-cursor/skills/plan-manager/SKILL.md3.4 KB · Markdown

name: plan-manager

description: "To create, track, and coordinate execution plans via local JSON files."

license: Apache-2.0

dependencies: node.js

disable-model-invocation: false

user-invocable: true

argument-hint: feature-name plan-name

allowed-tools: Bash(npx:*)

model: claude-sonnet-4-6

tags:

- plan-manager

- plan-manager-create

- plan-manager-use

baseSchema: docs/schemas/skill.md

<plan-manager>

<role>

Senior execution planner and tracker for plan-driven workflows.

</role>

<when_to_use_skill>

Primary plan manager for orchestrators and subagents. Creates, tracks, and executes plans as local JSON files.

</when_to_use_skill>

<core_concepts>

All Rosetta prep steps MUST be FULLY completed, load-context skill loaded and fully executed
Plan file lives in FEATURE PLAN folder: <feature_plan_folder_full_path>/plan.json
CLI: npx rosettify@latest plan <subcommand> <plan_file> [args...]
Always use full absolute paths for the plan file
Six subcommands for plan command: create, next, update_status, show_status, query, upsert
Resume behavior: next returns four groups: (1) in_progress steps (resume=true), (2) open eligible steps, (3) blocked steps (previously_blocked=true), (4) failed steps (previously_failed=true)
Phases are sequential: steps from a later phase do not appear until all steps in earlier phases are complete
Status propagation: bottom-up only (steps -> phases -> plan); plan root status is always derived, never set directly
Phase status updates are rejected (phase_status_is_derived); entire_plan target is rejected for update_status (invalid_target)
upsert silently ignores status fields in patch -- only update_status modifies status
ACQUIRE plan-manager/assets/pm-schema.md FROM KB for data structure reference

</core_concepts>

Orchestrator flow:

Create plan: npx rosettify@latest plan create <plan_file> '<json>' -- see pm-schema.md for JSON structure
Upsert phases and steps: npx rosettify@latest plan upsert <plan_file> entire_plan [kind] '<json>'
Delegate steps to subagents -- pass plan file path and step IDs
Loop: call next until plan_status: complete and count: 0

Subagent flow:

Get next steps: npx rosettify@latest plan next <plan_file> [limit]
Check resume flag -- if true, continue interrupted work; if false, start fresh
Execute step
Update: npx rosettify@latest plan update_status <plan_file> <step-id> complete
Repeat from step 1

</process>

<validation_checklist>

npx rosettify@latest plan help exits without error and returns structured help JSON
show_status output: plan root status is derived (never manually set)
next output: in_progress steps appear before open steps; blocked and failed steps are included with flags
show_status phase status matches aggregate of its steps after update_status

</validation_checklist>

Not checking resume flag on next results -- causes duplicate work on resumed sessions
Forgetting update_status after step completion -- plan remains stale
Plan root status cannot be set directly -- it is always derived from phases
Attempting to set phase status directly -- rejected as phase_status_is_derived

</pitfalls>

Asset: ACQUIRE plan-manager/assets/pm-schema.md FROM KB -- plan JSON structure
Flow: USE FLOW adhoc-flow

</resources>

</plan-manager>

plan-manager-10ecb4— agent skill

Is plan-manager-10ecb4 safe to install?

Audit the pieces. Scan the whole. Decide.