@pzy560117/codex-harness 0.1.2 → 0.1.4

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/thesis-writing/references/final-checklist.md

@@ -1,60 +1,60 @@
-# 最终检查清单
-
-## 1. 内容与体裁
-
-- [ ] 摘要是否还出现命令、日志、类名、接口路径、组件名
-- [ ] 第一章是否仍然像开题报告复述，而不是论文绪论
-- [ ] 第二章是否只写了与本文直接相关的技术
-- [ ] 第三章是否存在接口清单、类名堆砌、需求文档腔
-- [ ] 第四章是否围绕关键问题组织，而不是围绕源码目录
-- [ ] 结论是否避免了“首次”“领先”“填补空白”等无据夸大表述
-
-## 2. 图表与代码清单
-
-- [ ] `mermaid` 是否都已经导出为正式图片
-- [ ] 图题是否在图下，表题是否在表上
-- [ ] 图号、表号、代码清单编号是否连续
-- [ ] 文中出现的“如图/表 x-x 所示”是否真的有对应对象
-- [ ] 图文件是否都有正文引用和解释段
-- [ ] 页面截图是否做了裁剪或重点标注，而不是原样堆放
-- [ ] 若存在“系统实现”章，前端截图是否来自浏览器真实运行界面，而不是原型图或静态拼图
-- [ ] 代码清单是否只保留少量核心片段，而非大段贴代码
-- [ ] 若存在“系统实现”章，后端代码片段是否都围绕关键实现点展开并配有说明
-
-## 3. 引文与参考文献
-
-- [ ] 正文是否在研究背景、研究现状、关键技术、设计或测试中真实使用了引文
-- [ ] 正文引文编号是否按首次出现顺序连续编号
-- [ ] 同一文献重复引用时是否沿用了原编号，而不是重新编号
-- [ ] 参考文献是否全部真实可检索
-- [ ] 文中引用过的文献是否都已著录
-- [ ] 未引用文献是否已移除
-- [ ] 文末参考文献列表是否按正文首次引用顺序排列
-- [ ] 正文编号与文末列表编号是否一一对应，无跳号、重号或顺序错位
-- [ ] 参考文献数量是否满足模板最低要求
-- [ ] 若模板未明确更高要求，参考文献是否至少达到 15 条
-- [ ] 中文参考文献占比是否约为 60%
-- [ ] 英文参考文献占比是否约为 20%
-- [ ] 其他参考文献占比是否约为 20%
-- [ ] 若按 15 条基线执行，是否至少达到“中文 9 条、英文 3 条、其他约 3 条”
-- [ ] 官方文档、RFC、技术手册等是否只作为补充来源，而没有占据主体
-- [ ] 是否包含一定比例的近五年文献
-- [ ] GB/T 7714-2015 格式是否统一
-
-## 4. 测试与结果
-
-- [ ] 测试章节是否包含“测试方法、测试环境、功能测试、性能测试、测试结果”
-- [ ] 功能测试是否提供了输入、预期输出、实际输出
-- [ ] 功能测试是否聚焦核心功能和边界场景
-- [ ] 性能测试若未真实执行，是否已如实说明
-- [ ] 测试结果是否写明发现的问题与处理方式
-- [ ] 构建通过是否被正确写成“构建校验”而非“测试结果”
-
-## 5. 模板与专项一致性
-
-- [ ] 模板规定的章节骨架是否被保留
-- [ ] 用例图、系统架构图、功能结构图、E-R 图、核心表结构是否满足模板要求
-- [ ] 开题设想与实际实现差异是否已被显式交代
-- [ ] 未落地功能是否没有被写成已实现事实
-- [ ] 致谢中是否混入模板说明或操作说明
-- [ ] 中英文摘要内容是否一致
+# 最终检查清单
+
+## 1. 内容与体裁
+
+- [ ] 摘要是否还出现命令、日志、类名、接口路径、组件名
+- [ ] 第一章是否仍然像开题报告复述，而不是论文绪论
+- [ ] 第二章是否只写了与本文直接相关的技术
+- [ ] 第三章是否存在接口清单、类名堆砌、需求文档腔
+- [ ] 第四章是否围绕关键问题组织，而不是围绕源码目录
+- [ ] 结论是否避免了“首次”“领先”“填补空白”等无据夸大表述
+
+## 2. 图表与代码清单
+
+- [ ] `mermaid` 是否都已经导出为正式图片
+- [ ] 图题是否在图下，表题是否在表上
+- [ ] 图号、表号、代码清单编号是否连续
+- [ ] 文中出现的“如图/表 x-x 所示”是否真的有对应对象
+- [ ] 图文件是否都有正文引用和解释段
+- [ ] 页面截图是否做了裁剪或重点标注，而不是原样堆放
+- [ ] 若存在“系统实现”章，前端截图是否来自浏览器真实运行界面，而不是原型图或静态拼图
+- [ ] 代码清单是否只保留少量核心片段，而非大段贴代码
+- [ ] 若存在“系统实现”章，后端代码片段是否都围绕关键实现点展开并配有说明
+
+## 3. 引文与参考文献
+
+- [ ] 正文是否在研究背景、研究现状、关键技术、设计或测试中真实使用了引文
+- [ ] 正文引文编号是否按首次出现顺序连续编号
+- [ ] 同一文献重复引用时是否沿用了原编号，而不是重新编号
+- [ ] 参考文献是否全部真实可检索
+- [ ] 文中引用过的文献是否都已著录
+- [ ] 未引用文献是否已移除
+- [ ] 文末参考文献列表是否按正文首次引用顺序排列
+- [ ] 正文编号与文末列表编号是否一一对应，无跳号、重号或顺序错位
+- [ ] 参考文献数量是否满足模板最低要求
+- [ ] 若模板未明确更高要求，参考文献是否至少达到 15 条
+- [ ] 中文参考文献占比是否约为 60%
+- [ ] 英文参考文献占比是否约为 20%
+- [ ] 其他参考文献占比是否约为 20%
+- [ ] 若按 15 条基线执行，是否至少达到“中文 9 条、英文 3 条、其他约 3 条”
+- [ ] 官方文档、RFC、技术手册等是否只作为补充来源，而没有占据主体
+- [ ] 是否包含一定比例的近五年文献
+- [ ] GB/T 7714-2015 格式是否统一
+
+## 4. 测试与结果
+
+- [ ] 测试章节是否包含“测试方法、测试环境、功能测试、性能测试、测试结果”
+- [ ] 功能测试是否提供了输入、预期输出、实际输出
+- [ ] 功能测试是否聚焦核心功能和边界场景
+- [ ] 性能测试若未真实执行，是否已如实说明
+- [ ] 测试结果是否写明发现的问题与处理方式
+- [ ] 构建通过是否被正确写成“构建校验”而非“测试结果”
+
+## 5. 模板与专项一致性
+
+- [ ] 模板规定的章节骨架是否被保留
+- [ ] 用例图、系统架构图、功能结构图、E-R 图、核心表结构是否满足模板要求
+- [ ] 开题设想与实际实现差异是否已被显式交代
+- [ ] 未落地功能是否没有被写成已实现事实
+- [ ] 致谢中是否混入模板说明或操作说明
+- [ ] 中英文摘要内容是否一致

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/thesis-writing/references/photographer-booking-paper.md

@@ -1,85 +1,85 @@
-# 独立摄影师预订系统专项指导
-
-## 重点论证的问题
-
-优先围绕以下问题组织正文：
-
-1. 三类角色的认证与授权边界
-2. 摄影师档期冲突控制
-3. 订单从创建到支付、签收、评价、退款的状态闭环
-4. 前后端围绕档期和订单状态的联动机制
-5. 管理员审核与退款仲裁的治理能力
-
-## 应谨慎处理的内容
-
-以下内容若实际未完整落地，不得写成已实现能力：
-
-1. 微服务
-2. Nacos / Gateway / Seata / OpenFeign
-3. 真实支付平台接入
-4. MinIO / OSS 对象存储
-5. 选片、通知、推荐等扩展功能
-
-正确写法：
-
-- “开题阶段曾考虑……”
-- “经权衡后最终采用……”
-- “当前版本以……替代，用于验证……”
-- “该能力保留为后续扩展方向”
-
-## 最容易写歪的地方
-
-1. 把第 3、4 章写成“后端实现 + 前端实现”
-2. 把页面截图堆成产品展示手册
-3. 把订单、档期、权限这些真正有技术含量的问题写轻了
-4. 把开题设想和最终实现混在一起
-5. 把构建通过写成测试结论
-
-## 第5章实现建议
-
-如果学校模板要求单独写“系统实现”章，当前项目更稳妥的写法不是回避前后端，而是把它们放到第5章中集中展示。
-
-推荐写法一：
-
-1. `5.1 客户端主要页面实现`
-2. `5.2 摄影师端页面实现`
-3. `5.3 管理端页面实现`
-4. `5.4 后端关键业务实现`
-
-推荐写法二：
-
-1. `5.1 前端主要页面实现`
-2. `5.2 后端关键模块实现`
-
-无论采用哪种写法，都要满足：
-
-1. 前端部分必须放**真实浏览器运行截图**，不能放原型图或静态设计图。
-2. 截图优先覆盖：首页/搜索页、摄影师详情与档期页、客户订单页、摄影师工作台、管理员审核或退款治理页。
-3. 每张截图后都要解释“页面做了什么、和哪类状态联动、为什么能证明实现成立”。
-4. 后端部分优先放真正有论证价值的代码，例如：
-   - `OrderService`
-   - `AvailabilityService`
-   - `PaymentService`
-   - `SecurityConfig`
-   - `RedisDistributedLock`
-5. 代码片段要短，只截关键逻辑，且必须配文字解释它解决了什么问题。
-
-## 图表专项提醒
-
-至少要保证以下图表真正落地：
-
-1. 总体架构图
-2. 角色或业务主流程图
-3. E-R 图
-4. 订单状态图
-5. 预约支付时序图
-6. 首页或搜索页截图
-7. 摄影师详情与档期截图
-8. 客户订单页截图
-9. 摄影师工作台截图
-10. 管理员审核或治理截图
-
-若某些图文件已生成但正文未使用，应二选一：
-
-- 正式插入并解释
-- 删除不用，避免图号体系混乱
+# 独立摄影师预订系统专项指导
+
+## 重点论证的问题
+
+优先围绕以下问题组织正文：
+
+1. 三类角色的认证与授权边界
+2. 摄影师档期冲突控制
+3. 订单从创建到支付、签收、评价、退款的状态闭环
+4. 前后端围绕档期和订单状态的联动机制
+5. 管理员审核与退款仲裁的治理能力
+
+## 应谨慎处理的内容
+
+以下内容若实际未完整落地，不得写成已实现能力：
+
+1. 微服务
+2. Nacos / Gateway / Seata / OpenFeign
+3. 真实支付平台接入
+4. MinIO / OSS 对象存储
+5. 选片、通知、推荐等扩展功能
+
+正确写法：
+
+- “开题阶段曾考虑……”
+- “经权衡后最终采用……”
+- “当前版本以……替代，用于验证……”
+- “该能力保留为后续扩展方向”
+
+## 最容易写歪的地方
+
+1. 把第 3、4 章写成“后端实现 + 前端实现”
+2. 把页面截图堆成产品展示手册
+3. 把订单、档期、权限这些真正有技术含量的问题写轻了
+4. 把开题设想和最终实现混在一起
+5. 把构建通过写成测试结论
+
+## 第5章实现建议
+
+如果学校模板要求单独写“系统实现”章，当前项目更稳妥的写法不是回避前后端，而是把它们放到第5章中集中展示。
+
+推荐写法一：
+
+1. `5.1 客户端主要页面实现`
+2. `5.2 摄影师端页面实现`
+3. `5.3 管理端页面实现`
+4. `5.4 后端关键业务实现`
+
+推荐写法二：
+
+1. `5.1 前端主要页面实现`
+2. `5.2 后端关键模块实现`
+
+无论采用哪种写法，都要满足：
+
+1. 前端部分必须放**真实浏览器运行截图**，不能放原型图或静态设计图。
+2. 截图优先覆盖：首页/搜索页、摄影师详情与档期页、客户订单页、摄影师工作台、管理员审核或退款治理页。
+3. 每张截图后都要解释“页面做了什么、和哪类状态联动、为什么能证明实现成立”。
+4. 后端部分优先放真正有论证价值的代码，例如：
+   - `OrderService`
+   - `AvailabilityService`
+   - `PaymentService`
+   - `SecurityConfig`
+   - `RedisDistributedLock`
+5. 代码片段要短，只截关键逻辑，且必须配文字解释它解决了什么问题。
+
+## 图表专项提醒
+
+至少要保证以下图表真正落地：
+
+1. 总体架构图
+2. 角色或业务主流程图
+3. E-R 图
+4. 订单状态图
+5. 预约支付时序图
+6. 首页或搜索页截图
+7. 摄影师详情与档期截图
+8. 客户订单页截图
+9. 摄影师工作台截图
+10. 管理员审核或治理截图
+
+若某些图文件已生成但正文未使用，应二选一：
+
+- 正式插入并解释
+- 删除不用，避免图号体系混乱

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/thesis-writing/references/test-result-templates.md

@@ -1,22 +1,22 @@
-# 测试结果写法模板
-
-## 功能测试用例表
-
-| 编号 | 测试功能 | 输入条件 | 预期输出 | 实际输出 | 是否通过 |
-|:---|:---|:---|:---|:---|:---|
-| TC-01 | 用户注册 | 合法邮箱与密码 | 注册成功并返回认证信息 | 与预期一致 | 通过 |
-| TC-02 | 并发预约 | 两个用户同时预约同一档期 | 仅一个请求成功，另一个返回冲突提示 | 与预期一致 | 通过 |
-
-## 性能测试结果表
-
-| 并发用户数 | 平均响应时间(ms) | 峰值响应时间(ms) | 成功率 |
-|:---|:---|:---|:---|
-| 10 | 45 | 120 | 100% |
-| 50 | 132 | 380 | 99.2% |
-
-## 测试结果分析起笔句型
-
-1. 由表 x-x 可见，系统在……场景下……，说明……机制能够稳定发挥作用。
-2. 上述测试结果表明，……功能已经覆盖了……核心路径，但……场景尚未纳入本次验证范围。
-3. 并发测试显示，在……并发量下，系统仍将……控制在……范围内，能够满足当前业务规模下的基本需求。
-4. 从功能测试和结果回显来看，系统在……方面达到了预期目标，但在……方面仍需继续完善。
+# 测试结果写法模板
+
+## 功能测试用例表
+
+| 编号 | 测试功能 | 输入条件 | 预期输出 | 实际输出 | 是否通过 |
+|:---|:---|:---|:---|:---|:---|
+| TC-01 | 用户注册 | 合法邮箱与密码 | 注册成功并返回认证信息 | 与预期一致 | 通过 |
+| TC-02 | 并发预约 | 两个用户同时预约同一档期 | 仅一个请求成功，另一个返回冲突提示 | 与预期一致 | 通过 |
+
+## 性能测试结果表
+
+| 并发用户数 | 平均响应时间(ms) | 峰值响应时间(ms) | 成功率 |
+|:---|:---|:---|:---|
+| 10 | 45 | 120 | 100% |
+| 50 | 132 | 380 | 99.2% |
+
+## 测试结果分析起笔句型
+
+1. 由表 x-x 可见，系统在……场景下……，说明……机制能够稳定发挥作用。
+2. 上述测试结果表明，……功能已经覆盖了……核心路径，但……场景尚未纳入本次验证范围。
+3. 并发测试显示，在……并发量下，系统仍将……控制在……范围内，能够满足当前业务规模下的基本需求。
+4. 从功能测试和结果回显来看，系统在……方面达到了预期目标，但在……方面仍需继续完善。

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/thesis-writing/references/thesis-analysis-template.md

@@ -1,63 +1,63 @@
-# 论文分析工作文档模板
-
-> 用途：该文档用于承载论文写作过程中的分析材料，不直接等同于论文正文。
->
-> 推荐文件名：`docs/thesis-analysis.md`
-
-## 1. 当前论文问题清单
-
-按以下维度记录问题：
-
-1. 体裁问题
-2. 章节结构问题
-3. 图表问题
-4. 引文问题
-5. 测试问题
-6. 模板一致性问题
-
-## 2. 开题与实现差异表
-
-| 项目 | 开题设想 | 实际实现 | 正文写法 |
-|:---|:---|:---|:---|
-| 架构 |  |  |  |
-| 支付 |  |  |  |
-| 文件存储 |  |  |  |
-| 扩展功能 |  |  |  |
-
-> 注意：此表默认留在分析文档中，正文通常只吸收“结论性表达”。
-
-## 3. 论文主轴矩阵
-
-| 技术问题 | 设计方案 | 实现证据 | 验证方式 |
-|:---|:---|:---|:---|
-|  |  |  |  |
-
-## 4. 章节重构建议
-
-按学校模板列出：
-
-1. 第 1 章该保留什么
-2. 第 2 章该压缩什么
-3. 第 3 章该补什么图表
-4. 第 4/5 章如何避免写成源码目录说明
-5. 第 6 章测试与结果如何分开
-
-## 5. 图表待补清单
-
-| 图表名称 | 所属章节 | 当前状态 | 处理动作 |
-|:---|:---|:---|:---|
-|  |  |  |  |
-
-## 6. 引文待补清单
-
-| 章节 | 需要引用的内容 | 候选来源 | 是否已落正文 |
-|:---|:---|:---|:---|
-|  |  |  |  |
-
-## 7. 最终入正文的内容边界
-
-在开始生成论文正文前，先明确：
-
-1. 哪些内容只保留在分析文档
-2. 哪些内容需要转写成论文语言进入正文
-3. 哪些未实现能力必须降级为“后续展望”
+# 论文分析工作文档模板
+
+> 用途：该文档用于承载论文写作过程中的分析材料，不直接等同于论文正文。
+>
+> 推荐文件名：`docs/thesis-analysis.md`
+
+## 1. 当前论文问题清单
+
+按以下维度记录问题：
+
+1. 体裁问题
+2. 章节结构问题
+3. 图表问题
+4. 引文问题
+5. 测试问题
+6. 模板一致性问题
+
+## 2. 开题与实现差异表
+
+| 项目 | 开题设想 | 实际实现 | 正文写法 |
+|:---|:---|:---|:---|
+| 架构 |  |  |  |
+| 支付 |  |  |  |
+| 文件存储 |  |  |  |
+| 扩展功能 |  |  |  |
+
+> 注意：此表默认留在分析文档中，正文通常只吸收“结论性表达”。
+
+## 3. 论文主轴矩阵
+
+| 技术问题 | 设计方案 | 实现证据 | 验证方式 |
+|:---|:---|:---|:---|
+|  |  |  |  |
+
+## 4. 章节重构建议
+
+按学校模板列出：
+
+1. 第 1 章该保留什么
+2. 第 2 章该压缩什么
+3. 第 3 章该补什么图表
+4. 第 4/5 章如何避免写成源码目录说明
+5. 第 6 章测试与结果如何分开
+
+## 5. 图表待补清单
+
+| 图表名称 | 所属章节 | 当前状态 | 处理动作 |
+|:---|:---|:---|:---|
+|  |  |  |  |
+
+## 6. 引文待补清单
+
+| 章节 | 需要引用的内容 | 候选来源 | 是否已落正文 |
+|:---|:---|:---|:---|
+|  |  |  |  |
+
+## 7. 最终入正文的内容边界
+
+在开始生成论文正文前，先明确：
+
+1. 哪些内容只保留在分析文档
+2. 哪些内容需要转写成论文语言进入正文
+3. 哪些未实现能力必须降级为“后续展望”

package/package-source/docs/codex-harness-engineering/templates/package-assets/skills/update-codemaps/SKILL.md

@@ -3,34 +3,34 @@ name: update-codemaps
 description: Workflow skill from update-codemaps.md
 ---
 
-# Update Codemaps
-
-Analyze the codebase structure and update AI navigation documentation. Use this when a project adds modules, changes architecture boundaries, introduces generated code, external systems, sensitive directories, or asks to refresh repo maps / codemaps.
-
-## Workflow
-
-1. Identify the existing navigation surface:
-   - Prefer `docs/ai/repo-map.md` when present.
-   - Otherwise use existing `codemaps/*.md`, `docs/architecture/*`, or create `docs/ai/repo-map.md` from the package template when the user asks for a reusable navigation map.
-2. Scan source, config, tests, contracts, generated-code markers, imports, exports, and dependency boundaries. Use structured parsers or language tools when available; use `rg` for targeted discovery.
-3. Generate token-lean navigation docs. Recommended files:
-   - `docs/ai/repo-map.md` - first-read AI navigation index
-   - `codemaps/architecture.md` - overall architecture when the project already uses codemaps
-   - `codemaps/backend.md` - backend structure
-   - `codemaps/frontend.md` - frontend structure
-   - `codemaps/data.md` - data models and schemas
-4. Include, at minimum:
-   - project purpose and core domains
-   - key directories and responsibilities
-   - module entry points and truth sources
-   - generated code, sensitive paths, and do-not-edit zones
-   - external systems and MCP / API touchpoints
-   - common verification commands
-   - subdirectory `AGENTS.md` index when present
-   - freshness timestamp and maintenance owner when known
-5. Keep the map high-level. Do not explain every function or paste large source excerpts.
-6. Calculate diff percentage from the previous version when updating an existing codemap. If changes exceed 30%, summarize the reason and request user approval before replacing broad sections, unless the user explicitly asked for a full refresh.
-7. Save a short report to `.reports/codemap-diff.txt` when `.reports/` exists or when the project already uses reports.
-8. If the root `AGENTS.md` lacks a code-map entry and the project is large enough to need one, recommend adding a short link instead of copying map content into `AGENTS.md`.
-
-Use TypeScript/Node.js for JavaScript and TypeScript analysis when practical. For other stacks, prefer the project's native language tooling or LSP output when available. Focus on high-level structure, not implementation details.
+# Update Codemaps
+
+Analyze the codebase structure and update AI navigation documentation. Use this when a project adds modules, changes architecture boundaries, introduces generated code, external systems, sensitive directories, or asks to refresh repo maps / codemaps.
+
+## Workflow
+
+1. Identify the existing navigation surface:
+   - Prefer `docs/ai/repo-map.md` when present.
+   - Otherwise use existing `codemaps/*.md`, `docs/architecture/*`, or create `docs/ai/repo-map.md` from the package template when the user asks for a reusable navigation map.
+2. Scan source, config, tests, contracts, generated-code markers, imports, exports, and dependency boundaries. Use structured parsers or language tools when available; use `rg` for targeted discovery.
+3. Generate token-lean navigation docs. Recommended files:
+   - `docs/ai/repo-map.md` - first-read AI navigation index
+   - `codemaps/architecture.md` - overall architecture when the project already uses codemaps
+   - `codemaps/backend.md` - backend structure
+   - `codemaps/frontend.md` - frontend structure
+   - `codemaps/data.md` - data models and schemas
+4. Include, at minimum:
+   - project purpose and core domains
+   - key directories and responsibilities
+   - module entry points and truth sources
+   - generated code, sensitive paths, and do-not-edit zones
+   - external systems and MCP / API touchpoints
+   - common verification commands
+   - subdirectory `AGENTS.md` index when present
+   - freshness timestamp and maintenance owner when known
+5. Keep the map high-level. Do not explain every function or paste large source excerpts.
+6. Calculate diff percentage from the previous version when updating an existing codemap. If changes exceed 30%, summarize the reason and request user approval before replacing broad sections, unless the user explicitly asked for a full refresh.
+7. Save a short report to `.reports/codemap-diff.txt` when `.reports/` exists or when the project already uses reports.
+8. If the root `AGENTS.md` lacks a code-map entry and the project is large enough to need one, recommend adding a short link instead of copying map content into `AGENTS.md`.
+
+Use TypeScript/Node.js for JavaScript and TypeScript analysis when practical. For other stacks, prefer the project's native language tooling or LSP output when available. Focus on high-level structure, not implementation details.

package/package-source/docs/codex-harness-engineering/templates/package-assets/workflows/README.md

@@ -1,15 +1,15 @@
-# Workflows
-
-本目录现在只保留**独立 workflow**，不再保留与 `skills/` 一一镜像的平铺副本。
-
-## 当前范围
-
-- `speckit.*.md`
-  Speckit 相关的独立流程文档。
-
-## 已迁移内容
-
-- 与 `skills/` 重名的 workflow 镜像已移到 `../archive/workflows/skill-mirrors/`
-- 废弃副本如 `code-review copy.md` 已移到 `../archive/workflows/deprecated/`
-
-如果某个主题已经在 `skills/<name>/SKILL.md` 中维护，优先以 skill 目录为准。
+# Workflows
+
+本目录现在只保留**独立 workflow**，不再保留与 `skills/` 一一镜像的平铺副本。
+
+## 当前范围
+
+- `speckit.*.md`
+  Speckit 相关的独立流程文档。
+
+## 已迁移内容
+
+- 与 `skills/` 重名的 workflow 镜像已移到 `../archive/workflows/skill-mirrors/`
+- 废弃副本如 `code-review copy.md` 已移到 `../archive/workflows/deprecated/`
+
+如果某个主题已经在 `skills/<name>/SKILL.md` 中维护，优先以 skill 目录为准。