跳转到正文
报告库
用途分类 / 开发辅助

Spec Driven Development Skill 安全审计

作者说它能做什么(原文)

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.

第三方安全检查结论

发现安全风险

已检查文件
1
发现的风险
3
会不会运行危险命令?检查是否下载程序后直接运行、让他人远程控制电脑,或藏起要运行的命令。未发现风险
会不会泄露文件和密钥?检查是否发送含密码或密钥的文件,以及代码里是否直接写了密钥。未发现风险
会不会删除文件或一直在后台运行?检查是否大范围删除文件、改写磁盘,或设置自动启动。发现 2 项风险
中风险

“创建规格”的触发说明最终可进入代码实现并修改仓库

原文依据:6 处
发现了什么

元数据将该 Skill 描述为“编码前创建规格”,但工作流包含完整的 Implement 阶段,并要求逐项执行任务。用户仅因需要规格而调用它时,可能未预期其继续改动源代码。虽然阶段需要人工审阅,但文本没有要求在开始实现前取得一项单独、明确的代码修改授权。

为什么需要注意

批准规格、计划或任务后,代理可能把该批准理解为允许修改多个源文件、运行验证步骤以及完成整个实现。

这段证据能说明什么

该 Skill 的确包含会修改源代码的 Implement 阶段,而元数据主要强调“编码前创建规格”。不过工作流明确要求各阶段经人工审阅、当前阶段验证后才能继续;任务清单获批是否也构成实施授权,文本没有说清。因此存在范围超出用户只要规格的可能,但不能断定会自动改代码。用户可要求交付规格和任务后停止,实施前另行确认。

这项判断针对展示的代码和适用条件,不表示风险已经实际发生。
SKILL.md:2来自说明文档打开原文件
---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.---
查看另外 5 个位置
SKILL.md:24来自说明文档打开原文件
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:200来自说明文档打开原文件
### 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:3来自说明文档打开原文件
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:22来自说明文档打开原文件
## 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:27来自说明文档打开原文件
```SPECIFY ──→ PLAN ──→ TASKS ──→ IMPLEMENT   │          │        │          │   ▼          ▼        ▼          ▼ Human      Human    Human      Human reviews    reviews  reviews    reviews```
中风险

它指示提交规格,可能在未单独确认的情况下写入 Git 历史

原文依据:4 处
发现了什么

“Commit the spec”是一条直接操作指令,不只是格式示例。前文要求用户审阅规格,但没有明确规定执行 Git commit 前必须再次征得同意。提交会形成持久的仓库历史,并可能触发本地提交钩子。

为什么需要注意

代理可能创建用户并未打算产生的提交;提交钩子还可能运行格式化、测试或其他本地命令。

“Commit the spec”位于维护规范的主动指令列表中,不是示例或警告,因此可能促使代理创建 Git 提交。虽然规范必须先经人工批准,但该文件没有把“执行提交”列入需另行询问的操作;批准内容不一定等同于授权写入仓库历史。文本也未要求推送远端。用户可明确禁止自动提交,要求仅保存工作区文件,并在每次 commit 前单独确认。

SKILL.md:206来自说明文档打开原文件
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.
查看另外 3 个位置
SKILL.md:110来自说明文档打开原文件
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:204来自说明文档打开原文件
## 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:237来自说明文档打开原文件
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
会不会绕过安全保护?检查是否跳过网站安全验证、开放过多文件权限,或取消操作前的确认。未发现风险
会不会误导 AI 或隐藏内容?检查工作说明是否要求 AI 忽略你的指令、干扰检查结果,或夹带看不见的文字。发现 1 项风险
中风险

关键规划和实现行为被交给未随来源提供的其他 Skill

原文依据:4 处
发现了什么

该文件声明 `planning-and-task-breakdown` 在冲突时拥有优先权,并要求实现阶段遵循另外三个 Skill。本次来源没有包含这些依赖的内容,因此用户无法从这份 Skill 判断它们会要求哪些命令、文件访问或额外操作。

为什么需要注意

安装环境中同名依赖若包含更宽泛或不安全的指令,可能改变任务范围、命令和文件操作;这些行为会通过本 Skill 的明确委托进入工作流。

关键行为确实由外部 Skill 决定:规划规则在冲突时优先,实施还必须遵循三个其他 Skill。所给源码没有展示这些依赖的具体指令,因此无法判断其命令、文件操作或授权边界。只有实际加载这些依赖时风险才会出现。用户可要求作者提供并固定依赖版本,先分别审计,并限制其写文件、运行命令及网络访问。

SKILL.md:174来自说明文档打开原文件
> 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.
查看另外 3 个位置
SKILL.md:190来自说明文档打开原文件
> 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:202来自说明文档打开原文件
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:200来自说明文档打开原文件
### 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 逻辑拆解

7 个说明模块

该 Skill 采用人工审批的分阶段流程:规格、计划和任务都应先由用户审阅,之后才进入实现。

查看原文
SKILL.md:24来自说明文档打开原文件
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:30来自说明文档打开原文件
   ▼          ▼        ▼          ▼ Human      Human    Human      Human reviews    reviews  reviews    reviews```

对于包含多个独立能力的需求,它会先创建能力地图,再按依赖顺序为各模块创建规格文件。

查看原文
SKILL.md:63来自说明文档打开原文件
**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.

它要求将计划和任务清单写入仓库,并在实现阶段逐项执行任务。

查看原文
SKILL.md:176来自说明文档打开原文件
>> **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:200来自说明文档打开原文件
### 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
spec-driven-development
连线表示工作说明包含的模块,不是实际运行顺序。点击模块可查看原文。
文件与检查记录1 个文件

检查范围与遗漏

逐文件查看涉及的内容

下方列出本次涉及的原文范围;纳入检查不代表已查清所有问题。

  • SKILL.md已纳入全文

这份报告只针对上方版本。我们看了拿到的代码和说明文件,没有实际运行 Skill,也没有检查它另外安装的软件包。因此,这不是“保证安全”的承诺;换了版本或使用环境,结果也可能不同。

  • SKILL.md工作说明
读取了多少行
246
文件校验值(用于核对版本)
b14bd801bde0391a0bf889ad0067e7fd494852882d495dd721acf6e91727b7b3