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

Write Tech Spec Skill 安全审计

作者说它能做什么（原文）

Write a TECH.md spec for a significant Warp feature after researching the current codebase and implementation constraints. Use when the user asks for a technical spec, implementation plan, or architecture doc tied to a product spec.

第三方安全检查结论

这次检查未发现明显风险

已检查文件
1
发现的风险
0
会不会运行危险命令？检查是否下载程序后直接运行、让他人远程控制电脑，或藏起要运行的命令。未发现风险
会不会泄露文件和密钥？检查是否发送含密码或密钥的文件，以及代码里是否直接写了密钥。未发现风险
会不会删除文件或一直在后台运行？检查是否大范围删除文件、改写磁盘，或设置自动启动。未发现风险
会不会绕过安全保护？检查是否跳过网站安全验证、开放过多文件权限，或取消操作前的确认。未发现风险
会不会误导 AI 或隐藏内容？检查工作说明是否要求 AI 忽略你的指令、干扰检查结果，或夹带看不见的文字。未发现风险
会不会偷偷改推广链接或收款方？检查是否强制替换推广链接或收款对象，同时要求隐瞒更改。未发现风险

Skill 逻辑拆解

8 个说明模块

该 Skill 的主要行为是研究现有代码和产品规格，然后在 `specs/<id>/TECH.md` 创建一份技术规格；这是持久文件写入，但与其声明用途直接一致。

查看原文
SKILL.md:8来自说明文档打开原文件
Write a `TECH.md` spec for a significant feature in Warp.
SKILL.md:14来自说明文档打开原文件
Write specs to `specs/<id>/TECH.md`, where `<id>` is one of:- a Linear ticket number (e.g. `specs/APP-1234/TECH.md`)- a GitHub issue id, prefixed with `gh-` (e.g. `specs/gh-4567/TECH.md`)- a short kebab-case feature name (e.g. `specs/vertical-tabs-hover-sidecar/TECH.md`)

起草前，它要求读取产品规格并检查相关代码、类型、数据流和所有权边界，以便规格基于当前实现而不是猜测。

查看原文
SKILL.md:30来自说明文档打开原文件
## Research before writingBefore drafting, read the product spec (if any), inspect the relevant code, and identify the main files, types, data flow, and ownership boundaries. Do not guess about current architecture when the code can be inspected directly.When referencing relevant code chunks in the spec, prefer commit-pinned references so future readers can inspect the exact code you researched. Capture the current commit SHA for each repository you inspected (for example, `git rev-parse HEAD`) and, when possible, make file references Markdown links to the corresponding GitHub `blob/<sha>/...#Lx-Ly` URL. Use the linked text to keep the path readable in the spec.

它不会自行授权创建外部工单：只有用户明确要求时，才允许通过 Linear 工具或 `gh` 创建工单；团队、标签或仓库不明确时还要求询问用户。

查看原文
SKILL.md:22来自说明文档打开原文件
Ticket / issue references are optional. If the user has a Linear ticket or GitHub issue, use its id. If they don't, ask them for a feature name to use as the directory. Only create a new Linear ticket or GitHub issue when the user explicitly asks for one; in that case use the Linear MCP tools or `gh` CLI respectively (and `ask_user_question` if team, labels, or repo are unclear).

关于并行代理的内容是要求在技术规格中评估和记录未来实施的并行方案，而不是直接启动代理；当相关能力不可用时，应省略该章节。

查看原文
SKILL.md:45来自说明文档打开原文件
3. **Testing and validation** — How the implementation will be verified against the product behavior. Owns everything about proving the feature works: unit tests, integration tests, manual steps, screenshots, videos, and any other verification. Reference the numbered Behavior invariants from `PRODUCT.md` directly rather than restating them; each important invariant should map to a concrete test or verification step. This section is where validation lives — `PRODUCT.md` intentionally does not have a Validation section.4. **Parallelization** — Actively evaluate whether parallel sub-agents (launched via `run_agents`) would meaningfully reduce wall-clock time or isolate work. Skip this section if `run_agents` is not available. When the spec proposes using sub-agents, include for each proposed agent:   - A short name/role and the subtask it owns.
SKILL.md:55来自说明文档打开原文件
   When parallelization is NOT proposed, briefly note why it isn't beneficial (e.g. the task is small, or subtasks are tightly coupled) so reviewers can challenge that judgment.   Propose concrete defaults for worktrees, branch names, and execution mode rather than leaving them open-ended.
从这里开始 · 工作说明SKILL.md
write-tech-spec
连线表示工作说明包含的模块，不是实际运行顺序。点击模块可查看原文。
文件与检查记录1 个文件

检查范围与遗漏

逐文件查看涉及的内容

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

  • SKILL.md已纳入全文

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

  • SKILL.md工作说明

代码和说明中提到的操作

连接外部网站
SKILL.md:40来自说明文档打开原文件
1. **Context** — What's being built, how the current system works in the area being changed, and the most relevant files with line references. Combine the "problem," "current state," and "relevant code" into one grounded section. Example re …   - [`app/src/workspace/mod.rs:42 @ <commit-sha>`](https://github.com/warpdotdev/warp/blob/<commit-sha>/app/src/workspace/mod.rs#L42) — entry point for the user flow   - [`app/src/workspace/workspace.rs (120-220) @ <commit-sha>`](https://github.com/warpdotdev/warp/blob/<commit-sha>/app/src/workspace/workspace.rs#L120-L220) — state and event handling that will likely change
SKILL.md:41来自说明文档打开原文件
   - [`app/src/workspace/mod.rs:42 @ <commit-sha>`](https://github.com/warpdotdev/warp/blob/<commit-sha>/app/src/workspace/mod.rs#L42) — entry point for the user flow   - [`app/src/workspace/workspace.rs (120-220) @ <commit-sha>`](https://github.com/warpdotdev/warp/blob/<commit-sha>/app/src/workspace/workspace.rs#L120-L220) — state and event handling that will likely change   Reference `PRODUCT.md` for user-visible behavior rather than restating it.
读取了多少行
96
文件校验值（用于核对版本）
53cf3077c7e2fd7178027aa9cf89ff03eff26500ed1405da8362e0d87160cd1b