Skip to content
skillsafebeta
← Report library
Purpose / Other

Subagent Driven Development Skill Security Audit

What the author says it does (original text)

Use when executing implementation plans with independent tasks in the current session

Independent security check

Do not install or run it yet

Files checked
7
Risks found
6
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.No risks found
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.No risks found
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.Risks found: 3
Medium risk

Plans with the same filename share and overwrite one workspace

Source references: 5
What we found

The workspace name uses only the plan's basename, without its directory or a content identity. Plans such as two different `release.md` files both resolve to `.superpowers/sdd/release/`, contrary to the claim that another plan is never read or written. Task briefs are also overwritten under fixed names.

Why this matters

One plan can read another plan's progress, reports, or diffs, overwrite its task brief, or skip work after misreading a `Task N: complete` entry. This can expose project context and cause incorrect implementation decisions.

The workspace key is derived only from the plan's basename; its directory and contents are not included. Distinct Markdown plans with the same name therefore resolve to the same directory, and later task extraction writes a fixed task filename there. This contradicts the claimed plan isolation and could mix ledgers, reports, or review artifacts, affecting decisions about completed work and code state. Users can ask for a normalized full-path or content hash in the workspace identity.

scripts/sdd-workspace:31In the instructionsOpen original file
slug=$(basename "$plan" .md)[ -n "$slug" ] && [ "$slug" != "." ] && [ "$slug" != ".." ] \  || { echo "cannot derive a workspace name from: $plan" >&2; exit 2; }root=$(git rev-parse --show-toplevel)base="$root/.superpowers/sdd"dir="$base/$slug"mkdir -p "$dir"printf '*\n' > "$base/.gitignore"cd "$dir" && pwd
Show 4 other places
scripts/task-brief:24In the instructionsOpen original file
else  dir=$("$(cd "$(dirname "$0")" && pwd)/sdd-workspace" "$plan")  out="$dir/task-${n}-brief.md"fi
scripts/task-brief:28In the instructionsOpen original file
awk -v n="$n" '  /^```/ { infence = !infence }  !infence && /^#+[ \t]+Task[ \t]+[0-9]+/ {    intask = ($0 ~ ("^#+[ \t]+Task[ \t]+" n "([^0-9]|$)"))  }  intask { print }' "$plan" > "$out"
SKILL.md:136In the instructionsOpen original file
- Each plan owns a workspace: at skill start, run this skill's  `scripts/sdd-workspace PLAN_FILE` — it prints the plan's git-ignored  directory (`<repo-root>/.superpowers/sdd/<plan-basename>/`), home to  every artifact for THIS plan: ledger, briefs, reports, review packages.  Another plan's directory is never yours to read or write.- Check for this plan's ledger at `<workspace>/progress.md`. If its first
scripts/task-brief:21In the instructionsOpen original file
if [ $# -eq 3 ]; then  out=$3else  dir=$("$(cd "$(dirname "$0")" && pwd)/sdd-workspace" "$plan")  out="$dir/task-${n}-brief.md"fi
Medium risk

Optional output paths can overwrite any writable file

Source references: 4
What we found

Both `task-brief` and `review-package` accept a caller-supplied `OUTFILE` without requiring it to remain inside the dedicated workspace. Each script then uses `>` to replace that path.

Why this matters

A mistake, malicious plan instruction, or manipulated agent argument could truncate and replace any file writable by the process, including configuration, source, or agent-instruction files.

Both scripts accept a caller-supplied output path without constraining it to the workspace and overwrite the target with shell `>`. This occurs only when the optional output argument is explicitly supplied; the defaults are inside the dedicated workspace. If an agent, plan, or caller can influence that argument, any file writable under current permissions could be truncated and replaced by a task brief or diff package. Users can require validated workspace-only destinations and rejection of symlinks or escaping paths.

scripts/task-brief:21In the instructionsOpen original file
if [ $# -eq 3 ]; then  out=$3else  dir=$("$(cd "$(dirname "$0")" && pwd)/sdd-workspace" "$plan")  out="$dir/task-${n}-brief.md"fi
Show 3 other places
scripts/task-brief:28In the instructionsOpen original file
awk -v n="$n" '  /^```/ { infence = !infence }  !infence && /^#+[ \t]+Task[ \t]+[0-9]+/ {    intask = ($0 ~ ("^#+[ \t]+Task[ \t]+" n "([^0-9]|$)"))  }  intask { print }' "$plan" > "$out"
scripts/review-package:25In the instructionsOpen original file
if [ $# -eq 4 ]; then  out=$4else  dir=$("$(cd "$(dirname "$0")" && pwd)/sdd-workspace" "$plan")  out="$dir/review-$(git rev-parse --short "$base")..$(git rev-parse --short "$head").diff"fi
scripts/review-package:41In the instructionsOpen original file
  echo  echo "## Diff"  git diff -U10 "${base}..${head}"} > "$out"
Medium risk

Completion permanently deletes detailed review and progress evidence

Source references: 4
What we found

The workspace holds the ledger, task briefs, implementer reports, and review packages, but the finish procedure removes the entire directory with `rm -rf`. Only ledger lines containing `Ruling:` must be copied into the final message; other test output, reports, diff packages, and progress records are not retained in Git history.

Why this matters

The user loses local evidence needed to reassess test claims, reviews, and task decisions. If a defect or audit need appears later, only commits and the final summary remain, and the deleted material is normally not recoverable from Git.

The workspace explicitly holds the ledger, task briefs, implementer reports, and review packages. After final review and fixes, the workflow requires deleting the entire plan workspace with `rm -rf`. Git preserves code commits, but these ignored audit artifacts do not thereby enter history. Only ledger lines containing `Ruling:` must be copied into the final message, so other test output, reports, and progress records may be permanently lost. Users can require archival of necessary audit evidence before deletion or agree on retention and location.

SKILL.md:136In the instructionsOpen original file
- Each plan owns a workspace: at skill start, run this skill's  `scripts/sdd-workspace PLAN_FILE` — it prints the plan's git-ignored  directory (`<repo-root>/.superpowers/sdd/<plan-basename>/`), home to  every artifact for THIS plan: ledger, briefs, reports, review packages.  Another plan's directory is never yours to read or write.- Check for this plan's ledger at `<workspace>/progress.md`. If its first
Show 3 other places
SKILL.md:473In the instructionsOpen original file
Before you delete anything, collect every ledger line containing `Ruling:` —preflight rulings, parked findings, breaker adjudications, all of them — intoyour final message under "Rulings I made", in the order you made them, eachwith what it costs if wrong. The list is exhaustive: if the ledger holds aruling, the list holds it. That list is the only place the decisions youtook on your human partner's behalf reach them — they read it and reworkwhatever you got wrong. A ruling that dies with the workspace was a decisionmade in secret.
SKILL.md:482In the instructionsOpen original file
When the final whole-branch review is clean and its fixes are merged,delete this plan's workspace (`rm -rf <workspace>`) — the git history isthe record now. Sibling directories belong to other plans; leave themalone.
scripts/sdd-workspace:11In the instructionsOpen original file
## The workspace lives in the working tree (not under .git/) because Claude Code# treats .git/ as a protected path and denies agent writes there — which blocks# an implementer subagent from writing its report file. A self-ignoring# .gitignore at .superpowers/sdd/ keeps every plan's workspace out of# `git status` and out of accidental commits without modifying any tracked file.#
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.Risks found: 2
Medium risk

Real important defects may be parked after the repair limit

Source references: 3
What we found

After five rounds, the controller may park a finding that is real but not used downstream and mark the task complete. The final review also permits only one fix wave, after which the controller adjudicates residual findings instead of necessarily returning the decision to the user.

Why this matters

Known correctness, security, or maintainability defects can remain in commits while later tasks and the final branch continue. The user may not see those rulings until branch completion.

After five rounds, the process explicitly permits parking a defect judged real but not load-bearing, after which the task can still be marked complete. The final review also permits only one fix wave and has the controller adjudicate residuals, surfacing only load-bearing ones during branch finishing. A real important defect may therefore remain before merge, depending on the controller's judgment of severity and dependency. Users can require explicit human acceptance for every remaining real Critical or Important finding.

SKILL.md:411In the instructionsOpen original file
**The breaker.** When round 5's re-review still leaves findings open, stopdispatching. Adjudicate each open finding yourself — you hold the plan andthe cross-task context the reviewer lacks:- **The reviewer is wrong, or the point is contestable:** park it —  `Task <N>: parked — <finding> — Ruling: <why the code stands>`. The final  review sees both sides.- **Real, but nothing downstream builds on it:** park it the same way, with  a ruling that says it's real and deferred.- **Real and load-bearing** — a later task builds on it, or it reveals a  plan defect: rule on the smallest change that unblocks the dependent work,  ledger it as `Task <N>: Ruling: <finding> — <what you decided and why>`,  and carry it into the next task's dispatch. Parking a structural failure  silently lets every dependent task build on it. Stop only when the defect  leaves every path forward a guess.
Show 2 other places
SKILL.md:433In the instructionsOpen original file
When the review comes back clean — or every open finding is parked with aruling at the cap — append the completion line to the ledger in the samemessage as your other bookkeeping:- `Task <N>: complete (commits <base7>..<head7>, review clean)`- `Task <N>: complete (commits <base7>..<head7>, <K> parked)` after a  tripped breakerThen mark the todo complete and move on. Never move to the next task whilethe review has open Critical/Important issues that are neither fixed norparked-with-ruling at the cap.
SKILL.md:458In the instructionsOpen original file
If the final whole-branch review returns findings, dispatch ONE fix subagentwith the complete findings list — not one fixer per finding.Per-finding fixers each rebuild context and re-run suites; a realsession's final-review fix wave cost more than all its tasks combined.Then run exactly one scoped re-review of the fix wave(`scripts/review-package PLAN_FILE FIX_BASE HEAD` over the fix range,[re-review-prompt.md](re-review-prompt.md)).Adjudicate any residual findings as in the task loop's breaker: park withrulings, or rule on the load-bearing ones and ledger what you decided. Onlythe four classes above stop you here. There is no second fix wave —residual load-bearing findings surface to your human partner whenfinishing-a-development-branch presents the options.
Medium risk

Review approval does not independently verify test results

Source references: 4
What we found

The review templates call the implementer's report unverified claims but prohibit rerunning the suite. A reviewer runs only a focused test when code reading creates a specific doubt. Fabricated, stale, or misunderstood test output can therefore escape detection.

Why this matters

Code may receive task-quality approval even when tests failed, were not run, or do not cover the behavior, particularly when the diff looks plausible but runtime behavior differs.

The reviewer must treat the implementer's report as unverified and compare it with the diff, but is also told not to rerun the suite merely to confirm the report; a focused test is allowed only when code reading raises a specific unanswered doubt. This is deliberate cost control, not an absence of code review, but fabricated, stale, environment-dependent, or misread results may pass when the static diff gives no reason for suspicion. Users can require independent reruns or verified test artifacts for high-risk changes.

task-reviewer-prompt.md:64In the instructionsOpen original file
    ## Do Not Trust the Report    Treat the implementer's report as unverified claims about the code. It    may be incomplete, inaccurate, or optimistic. Verify the claims against    the diff. Design rationales in the report are claims too: "left it per    YAGNI," "kept it simple deliberately," or any other justification is the    implementer grading their own work. Judge the code on its merits — a    stated rationale never downgrades a finding's severity.
Show 3 other places
task-reviewer-prompt.md:75In the instructionsOpen original file
    The implementer already ran the tests and reported results with TDD    evidence for exactly this code. Do not re-run the suite to confirm their    report. Run a test only when reading the code raises a specific doubt    that no existing run answers — and then a focused test, never a    package-wide suite, race detector run, or repeated/high-count loop. If    heavy validation seems warranted, recommend it in your report instead of    running it. If you cannot run commands in this environment, name the    test you would run.
re-review-prompt.md:66In the instructionsOpen original file
    The implementer re-ran the tests covering the amended code and appended    the results to the report file. Treat the report as unverified claims:    confirm the fix report names the covering tests and shows their output,    and verify the claims against the diff. Do not re-run the suite to    confirm their report. Run a test only when reading the code raises a    specific doubt that no existing run answers — and then a focused test,    never a package-wide suite.
task-reviewer-prompt.md:73In the instructionsOpen original file
    ## Tests    The implementer already ran the tests and reported results with TDD    evidence for exactly this code. Do not re-run the suite to confirm their    report. Run a test only when reading the code raises a specific doubt    that no existing run answers — and then a focused test, never a    package-wide suite, race detector run, or repeated/high-count loop. If    heavy validation seems warranted, recommend it in your report instead of    running it. If you cannot run commands in this environment, name the    test you would run.
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.Risks found: 1
High risk

Plan content is promoted directly into executable subagent instructions

Source references: 4
What we found

The Skill extracts plan text into a brief, tells the subagent it contains exact values to use verbatim, and instructs it to implement exactly what the task specifies and commit the work. The implementer template does not treat plan content as untrusted data or repeat the controller's four stop conditions.

Why this matters

If a plan is untrusted, compromised, or contains prompt injection disguised as requirements, the implementer could run unintended commands, modify files, or create commits. A later diff review does not guarantee prevention before those side effects occur.

The workflow copies task text from the selected plan into a brief, tells the implementer to treat it as requirements, use exact values verbatim, implement, and commit. Although the template says to ask about unclear points, it does not require treating plan content as untrusted or carry the controller's security stop conditions into the implementer prompt. A malicious, injected, or overbroad plan instruction could therefore be treated as authorized work. Users can ask for explicit trust boundaries, allowed scope, and a pre-implementation safety check.

SKILL.md:251In the instructionsOpen original file
- **Task brief:** before dispatching an implementer, run this skill's  `scripts/task-brief PLAN_FILE N` — it extracts the task's full text to a  uniquely named file and prints the path. Compose the dispatch so the  brief stays the single source of  requirements. Your dispatch should contain: (1) one line on where this  task fits in the project; (2) the brief path, introduced as "read this  first — it is your requirements, with the exact values to use verbatim";  (3) interfaces and decisions from earlier tasks that the brief cannot  know; (4) your resolution of any ambiguity you noticed in the brief;  (5) the report-file path and report contract. Exact values (numbers,  magic strings, signatures, test cases) appear only in the brief. Never  make a subagent read the whole plan file.- **Report file:** name the implementer's report file after the brief
Show 3 other places
implementer-prompt.md:15In the instructionsOpen original file
    Read your task brief first: [BRIEF_FILE]    It contains the full task text from the plan.
implementer-prompt.md:34In the instructionsOpen original file
    Once you're clear on requirements:    1. Implement exactly what the task specifies    2. Write tests (following TDD if task says to)    3. Verify implementation works    4. Commit your work    5. Self-review (see below)    6. Report back    Work from: [directory]    **While you work:** If you encounter something unexpected or unclear, **ask questions**.    It's always OK to pause and clarify. Don't guess or make assumptions.
SKILL.md:27In the instructionsOpen original file
Four things stop you, and only these: an irreversible or destructiveoperation; a security-sensitive action; a side effect outside this worktreethat norms say you ask about first (a merge, a push to a shared branch, apublish); and a plan so broken that every path forward is a guess. For those,stop and ask.
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

8 instruction sections

This Skill splits an implementation plan into tasks, dispatches an implementation subagent and a review subagent for each task, and performs a final branch-wide review. Implementers modify code, run tests, and create Git commits.

View source
SKILL.md:8In the instructionsOpen original file
Execute plan by dispatching a fresh implementer subagent per task, a task review (spec compliance + code quality) after each, and a broad whole-branch review at the end.**Why subagents:** You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.**Core principle:** Fresh subagent per task + task review (spec + quality) + broad final review = high quality, fast iteration
implementer-prompt.md:34In the instructionsOpen original file
    Once you're clear on requirements:    1. Implement exactly what the task specifies    2. Write tests (following TDD if task says to)    3. Verify implementation works    4. Commit your work    5. Self-review (see below)    6. Report back

The scripts create task briefs, review diffs, and progress records under `.superpowers/sdd/<plan-basename>/` in the repository. A review package contains the commit list, statistics, and full diff for a specified Git range.

View source
scripts/sdd-workspace:31In the instructionsOpen original file
slug=$(basename "$plan" .md)[ -n "$slug" ] && [ "$slug" != "." ] && [ "$slug" != ".." ] \  || { echo "cannot derive a workspace name from: $plan" >&2; exit 2; }root=$(git rev-parse --show-toplevel)base="$root/.superpowers/sdd"dir="$base/$slug"mkdir -p "$dir"printf '*\n' > "$base/.gitignore"cd "$dir" && pwd
scripts/review-package:32In the instructionsOpen original file
{  echo "# Review package: ${base}..${head}"  echo  echo "## Commits"  git log --oneline "${base}..${head}"  echo  echo "## Files changed"  git diff --stat "${base}..${head}"  echo  echo "## Diff"  git diff -U10 "${base}..${head}"} > "$out"

Review agents normally do not rerun the full test suite. They inspect the implementer's reported output and the diff, and may run only a focused test when a specific unresolved doubt arises.

View source
task-reviewer-prompt.md:75In the instructionsOpen original file
    The implementer already ran the tests and reported results with TDD    evidence for exactly this code. Do not re-run the suite to confirm their    report. Run a test only when reading the code raises a specific doubt    that no existing run answers — and then a focused test, never a    package-wide suite, race detector run, or repeated/high-count loop. If    heavy validation seems warranted, recommend it in your report instead of    running it. If you cannot run commands in this environment, name the    test you would run.
re-review-prompt.md:66In the instructionsOpen original file
    The implementer re-ran the tests covering the amended code and appended    the results to the report file. Treat the report as unverified claims:    confirm the fix report names the covering tests and shows their output,    and verify the claims against the diff. Do not re-run the suite to    confirm their report. Run a test only when reading the code raises a    specific doubt that no existing run answers — and then a focused test,    never a package-wide suite.

The process permits the controller to rule on plan conflicts and review findings, continue after recording some unresolved issues once five fix rounds are exhausted, and delete the plan workspace at the end.

View source
SKILL.md:411In the instructionsOpen original file
**The breaker.** When round 5's re-review still leaves findings open, stopdispatching. Adjudicate each open finding yourself — you hold the plan andthe cross-task context the reviewer lacks:- **The reviewer is wrong, or the point is contestable:** park it —  `Task <N>: parked — <finding> — Ruling: <why the code stands>`. The final  review sees both sides.- **Real, but nothing downstream builds on it:** park it the same way, with  a ruling that says it's real and deferred.- **Real and load-bearing** — a later task builds on it, or it reveals a  plan defect: rule on the smallest change that unblocks the dependent work,  ledger it as `Task <N>: Ruling: <finding> — <what you decided and why>`,  and carry it into the next task's dispatch. Parking a structural failure  silently lets every dependent task build on it. Stop only when the defect  leaves every path forward a guess.
SKILL.md:482In the instructionsOpen original file
When the final whole-branch review is clean and its fixes are merged,delete this plan's workspace (`rm -rf <workspace>`) — the git history isthe record now. Sibling directories belong to other plans; leave themalone.
Start here · InstructionsSKILL.md
subagent-driven-development
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source. 1 more sections are available in the original file.

File reference map

References: 3
Files making referencesReferenced content
Lines show actual file references, not execution order. Select a node to highlight its connections and inspect the files and source locations. Dashed lines include files that still need locating.
Files and check records7 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included
  • scripts/review-packageFull text included
  • scripts/sdd-workspaceFull text included
  • scripts/task-briefFull text included
  • implementer-prompt.mdFull text included
  • re-review-prompt.mdFull text included
  • task-reviewer-prompt.mdFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions
  • implementer-prompt.mdSupporting file
  • re-review-prompt.mdSupporting file
  • scripts/review-packageSupporting file
  • scripts/sdd-workspaceSupporting file
  • scripts/task-briefSupporting file
  • task-reviewer-prompt.mdSupporting file

Operations mentioned in code and instructions

Run commands
SKILL.md:318In the instructionsOpen original file
  `scripts/review-package PLAN_FILE BASE HEAD` and pass the reviewer the file path  it prints (or, without bash: `git log --oneline`, `git diff --stat`,  and `git diff -U10` for the range, redirected to one uniquely named
scripts/review-package:1In the instructionsOpen original file
#!/usr/bin/env bash# Generate a review package: commit list, stat summary, and the net
scripts/sdd-workspace:1In the instructionsOpen original file
#!/usr/bin/env bash# Resolve and ensure the working-tree directory SDD uses for one plan's
Read files
SKILL.md:384In the instructionsOpen original file
findings, and this framing: "A prior implementer attempted this task[N] times; you own it now. Read the report file for what was tried." A loopthat survives three resumes usually means the implementer cannot see its
SKILL.md:509In the instructionsOpen original file
[Setup: worktree verified][Read plan file once: docs/superpowers/plans/feature-plan.md][Resolve workspace: scripts/sdd-workspace docs/superpowers/plans/feature-plan.md — no ledger inside, fresh start]
implementer-prompt.md:85In the instructionsOpen original file
    - The task involves restructuring existing code in ways the plan didn't anticipate    - You've been reading file after file trying to understand the system without progress
Change files
SKILL.md:483In the instructionsOpen original file
When the final whole-branch review is clean and its fixes are merged,delete this plan's workspace (`rm -rf <workspace>`) — the git history isthe record now. Sibling directories belong to other plans; leave them
Lines read
1,178
File checksum (to compare versions)
bf1d87234bb7ed340307d54567bf15189a4f27cbfe8ae83ea304d22b93424cf4