بنقرة واحدة
taiyi-reanalyze
TaiyiForge 辅助 — 重新理解已有需求工件,找出矛盾、缺口、歧义。OpenCode / Claude / Codex / Cursor 通用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
TaiyiForge 辅助 — 重新理解已有需求工件,找出矛盾、缺口、歧义。OpenCode / Claude / Codex / Cursor 通用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
TaiyiForge /taiyi:plan — 项目规划入口:把 README/PRD 拆解为独立 change 清单,推荐 profile 和依赖关系。OpenCode / Claude / Codex / Cursor 通用。
TaiyiForge 第1阶段 — 变更提案,CHANGE.md。四端通用。
TaiyiForge 第3阶段 — 技术设计(≥2方案),DESIGN.md。四端通用。
TaiyiForge 第6阶段 — TDD开发执行。四端通用。
TaiyiForge 辅助 — 代码库健康巡检。四端通用。
TaiyiForge 第9阶段 — 闭环归档,CHANGELOG.md。四端通用。
| name | taiyi-reanalyze |
| description | TaiyiForge 辅助 — 重新理解已有需求工件,找出矛盾、缺口、歧义。OpenCode / Claude / Codex / Cursor 通用。 |
当需求文档写了一段时间后,团队对需求的理解可能已经变化。这个技能重新阅读 CHANGE.md 和 REQUIREMENT.md,找出其中的矛盾、缺口和模糊点,产出一份「二次理解」报告。
reanalyze 跑在 requirement 写完之后、dev 开始之前:
change → requirement → /taiyi:sp reanalyze(重新理解)
│ │
▼ ▼ 产出 REANALYZE.md
design → ui-design → task → dev → ...
│
缺口/歧义 → 回到 requirement 补 AC
| 信号 | 建议 |
|---|---|
| change 写完后放了一周以上才开始 dev | 必跑 |
| 多人协作,中间有人改过 scope | 必跑 |
| requirement 写到一半觉得不对劲 | 必跑 |
| review 阶段发现设计和需求对不上 | 必跑 |
| 刚写完 change,记忆还新鲜 | 跳过 |
.taiyi/changes/<slug>/CHANGE.md.taiyi/changes/<slug>/REQUIREMENT.mdCONTEXT.md 代码情报一份重新分析报告,写到 .taiyi/changes/<slug>/REANALYZE.md 或直接在聊天里展示。
格式:
# Reanalyze: <slug>
> 重分析日期 · 原始 change 日期 · 间隔 X 天
## 重新理解
用一句话重述这个 change 要解决什么问题。
## 一致性检查
| 检查项 | 状态 | 说明 |
|--------|------|------|
| CHANGE 和 REQUIREMENT 的范围一致 | ✅ | |
| AC 覆盖了所有 scope 条目 | ❌ | 缺少「权限校验」的 AC |
| 设计方案的假设在代码情报中成立 | ⚠️ | CONTEXT 标记了风险区 |
| 没有自相矛盾的 AC | ✅ | |
## 缺口
列出 REQUIREMENT 中应该覆盖但没覆盖的内容:
1. **缺口 1**:XXX 场景没有 AC
2. **缺口 2**:未定义错误处理策略
## 歧义
列出表述不清、有多种理解的内容:
1. **歧义 1**:「支持多种登录方式」—— 具体哪几种?oauth 还是手机号?
2. **歧义 2**:「高性能」—— 量化标准是什么?
## 建议
- 补充 AC:「XXX」
- 向产品确认:「YYY」
- 缩小 scope:「ZZZ 放到下一期」
把 CHANGE.md 和 REQUIREMENT.md 当成第一次读:
| 核对 | 方法 |
|---|---|
| CHANGE vs REQUIREMENT | 每个 scope 条目在 REQUIREMENT 中有对应的 AC 吗? |
| AC 完整性 | happy path / error path / edge case 都覆盖了吗? |
| 假设 vs 现实 | CONTEXT.md 中的代码现实是否推翻了设计假设? |
| 自洽性 | AC 之间有没有互相矛盾的? |
重点关注:
报告展示完后,必须询问:
要自动修复发现的问题吗?
- 自动修:我直接更新 CHANGE.md / REQUIREMENT.md 中的缺口和歧义
- 手动修:你自己对着报告改,我把 REANALYZE.md 保存下来
- 不修:只看报告不做改动
CHANGE.md 的 Scope 部分REQUIREMENT.mdtaiyi-design 重新设计