wxs 6cc703ada2 feat: monorepo 重构 + 新增 5 个平台适配器

项目从单体结构重构为 pnpm monorepo (shared/backend/frontend)，
新增 YouTube、Instagram、Twitter/X、哔哩哔哩、微博 5 个平台适配器，
包含完整的单元测试和 E2E 测试覆盖。

- 完成 T-031~T-044: 5 个适配器实现、注册、配置和测试
- 重构前后端分离: Hono 后端 + Next.js 前端
- 151 个单元测试 + 21 个 Mock E2E + 25 个真实 E2E
- 适配器基于真实 TikHub API 响应结构实现

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

2026-03-03 15:43:25 +08:00

2.6 KiB

Raw Blame History

name	description
rr	评审 RequirementsDoc.md，检查需求文档的完整性、清晰度和可执行性，输出结构化评审报告。

Review RequirementsDoc

当用户调用 /rr 时，执行以下步骤：

1. 读取目标文档

读取 doc/RequirementsDoc.md 文件。

如果文件不存在，提示用户：

RequirementsDoc.md 不存在，请先创建需求文档。

2. 评审维度

RequirementsDoc 是文档链的源头，没有上游依赖。重点检查以下维度：

2.1 完整性

产品概述是否清晰（定位、目标用户、核心价值）
功能需求是否完整列出
非功能需求是否涵盖（性能、安全、兼容性）
数据规范是否明确（输入输出格式、字段定义）
边界条件和异常情况是否考虑

2.2 清晰度

术语定义是否一致，无歧义
用例描述是否具体可理解
优先级是否明确标注
是否有模糊表述（"等"、"可能"、"应该"等）

2.3 可执行性

需求是否可被验证（有明确的验收标准）
技术约束是否合理
依赖项是否明确

2.4 结构规范

文档结构是否清晰（章节划分合理）
格式是否统一（表格、列表、标题层级）

3. 生成评审报告

按以下格式输出评审报告：

# RequirementsDoc 评审报告

## 概要

| 项目 | 内容 |
|------|------|
| 评审时间 | {YYYY-MM-DD HH:mm} |
| 目标文档 | doc/RequirementsDoc.md |
| 问题统计 | {critical} 个严重 / {major} 个一般 / {minor} 个建议 |

## 问题清单

### 严重问题 (Critical)

> 必须修复，否则影响后续文档生成

1. **[位置: 第X节/第Y行]** 问题描述
   - 现状：...
   - 建议：...

### 一般问题 (Major)

> 建议修复，可提升文档质量

1. **[位置]** 问题描述
   - 建议：...

### 改进建议 (Minor)

> 可选优化项

1. **[位置]** 建议内容

## 评审结论

{通过 / 需修改后通过 / 不通过}

### 下一步行动

- [ ] 行动项1
- [ ] 行动项2

4. 保存报告

将评审报告保存到 doc/review-RequirementsDoc-claude.md。

如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。

5. 输出摘要

向用户展示评审摘要：

发现的问题数量（按严重程度分类）
评审结论
报告文件路径

注意事项

评审时保持客观，聚焦于文档质量而非业务判断
问题描述要具体，给出明确的位置引用
建议要可操作，避免模糊表述
不要修改原文档，只输出评审报告

2.6 KiB Raw Blame History Unescape Escape