Menu
评审需求(PRD), 从业务价值和技术可行性角度回答问题, 给出评估。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
定期巡查仓库，监控 CI 状态、扫描未处理 Issue，自动分发到对应 skill 处理。
通用问答, 回答用户咨询、技术探讨等非错误、非功能需求的 Issue。
分析 Bug 类型 Issue, 定位根因, 并对简单 Bug 自动创建修复 PR。
定义 GitHub 评论的格式规范, 强调使用折叠 `<details>` 保持简洁。
根据 Issue 的讨论和方案, 实现功能或修复 Bug, 并创建 PR。
自动审查 PR, 检查代码质量、风格和潜在问题, 支持增量审查。
| name | feature-review |
| description | 评审需求(PRD), 从业务价值和技术可行性角度回答问题, 给出评估。 |
评审功能需求。输出面向产品经理，业务化表达，避免技术术语。
遵循
github-comment规范。
| 级别 | 工时 | 典型特征 |
|---|---|---|
| small | < 1天 | 单文件改动、配置修改、简单 UI 调整 |
| medium | 1-3天 | 新增独立功能、涉及 2-5 个文件、需要单元测试 |
| large | 3-5天 | 跨模块改动、需要接口设计、涉及数据迁移 |
| extra-large | > 1周 | 架构变更、新增子系统、需要多方协调 |
评估时考虑：
## 📋 需求评审 #${issue_number}
| 项目 | 评估 |
|------|------|
| **业务价值** | {这个功能解决什么用户问题} |
| **预估成本** | 🟢 small / 🟡 medium / 🟠 large / 🔴 extra-large |
**主要挑战**:
- {用业务语言描述难点，如"需要对接第三方系统"}
**影响范围**:
- {哪些用户可见的功能会受影响}
- {是否涉及数据变更}
<details>
<summary><h3>🔧 技术细节</h3></summary>
**涉及模块**: {列出}
**关键文件**: [{文件}]({github_link})
**技术风险**: {如有}
</details>
<details>
<summary><h3>❓ 待澄清问题</h3></summary>
- {需求不明确的地方，用问句形式}
</details>