hplan-083b2f — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited hplan-083b2f (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
用文件系统作为持久化工作记忆。overview.md 保持精简（≤25行），详细规格按阶段拆分到独立目录中。
上下文窗口 = RAM（易失、有限）
文件系统 = 磁盘（持久、无限）
→ 重要信息必须写入磁盘
→ 被 hook 注入的内容必须精简
→ 被深度参考的内容必须详尽
→ 二者分离，互不冲突如果感觉上下文缺失，主动读取 .plan/ 下的相关文件即可。所有计划信息都持久化在磁盘文件中，不会因上下文变化而丢失。
所有计划文件存放在项目根目录的 .plan/ 目录下：
.plan/
├── overview.md ← 全局摘要（精简，被 hook 反复注入）
├── decisions.md ← 所有决策记录
├── errors.md ← 所有错误记录
└── phases/
├── phase1_xxx/
│ ├── spec.md ← 该阶段详细规格（修改文件、代码变更）
│ ├── call_chain.md ← 调用链 / 架构图（可选）
│ └── checklist.md ← 逐项完成状态
├── phase2_xxx/
│ ├── spec.md
│ ├── call_chain.md
│ └── checklist.md
└── ...overview.md 是被 PreToolUse hook 每次注入到上下文的文件。严格控制在 25 行以内。格式如下：
# [项目名称]
current_phase: phase2_xxx
## Goal
[一句话描述最终目标]
## Phases
- [x] phase1_xxx: [阶段描述] → complete
- [ ] phase2_xxx: [阶段描述] → in_progress (2/4)
- [ ] phase3_xxx: [阶段描述] → pending
## Blockers
[当前阻塞项，没有则写 None]
## Last Decision
[最近一条重要决策的一句话摘要]
## Last Error
[最近一条错误的一句话摘要，没有则写 None]绝对不要在 overview.md 里放详细的文件清单、代码片段、调用链。那些内容属于 phase 目录。
每个 phases/phaseN_xxx/ 目录包含该阶段的完整信息：
spec.md — 该阶段的详细规格：
spec.md 控制在 60 行以内。 当用户发送新消息时，如果有进行中的阶段，当前阶段的 spec.md 会被自动注入到上下文。如果一个阶段的 spec 写出来超过 60 行，说明这个阶段的粒度太粗，应该拆分成两个或更多阶段。拆分时保持每个阶段的 spec 聚焦于一组相关的修改，而非堆砌所有细节。
call_chain.md（可选）— 调用链 / 架构变更图：
checklist.md — 该阶段的逐项检查清单：
# Phase 2: 后端接口改造 — 检查清单
- [x] 新建 src/auth/token.py
- [x] 修改 src/auth/routes.py
- [ ] 修改 src/middleware/auth.py
- [ ] 修改 config/auth.yaml
- [ ] 运行单元测试确认无回归收到复杂任务后：
.plan/ 目录结构（可运行 sh scripts/init-plan.sh 快速初始化）参考模板文件：
计划创建完成后，必须停下来等待用户确认，严禁自行开始执行。
向用户展示以下内容并请求确认：
明确询问用户：
只有在用户明确表示同意后，才能进入执行阶段。 如果用户提出调整意见，修改计划文件后再次展示并请求确认。
#### 修改计划时必须保持 overview.md 与 phases/ 目录同步
在确认阶段与用户反复调整计划时，任何对阶段的增删改都必须同时更新两个地方：
phases/phaseN_xxx/ 目录及 spec.md、checklist.mdphases/phaseN_xxx/ 目录phases/ 下的目录（不要保留旧目录）每次修改计划后，运行 sh scripts/validate-plan.sh 校验一致性。该脚本会检查：
用户确认计划后，进入工作循环：
[ ] → [x]）current_phase 指向下一阶段sh scripts/advance-phase.sh 辅助切换当 overview.md 中 current_phase 变更后：
第1次失败：诊断并修复 → 记录到 errors.md
第2次失败：换一种方法 → 记录到 errors.md
第3次失败：重新审视假设 → 更新 spec.md
第3次后仍失败：向用户说明情况，请求指导Stop hook 会自动检查 overview.md 中所有阶段的完成状态。如果存在未完成的阶段，会提示你检查剩余任务。用户可以随时通过删除 .plan/ 目录来退出计划。
应尽量亲自执行 checklist 中的每一项，而非将工作交给用户手动执行。
如果某个子任务你无法完成（例如需要外部服务的密钥、需要物理设备操作），应当：
以下行为应避免：
计划全部完成后，用户可能提出修改意见。根据修改的复杂度选择不同的处理方式：
直接修复（修改涉及 ≤2 个文件，不改变架构）：
追加阶段（修改涉及 3+ 个文件，或需要调整调用链）：
.plan/ 上追加新的 phase 目录（如 phase10_fix_xxx）current_phase 指向新阶段sh scripts/validate-plan.sh 校验一致性全新计划（修改的性质是推翻原设计）：
.plan/ 重命名为 .plan.archived/（保留记录）判断标准：如果用户的修改意见可以表述为"在现有架构上修 N 个问题"，追加阶段；如果必须表述为"重新设计 XXX 模块"，全新计划。
使用：
不使用：
| 场景 | 操作 | 原因 |
|---|---|---|
| 刚写完文件 | 不读 | 内容还在上下文中 |
| 开始新阶段 | 读 spec.md + checklist.md | 完整理解工作范围 |
| 做重要决策前 | 读 overview.md + 相关 spec | 确保目标对齐 |
| 遇到错误 | 读 errors.md | 避免重复失败 |
| 不要 | 应该 |
|---|---|
| 在 overview.md 里放详细信息 | 放在 phase 目录的 spec.md 里 |
| overview.md 超过 25 行 | 精简到只有摘要 |
| spec.md 超过 60 行 | 拆分为多个阶段，每个阶段的 spec 保持聚焦 |
| 跳过创建计划直接执行 | 先创建完整的 .plan/ 目录 |
| 忘记更新 checklist.md | 每完成一项立即更新 |
| 在 spec.md 里更新状态 | 状态在 checklist.md，规格在 spec.md |
| 重复同样的失败操作 | 记录错误，变换方法 |
| 把未完成的子任务交给用户手动执行 | 尽量自己执行，遇到阻塞时请求用户提供必要信息 |
| 列出剩余步骤的说明后结束 | 尽量实际执行这些步骤，完成后再结束 |
| 创建计划后直接开始执行 | 展示计划并等待用户确认后才执行 |
| 修改 overview.md 后不同步 phases/ 目录 | 增删改阶段时同时更新两处，用 validate-plan.sh 校验 |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.