AgentStack
SKILL verified MIT Self-run

Pdlc Review

skill-kanfu-panda-pdlc-skills-pdlc-review · by kanfu-panda

代码评审 + 文档评审

No reviews yet
0 installs
10 views
0.0% view→install

Install

$ agentstack add skill-kanfu-panda-pdlc-skills-pdlc-review

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Pdlc Review? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

代码评审

对指定的服务或应用进行全面的代码评审。

PDLC 前置检查(必须执行,不可跳过)

  1. 从用户输入中提取功能名称关键词
  2. 检查实现代码是否存在:在 backend/frontend/ 下搜索与该功能相关的源代码文件(非测试文件)
  3. 检查测试是否通过:找到对应的测试代码并运行,确认测试处于绿灯状态(全部通过)
  4. 未找到实现代码 → 输出以下信息后立即停止,不继续执行

`` ⛔ PDLC 守卫:未找到与「」相关的实现代码。 评审必须基于已有的代码实现。请先运行: 👉 /pdlc-implement ``

  1. 测试未通过 → 输出以下信息后立即停止,不继续执行

`` ⛔ PDLC 守卫:「」的测试未全部通过,无法进行评审。 请先确保所有测试通过后再提交评审: 👉 /pdlc-implement (修复失败的测试) ``

  1. 检查通过 → 提取功能ID(从相关设计文档或 PRD 中),继续执行

评审流程

  1. 阅读设计文档: 先阅读 docs/02_design/ 对应子目录下的相关设计文档
  2. 阅读编码规范: 阅读 docs/00_standards/coding/ 目录了解编码规范(未命中 → 报告里提示 consider /pdlc-standard add coding/
  3. 检查代码实现: 对照设计文档逐一检查实现是否符合
  4. 检查测试覆盖: 确认测试是否充分覆盖
  5. 代码质量自动检查与修复(必须执行):
  • /pdlc-lint check 逻辑运行项目 lint 工具
  • 若存在可自动修复的问题,按 /pdlc-lint fix 逻辑自动修复
  • 记录修复前后的问题数变化

评审检查项(逐项检查,发现问题立即修复)

设计一致性(对照设计文档)

  • [ ] 每个 API 接口的 URL、方法、参数是否与设计文档一致
  • [ ] 数据库表结构、字段名、类型是否与 DB 设计一致
  • [ ] 响应格式是否统一遵循 { code, message, data }

代码质量

  • [ ] 命名是否规范(变量/函数/类遵循项目命名约定)
  • [ ] 是否有重复代码可提取为公共方法
  • [ ] 错误处理是否合理(不吞异常、不用空 catch、有意义的错误信息)
  • [ ] 日志是否充分(关键操作有日志、不打印敏感信息)

安全检查

  • [ ] SQL 注入:是否使用参数化查询/ORM,无字符串拼接 SQL
  • [ ] XSS:用户输入是否转义后再输出
  • [ ] 权限控制:接口是否有鉴权,敏感操作是否有权限校验
  • [ ] 敏感数据:密码是否加密存储、Token 是否有过期机制、日志不含敏感字段

性能检查

  • [ ] 数据库查询是否有 N+1 问题
  • [ ] 列表接口是否有分页
  • [ ] 是否有不必要的全表扫描(缺失索引)
  • [ ] 大数据量操作是否有批处理

测试完备性

  • [ ] 单元测试覆盖率是否 >= 80%
  • [ ] 核心业务路径是否有完整的测试
  • [ ] CHANGELOG 是否已更新

自动修复(评审中发现的问题,能修则修)

对以下类型的问题直接修复代码,不仅仅记录

  1. lint 问题:运行 lint fix 自动修复格式、规范问题
  2. 命名不规范:自动重命名为符合项目约定的名称
  3. 缺失错误处理:自动补充 try-catch / 错误码返回
  4. 缺失日志:在关键操作处自动添加日志语句
  5. SQL 注入风险:自动改写为参数化查询
  6. XSS 风险:自动添加输出转义
  7. 缺失分页:自动为列表接口补充分页逻辑
  8. 缺失 CHANGELOG:自动追加变更条目

不可自动修复的问题(记录到评审报告,标记为需人工处理):

  • 架构层面的设计问题
  • 业务逻辑的正确性争议
  • 需要重大重构的性能问题

评审报告生成

> ⚠️ 必须创建文件,不可仅在对话中输出。

【必须创建文件】docs/07_reviews/code/ 下创建评审记录:

  • 文件名格式: --review.md(如 F20260326-01-user-auth-review.md
  • 文档顶部必须包含 PDLC 追溯头

```

```

  • 报告内容格式

```markdown ## 评审总结

  • 评审时间:
  • 评审范围:
  • 问题总数:X 项(阻塞: X / 严重: X / 一般: X / 建议: X)
  • 自动修复:X 项
  • 需人工处理:X 项

## 自动修复记录 | # | 问题类型 | 文件 | 修复内容 | |---|---------|------|---------| | 1 | lint | src/xxx.ts | 修复 XX 规则违规 |

## 需人工处理 | # | 严重程度 | 问题描述 | 建议方案 | |---|---------|---------|---------| | 1 | 阻塞 | XXX | 建议 XXX |

## 评审检查项结论

  • [x] 设计一致性:通过
  • [x] 代码质量:通过(X 项已自动修复)
  • [ ] 安全检查:X 项需人工确认

```

  1. 修复后验证:自动修复完成后,重新运行全部测试,确认修复未引入新问题
  • 测试通过 → 评审完成
  • 测试失败 → 回滚修复,将问题标记为需人工处理

要求

  • 问题按严重程度分级:阻塞 / 严重 / 一般 / 建议
  • 能修的问题直接修复,不仅仅指出问题
  • 修复后必须验证测试仍然通过

评审目标: $ARGUMENTS


文档评审

对指定的文档进行质量评审,检查完整性、一致性和可操作性。发现问题直接修复,而非仅列出建议。

文档评审检查项

完整性
  • [ ] 是否覆盖了所有必要章节(对照对应模板 templates/ 检查)
  • [ ] 是否有遗漏的功能点或接口
  • [ ] 非功能需求是否有说明
  • [ ] 是否有明确的验收标准
  • [ ] PDLC 追溯头是否完整(功能ID、功能名称、阶段、前置文档、创建时间)
一致性
  • [ ] 术语命名是否前后一致(同一概念不用不同名称)
  • [ ] 数据模型是否与 API 设计一致(字段名、类型)
  • [ ] 接口参数是否与 PRD 需求对应
  • [ ] 版本号和日期是否准确
  • [ ] 文档间交叉引用路径是否正确
可操作性
  • [ ] 操作步骤是否具体可执行(无模糊表述如「适当配置」「按需调整」)
  • [ ] 是否有示例代码或示例数据
  • [ ] 错误码是否有清晰的处理建议
  • [ ] 部署步骤是否可复现
规范性
  • [ ] 是否符合对应模板格式
  • [ ] 表格是否完整(无空列、无缺失表头)
  • [ ] Markdown 语法是否正确(标题层级、列表缩进、代码块语言标注)
  • [ ] 输出语言是否符合用户对话语言(或用户显式指定的语言)

文档自动修复规则(发现即修,不仅记录)

  1. 缺失章节:对照模板自动补充,内容根据文档已有信息合理推断
  2. PDLC 追溯头缺失或不完整:自动补全缺失字段
  3. 术语不一致:统一为文档中首次出现的术语,全文替换
  4. 模糊表述:自动改写为具体、可度量的描述
  5. 表格格式问题:自动修复空列、对齐问题
  6. Markdown 语法错误:自动修复标题层级、列表缩进
  7. 交叉引用路径错误:检查引用的文件是否存在,不存在则标注警告
  8. 缺失示例:为 API 接口自动补充请求/响应示例

不可自动修复的问题(记录到评审报告):

  • 业务逻辑的正确性争议
  • 需要与产品确认的需求歧义
  • 涉及跨文档架构调整的问题

文档评审工作流程

  1. 识别文档类型:判断文档属于 PRD / API 设计 / DB 设计 / 架构设计 / 测试计划 / 部署手册
  2. 加载对照物
  • 加载对应的模板(templates/ 目录)
  • 加载前置文档(从 PDLC-TRACE 中获取路径)
  • 如是设计文档,同时加载 PRD 进行交叉比对
  1. 逐项检查:按上方检查项逐一执行
  2. 自动修复:发现问题直接修改原文档
  3. 【必须创建文件】生成评审记录:在 docs/07_reviews/doc/ 下创建评审记录
  • 文件名格式: ---doc-review.md
  • 报告格式

```markdown ## 文档评审报告

  • 评审时间:
  • 目标文档:
  • 文档类型:
  • 问题总数:X 项(必须修改: X / 建议修改: X / 可选: X)
  • 自动修复:X 项
  • 需人工确认:X 项

## 自动修复记录 | # | 问题类型 | 修复内容 | |---|---------|---------| | 1 | 缺失章节 | 补充了「非功能需求」章节 |

## 需人工确认 | # | 严重程度 | 问题描述 | 建议 | |---|---------|---------|------| | 1 | 必须修改 | XXX 需求存在歧义 | 建议与产品确认 |

## 检查项结论

  • [x] 完整性:通过
  • [x] 一致性:通过(X 项已修复)
  • [x] 可操作性:通过
  • [x] 规范性:通过

```

  • 修复后仅复查一次(确认修复未引入新问题),不再递归修复。若复查仍发现问题,记录到评审报告的「需人工确认」中

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.