@tanlinfeng/project-docs-workflow 2.2.0 → 3.0.0

package/skills/grilling/SKILL.md

@@ -1,46 +0,0 @@
----
-name: grilling
-description: 追问式访谈，把计划、决策或想法压到没有含糊之处。当用户想压力测试自己的思路、或说出任何 "grill" 触发短语时使用。
----
-
-# Grilling（追问式访谈）
-
-> 轻量精简版，裁剪自 [mattpocock/skills](https://github.com/mattpocock/skills) 的 grilling（MIT License, Copyright (c) 2026 Matt Pocock）。若环境已安装同名完整 skill，请优先使用完整版。
-
-持续追问用户，直到双方对方案达成共同理解。把这次访谈建模成一棵**设计树（design tree）**：每个决策都会分叉出依赖它的子决策。
-
-## 按轮次推进
-
-**frontier（前沿）** = 所有前置条件已确定的决策：也就是你现在就能问、不必臆测尚未听到的答案的问题。
-
-1. 一轮处理当前 frontier：把 frontier 上的问题**一次性全部提出**。
-2. 每个问题**编号**，并给出**你推荐的答案**。
-3. 等用户回答后，再进入下一轮。
-
-轮次格式：
-
-```
-❓ **Q1** - **<问题标题>**：<问题正文，可多段，可含多选项>
-
-➡️ <你推荐的答案>
-
----
-
-❓ **Q2** - **<问题标题>**：<问题正文>
-
-➡️ <你推荐的答案>
-```
-
-用户每一轮的回答会重塑整棵树：已确定的决策把 frontier 向外推，解锁依赖它们的问题。每轮结束都**重新计算 frontier**，再问下一轮。若某问题的答案依赖本轮尚未解决的另一个问题，它属于**后面的轮次**，不属于本轮。
-
-## 事实 vs 决策
-
-- **事实是 agent 的活，永远不要问用户。** 当某个 frontier 问题需要环境中的事实（文件系统、工具、外部文档等），派子 agent 去查，不要问用户你本可以自己查的东西。
-- **不要因此阻塞**：一个还在跑的探查本身就是一个未确定的前置条件，所以只有它下游的问题需要等子 agent 回报；frontier 上其余问题现在就问。
-- **决策是用户的活。** 每个决策都摆到用户面前并等待回答，绝不替用户拍板。
-
-## 完成条件
-
-当 frontier 为空——设计树每个分支都走过、没有任何东西被默默假设——本次访谈结束。
-
-**在用户确认你们达成了共同理解之前，不要动手实施。**

package/skills/grilling/agents/openai.yaml

@@ -1,3 +0,0 @@
-interface:
-  display_name: "Grilling"
-  short_description: "Stress-test thinking a round of questions at a time"

package/skills/improve-codebase-architecture/SKILL.md

@@ -1,15 +0,0 @@
----
-name: improve-codebase-architecture
-description: 代码库架构改进路线的占位；需要术语或 ADR 支持时转 domain-modeling。
-disable-model-invocation: true
----
-
-# Improve Codebase Architecture（路径占位）
-
-> 轻量精简版，裁剪自 [mattpocock/skills](https://github.com/mattpocock/skills) 的 improve-codebase-architecture（MIT License, Copyright (c) 2026 Matt Pocock）。若环境已安装同名完整 skill，请优先使用完整版。
-
-本 skill 只标出代码库架构改进的路线，不含完整流程。
-
-- **目标**：找出「深化模块」的机会（把浅模块变深），提升可测试性与 AI 可导航性。
-- **基础**：建立在领域模型与共享架构词汇（module / interface / depth / seam / adapter / leverage / locality）之上；领域术语来自 `CONTEXT.md`，决策记录在 `docs/adr/`。
-- **无完整流程时**：本技能包不提供扫描与 HTML 报告流程。若环境未安装完整 skill，而你需要术语或 ADR 支持，转 `domain-modeling`（未安装则见 `project-docs-workflow/references/deps/domain-modeling.md`）。

package/skills/project-docs-workflow/assets/templates/entries/pdr-current.md

@@ -1,19 +0,0 @@
-<!-- 文件名：04-current.md，位于模块根；现状快照（对照 01-spec.md 目标），收尾回顾时更新；≤1 页，只记结论与差距，不写流水账。 -->
-
-# <模块> 现状（Current）
-
-> 更新：YYYY-MM-DD ｜ 对照：01-spec.md
-
-## 进展概览
-
-- 已实现：<FR 或功能块，只记结论>
-- 部分实现：<…>
-- 未实现：<…>
-
-## 与目标的差距
-
-- <差距要点（对应 FR-<模块>-NN）>
-
-## 关键结论与已知问题
-
-- <结论 / 遗留；指向相关 issue / ADR>

package/skills/retro/SKILL.md

@@ -1,19 +0,0 @@
----
-name: retro
-description: 对编码会话或 agent 表现做回顾，输出针对 agent 环境的改进建议。
-disable-model-invocation: true
----
-
-# Retro（会话回顾）
-
-> 轻量精简版，裁剪自 [mattpocock/skills](https://github.com/mattpocock/skills) 的 retro（MIT License, Copyright (c) 2026 Matt Pocock）。若环境已安装同名完整 skill，请优先使用完整版。
-
-会话/agent 回顾的所有权属于本 skill；`project-docs-workflow` 第五步「回顾」只是文档同步，不做会话回顾。
-
-最小回顾至少覆盖三问：
-
-1. **发生了什么**：读指定会话的原始记录（未指定则默认当前会话），尽量取原始来源。
-2. **保留什么**：哪些做法或环境配置有效，值得延续。
-3. **改变什么**：给出针对 agent **环境**的改进候选（导航指针、自动化检查、编码规范、全局指令瘦身、工具经济性、多余指令、信息可达性），按严重程度排序呈现给用户。
-
-若环境未安装完整 skill，按 `project-docs-workflow/references/deps/boundaries.md` 的最小三问回顾执行。

package/skills/tdd/SKILL.md

@@ -1,50 +0,0 @@
----
-name: tdd
-description: 测试驱动开发。当用户想以测试先行方式构建功能或修 bug、提到 "red-green-refactor"、或需要集成测试时使用。
----
-
-# TDD（测试驱动开发）
-
-> 轻量精简版，裁剪自 [mattpocock/skills](https://github.com/mattpocock/skills) 的 tdd（MIT License, Copyright (c) 2026 Matt Pocock）。若环境已安装同名完整 skill，请优先使用完整版。
-
-TDD 就是 red → green 循环。本 skill 是让这个循环产出**值得保留**的测试的参考：什么算好测试、测试放哪里、反模式、以及循环的规则。每一节在**每个循环**都适用——在循环前和循环中都查阅，而不是事后。
-
-探索代码库时读 `CONTEXT.md`（若存在），让测试名与接口词汇匹配项目领域语言，并遵守所涉区域的 ADR。
-
-## 什么是好测试
-
-测试通过**公共接口**验证行为，而非实现细节。代码可以整个换掉，测试不应跟着变。好测试读起来像规格说明：「user can checkout with valid cart」准确告诉你存在什么能力，且因为不关心内部结构，能扛住重构。
-
-特征：测试用户/调用方真正关心的行为；只用公共 API；重构后仍存活；描述 WHAT 而非 HOW；每个测试一个逻辑断言。
-
-## Seam：测试放哪里
-
-**seam（接缝）** 是你据以测试的公共边界：无需伸手进内部即可观察行为的接口。测试住在 seam 上，绝不针对内部。
-
-- **只在事先约定的 seam 上测试。** 写任何测试前，先写下待测 seam 并与用户确认。未确认的 seam 上不写测试。你无法测试一切，事先约定 seam 才能把测试精力落在关键路径和复杂逻辑上，而不是每个边界情况。
-- 问：「公共接口是什么？我们该测哪些 seam？」
-
-当接口形状本身存疑（模块多深、seam 该在哪、接口暴露什么）时，调用 `codebase-design` skill 获取 module / interface / depth / seam / adapter / leverage / locality 的共享词汇；它是参考，不是要跑的一次会话。
-
-## 反模式
-
-- **耦合实现**：mock 内部协作者、测私有方法、或走旁路验证（绕过接口直接查数据库）。信号：重构后行为未变，测试却坏了。
-- **同义反复（tautological）**：断言以代码的算法重算期望值（`expect(add(a, b)).toBe(a + b)`、手工按同样方式推出的快照、常量自比），于是它只会通过、永远无法与代码唱反调。期望值必须来自独立真相源：已知良好的字面量、算好的例子、规格。
-- **横切切片**：先写完所有测试，再写所有实现。批量测试验证的是**想象中**的行为：测的是事物的**形状**而非面向用户的行为，测试对真实变化变得迟钝，且你在理解实现前就锁定了测试结构。改用**纵向切片**：一个测试 → 一个实现 → 重复，每个测试都是**曳光弹**，回应上一轮学到的东西。
-
-## 循环规则
-
-- **先红后绿。** 先写失败的测试，再只写刚好让它通过的代码。不要预判未来测试或加投机功能。
-- **一次一片。** 每个循环一个 seam、一个测试、一个最小实现。
-- **重构不属于循环。** 它属于评审阶段（见 `code-review` skill），不属于 red → green 实现循环。
-
-## 模拟（mock）
-
-**只在系统边界 mock**：外部 API（支付、邮件等）、数据库（有时——优先用测试库）、时间/随机性、文件系统（有时）。
-
-**不要 mock**：你自己的类/模块、内部协作者、任何你控制得了的东西。
-
-边界接口的设计要便于 mock：
-
-- **依赖注入**：把外部依赖传进来，而不是在内部创建。`processPayment(order, paymentClient)` 好过内部 `new StripeClient(...)`。
-- **优先 SDK 式接口而非通用 fetcher**：每个外部操作一个具体函数（`getUser` / `getOrders` / `createOrder`），而不是一个带条件逻辑的通用 `fetch`。这样每个 mock 只返回一种确定形状，测试准备里没有条件逻辑，也更容易看出测试覆盖了哪些端点。

package/skills/tdd/agents/openai.yaml

@@ -1,3 +0,0 @@
-interface:
-  display_name: "TDD"
-  short_description: "Test-driven red-green-refactor"