Skip to content
skillsafebeta
← Report library
Purpose / Development

Spec Driven Development Skill Security Audit

What the author says it does (original text)

Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea. Use when a single requirement spans several independently testable capabilities and needs decomposing into a capability map of modules before specifying.

Independent security check

Security risks found

Files checked
1
Risks found
3
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: 2
Medium risk

A trigger described as creating specifications can proceed into repository code changes

Source references: 6
What we found

The metadata describes creating specs before coding, but the workflow includes a full Implement phase and directs the agent to execute tasks. A user invoking it only to obtain a specification may not expect source changes. Although phases are reviewed, the text does not require a separate, explicit authorization immediately before code modification begins.

Why this matters

Approval of a specification, plan, or task list could be interpreted as permission to modify multiple source files, run verification steps, and complete the implementation.

What this evidence establishes

The Skill does include an Implement phase that can modify source code, while its metadata emphasizes creating specifications before coding. However, the workflow requires human review and validation at each gate; it is unclear whether approval of the task list also authorizes implementation. There is a plausible scope mismatch when a user wants only a spec, but automatic code changes are not established. The user can require it to stop after the spec/tasks and obtain separate approval before implementation.

This assessment concerns the code and conditions shown, not proof that harm has occurred.
SKILL.md:2In the instructionsOpen original file
---name: spec-driven-developmentdescription: Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea. Use when a single requirement spans several independently testable capabilities and needs decomposing into a capability map of modules before specifying.---
Show 5 other places
SKILL.md:24In the instructionsOpen original file
Spec-driven development has four phases, preceded by a scope check (Phase 0) that activates only when one request bundles several independently testable capabilities. Do not advance to the next phase until the current one is validated.
SKILL.md:200In the instructionsOpen original file
### Phase 4: ImplementExecute tasks one at a time following `skills/incremental-implementation/SKILL.md` (`incremental-implementation`) and `skills/test-driven-development/SKILL.md` (`test-driven-development`). Use `skills/context-engineering/SKILL.md` (`context-engineering`) to load the right spec sections and source files at each step rather than flooding the agent with the entire spec.
SKILL.md:3In the instructionsOpen original file
name: spec-driven-developmentdescription: Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea. Use when a single requirement spans several independently testable capabilities and needs decomposing into a capability map of modules before specifying.---
SKILL.md:22In the instructionsOpen original file
## The Gated WorkflowSpec-driven development has four phases, preceded by a scope check (Phase 0) that activates only when one request bundles several independently testable capabilities. Do not advance to the next phase until the current one is validated.
SKILL.md:27In the instructionsOpen original file
```SPECIFY ──→ PLAN ──→ TASKS ──→ IMPLEMENT   │          │        │          │   ▼          ▼        ▼          ▼ Human      Human    Human      Human reviews    reviews  reviews    reviews```
Medium risk

It directs the agent to commit the specification, potentially writing Git history without separate confirmation

Source references: 4
What we found

“Commit the spec” is a direct operational instruction, not merely a formatting example. Earlier text requires review of the specification, but it does not explicitly require fresh consent before running Git commit. A commit creates lasting repository history and may invoke local commit hooks.

Why this matters

The agent could create a commit the user did not intend; commit hooks could also run formatting, tests, or other local commands.

“Commit the spec” is an active instruction in the spec-maintenance list, not an example or warning, so it could lead an agent to create a Git commit. Although the spec must first receive human approval, this file does not classify committing as an operation requiring separate confirmation; approving content is not necessarily authorization to alter repository history. It does not instruct pushing remotely. The user can prohibit automatic commits, allow only working-tree files, and require confirmation before every commit.

SKILL.md:206In the instructionsOpen original file
The spec is a living document, not a one-time artifact:- **Update when decisions change** — If you discover the data model needs to change, update the spec first, then implement.- **Update when scope changes** — Features added or cut should be reflected in the spec.- **Commit the spec** — The spec belongs in version control alongside the code.- **Reference the spec in PRs** — Link back to the spec section that each PR implements.
Show 3 other places
SKILL.md:110In the instructionsOpen original file
6. **Boundaries** — Three-tier system:   - **Always do:** Run tests before commits, follow naming conventions, validate inputs   - **Ask first:** Database schema changes, adding dependencies, changing CI config   - **Never do:** Commit secrets, edit vendor directories, remove failing tests without approval
SKILL.md:204In the instructionsOpen original file
## Keeping the Spec AliveThe spec is a living document, not a one-time artifact:- **Update when decisions change** — If you discover the data model needs to change, update the spec first, then implement.- **Update when scope changes** — Features added or cut should be reflected in the spec.- **Commit the spec** — The spec belongs in version control alongside the code.- **Reference the spec in PRs** — Link back to the spec section that each PR implements.
SKILL.md:237In the instructionsOpen original file
Before proceeding to implementation, confirm:- [ ] The spec covers all six core areas- [ ] The human has reviewed and approved the spec- [ ] Success criteria are specific and testable- [ ] Boundaries (Always/Ask First/Never) are defined- [ ] The spec is saved to a file in the repository- [ ] If the request bundles several independently testable capabilities, a capability map (module ids, dependency direction, build order) was approved before any module spec was written
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.No risks found
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
Medium risk

Critical planning and implementation behavior is delegated to Skills absent from the supplied source

Source references: 4
What we found

This file gives `planning-and-task-breakdown` precedence on conflicts and requires three additional Skills during implementation. Their contents are not included in the supplied source, so a user cannot determine from this package which commands, file access, or additional actions they require.

Why this matters

If same-named dependencies in the installed environment contain broader or unsafe instructions, they can change task scope, commands, and file operations through this Skill's explicit delegation.

Critical behavior is delegated to other Skills: the planning dependency overrides this file on conflicts, and implementation must follow three additional Skills. Their instructions are not shown in the supplied source, so their commands, file operations, and authorization boundaries cannot be assessed here. The risk arises if those dependencies are loaded. A user can require disclosed, pinned versions, separate audits, and restrictions on file writes, command execution, and network access.

SKILL.md:174In the instructionsOpen original file
> Follow `planning-and-task-breakdown` for the dependency-graph mapping and vertical-slicing mechanics behind these steps; it is the canonical source. The bullets above are a lightweight summary; if they ever diverge, `planning-and-task-breakdown` takes precedence.>> **Output convention:** Save the plan to `tasks/plan.md` and record the task list in the task list target defined by `planning-and-task-breakdown` (default `tasks/todo.md`; projects may designate an external tracker instead). Create `tasks/` if it does not exist. Downstream commands (`/build`, etc.) expect these defaults.
Show 3 other places
SKILL.md:190In the instructionsOpen original file
> Follow `planning-and-task-breakdown` for the full task-sizing and dependency-ordering mechanics; it is the canonical source. The template below is a lightweight inline form; if they ever diverge, `planning-and-task-breakdown` takes precedence.
SKILL.md:202In the instructionsOpen original file
Execute tasks one at a time following `skills/incremental-implementation/SKILL.md` (`incremental-implementation`) and `skills/test-driven-development/SKILL.md` (`test-driven-development`). Use `skills/context-engineering/SKILL.md` (`context-engineering`) to load the right spec sections and source files at each step rather than flooding the agent with the entire spec.
SKILL.md:200In the instructionsOpen original file
### Phase 4: ImplementExecute tasks one at a time following `skills/incremental-implementation/SKILL.md` (`incremental-implementation`) and `skills/test-driven-development/SKILL.md` (`test-driven-development`). Use `skills/context-engineering/SKILL.md` (`context-engineering`) to load the right spec sections and source files at each step rather than flooding the agent with the entire spec.
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

7 instruction sections

The Skill uses a human-gated workflow: the specification, plan, and tasks are intended to be reviewed before implementation begins.

View source
SKILL.md:24In the instructionsOpen original file
Spec-driven development has four phases, preceded by a scope check (Phase 0) that activates only when one request bundles several independently testable capabilities. Do not advance to the next phase until the current one is validated.
SKILL.md:30In the instructionsOpen original file
   ▼          ▼        ▼          ▼ Human      Human    Human      Human reviews    reviews  reviews    reviews```

For a request containing several independent capabilities, it first creates a capability map and then creates per-module specification files in dependency order.

View source
SKILL.md:63In the instructionsOpen original file
**The map is gated like every phase.** The human reviews module boundaries, dependency direction, and build order before any module spec is written. Getting the map wrong is expensive; reviewing ten lines is not.**Then recurse per module.** Run Specify → Plan → Tasks → Implement for each module in dependency order. Each module gets its own spec, scoped to that module's objective, boundaries, and success criteria. Save the approved map at the project root and each module's spec alongside it, named by module id (`SPEC-identity.md`, `SPEC-billing.md`) — the map, not filename guessing, is the index of what exists.

It directs the agent to write planning artifacts into the repository and then execute tasks individually during the implementation phase.

View source
SKILL.md:176In the instructionsOpen original file
>> **Output convention:** Save the plan to `tasks/plan.md` and record the task list in the task list target defined by `planning-and-task-breakdown` (default `tasks/todo.md`; projects may designate an external tracker instead). Create `tasks/` if it does not exist. Downstream commands (`/build`, etc.) expect these defaults.
SKILL.md:200In the instructionsOpen original file
### Phase 4: ImplementExecute tasks one at a time following `skills/incremental-implementation/SKILL.md` (`incremental-implementation`) and `skills/test-driven-development/SKILL.md` (`test-driven-development`). Use `skills/context-engineering/SKILL.md` (`context-engineering`) to load the right spec sections and source files at each step rather than flooding the agent with the entire spec.
Start here · InstructionsSKILL.md
spec-driven-development
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source.
Files and check records1 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

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
Lines read
246
File checksum (to compare versions)
b14bd801bde0391a0bf889ad0067e7fd494852882d495dd721acf6e91727b7b3