@netpilot/skills 0.3.2

package/skills/codebase-design/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: codebase-design
+description: 当新功能或重构需要确定模块边界、职责归属、依赖方向、公共接口、数据流和测试接缝时使用。它从行为与变更模式设计简单可演进的结构；单文件小改动或领域尚未澄清时不使用。
+---
+
+# Codebase Design
+
+从要支持的行为和未来最可能发生的变更出发设计代码位置。目标是让相关变化聚在一起，让不相关变化彼此隔离，而不是追求最多层次或最通用抽象。
+
+## 设计前检查
+
+1. 读取仓库规则、入口、目录结构、相邻实现、测试和依赖配置。
+2. 用具体场景列出要支持的行为、失败路径和非目标。
+3. 如果业务概念仍冲突，先调用 `domain-modeling`；如果关键技术能力未知，先调用 `research` 或 `prototype`。
+4. 识别现有约定。除非有可证明的收益，优先延续项目已经工作的结构。
+
+跨模块设计且宿主支持 custom agents 时，可以先让 `agent:code-reader` 只读绘制现状调用链，再让 `agent:architecture-designer` 独立比较候选边界。主 agent 仍负责统一事实、选择方案和向用户暴露真实取舍；agent 不可用或范围较小时，直接串行执行以下步骤。
+
+## 设计步骤
+
+### 1. 绘制变更地图
+
+列出各类变化可能触及的职责，例如业务规则、持久化、外部集成、界面、授权和观测。经常一起变化的职责可相邻，不应一起变化的职责要有边界。
+
+### 2. 分配所有权
+
+每项核心规则只指定一个权威位置。说明：
+
+- 哪个模块拥有状态和不变量；
+- 谁可以调用它；
+- 输入输出使用什么稳定契约；
+- 错误如何跨边界表达；
+- 哪些细节必须保持私有。
+
+### 3. 校验依赖方向
+
+依赖应指向更稳定、更接近业务规则的边界。框架、数据库和外部服务细节通过窄接口进入，不让领域规则依赖具体传输或存储形式。
+
+### 4. 设计测试接缝
+
+明确哪些行为由单元测试、集成测试、契约测试或端到端测试验证。接缝应来自真实边界，不为 mock 而制造层次。
+
+### 5. 对比替代方案
+
+至少记录一个更简单方案和一个主要替代方案。用当前需求、认知负担、迁移成本、故障隔离和可逆性解释选择。
+
+## 输出格式
+
+```markdown
+## 设计摘要
+- 行为与非目标：
+- 模块与职责：
+- 依赖方向：
+- 数据与控制流：
+- 公共契约：
+- 错误与失败边界：
+- 测试策略：
+- 替代方案与取舍：
+- 迁移步骤与回退：
+```
+
+复杂关系可以补充一张最小的流程图或依赖图；简单结构用表格或文字即可。
+
+## 完成标准
+
+- 每个关键行为和业务规则都有唯一、合理的归属。
+- 依赖方向、公共契约和失败边界清楚。
+- 设计与现有仓库约定兼容，或明确说明偏离理由。
+- 可以拆成小步、可验证、可回滚的实现切片。
+
+## 反模式
+
+- 不要为想象中的未来需求提前建立平台。
+- 不要按技术层机械拆分所有功能而忽略业务内聚。
+- 不要用共享工具模块掩盖所有权不清。
+- 不要在没有行为证据时引入新的框架或生产依赖。
+- 不要把目录树本身当作完整设计。
+- 不要把 `agent:architecture-designer` 的建议未经核验直接升级为架构决策或 ADR。

package/skills/codebase-design/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Codebase Design"
+  short_description: "从行为、职责与依赖出发设计清晰、简单且可演进的代码结构"
+  default_prompt: "请使用 $codebase-design 为当前需求设计模块边界、依赖方向和代码放置方案。"
+policy:
+  allow_implicit_invocation: true

package/skills/diagnosing-bugs/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: diagnosing-bugs
+description: 当出现复杂 bug、测试或构建失败、运行时异常、性能回退、偶发故障，且真实根因尚不明确时使用。它要求先可靠复现、收集证据并系统缩小范围，再给出根因；仅解释已知错误或执行明确修复时不使用。
+---
+
+# Diagnosing Bugs
+
+诊断的产物是有证据支持的根因，不是看起来可能有效的补丁。除非用户也要求修复，否则保持只读排查并报告结论。
+
+## 1. 定义故障
+
+记录预期行为、实际行为、首次出现时间、影响范围、环境和稳定复现步骤。区分：
+
+- 症状：用户或监控看到什么；
+- 触发条件：什么输入、状态或时序使它出现；
+- 根因：哪个机制违反了哪个不变量；
+- 影响：哪些用户、数据或路径受到波及。
+
+不要把错误消息直接当作根因。
+
+## 2. 建立可靠复现
+
+1. 使用最小输入重现故障，并保存准确命令和输出。
+2. 确认当前基线，检查相关代码、配置、依赖和近期变更。
+3. 若无法稳定复现，收集时间、并发、缓存、网络和环境差异，设计能区分假设的观测点。
+4. 涉及生产、敏感数据或外部写入时，先限定范围并获得必要授权；优先在隔离环境复现。
+
+## 3. 缩小范围
+
+沿实际数据流和控制流追踪，从故障边界向上游寻找第一个错误状态。使用：
+
+- 对照正常与异常样本；
+- 二分版本、输入、配置或执行阶段；
+- 定向日志、断言、调试器和最小测试；
+- 逐层验证接口前置条件与输出不变量；
+- 一次只改变一个变量的实验。
+
+先列少量可证伪假设，并为每个假设指定能支持或反驳它的观测。不要同时尝试多项修复。
+
+## 4. 证明根因
+
+根因结论至少应满足：
+
+- 能解释所有主要症状，而不只解释一条日志；
+- 能说明为何只在特定条件出现；
+- 移除或控制该机制后，复现行为按预测变化；
+- 与代码、配置、运行输出或版本历史中的证据一致。
+
+如果证据仍不足，明确写“尚未定位”，并列出下一项最高信息价值的检查。
+
+## 5. 形成修复路径
+
+用户要求修复时，先用 `tdd` 把最小复现转成失败回归测试，再修复造成错误状态的最早合理位置。验证原始复现、回归测试和受影响范围。不要只压制异常、增加重试或清空状态来掩盖机制问题。
+
+## 输出格式
+
+```markdown
+## 诊断结论
+- 现象与影响：
+- 复现步骤：
+- 根因：
+- 证据链：
+- 被排除的假设：
+- 建议修复：
+- 回归验证：
+- 剩余未知与风险：
+```
+
+## 完成标准
+
+- 故障可复现，或无法复现的原因与下一观测方案明确。
+- 根因有完整证据链并能预测故障条件。
+- 症状、触发条件和根因被清楚区分。
+- 如果实施修复，已有失败回归测试和修复后验证。
+
+## 反模式
+
+- 不要凭错误关键词直接改代码。
+- 不要随机升级依赖、增加延迟或反复重启来碰运气。
+- 不要在一次实验中改变多个变量。
+- 不要把“本地没复现”当作问题不存在。
+- 不要在未验证前声称问题已修复。

package/skills/diagnosing-bugs/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Diagnosing Bugs"
+  short_description: "系统复现、缩小故障范围并定位复杂问题背后的真实根因"
+  default_prompt: "请使用 $diagnosing-bugs 系统复现并定位这个问题，在确认根因前不要猜测修复。"
+policy:
+  allow_implicit_invocation: true

package/skills/domain-modeling/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: domain-modeling
+description: 当业务术语不统一、同名概念含义不同、对象边界和关系模糊，或核心业务规则难以放入清晰模型时使用。它建立统一语言、上下文、状态与不变量；纯技术结构设计或简单字段命名不单独使用。
+---
+
+# Domain Modeling
+
+建立一套业务人员、开发者和 AI 都能一致使用的领域语言。模型应服务于当前决策，不追求一次覆盖整个业务。
+
+## 建模流程
+
+1. **收集语言**：从需求、界面、代码、数据库、已有 `CONTEXT-MAP.md`、`CONTEXT.md`、ADR 和用户表述中提取名词、动作、状态和规则。
+2. **识别冲突**：找出同义多名、同名异义、技术名冒充业务概念和边界不清的词。
+3. **限定上下文**：说明每个概念在哪个业务上下文中成立；同一个词跨上下文含义不同是允许的，但必须显式映射。
+4. **描述行为**：优先用“谁基于什么规则执行什么动作并产生什么结果”建模，不只画数据结构。
+5. **提炼不变量**：记录任何有效状态都必须满足的业务规则、权限条件、唯一性和时间约束。
+6. **验证语言**：用真实场景、反例和边界案例让用户确认模型。
+
+独立使用且当前没有活跃访谈时，必要时调用 `grilling` 确认业务含义；如果由 `grill-with-docs` 调用，沿用当前访谈并在每个结论处理后返回控制权，不重新启动 `grilling`。建模完成后可调用 `codebase-design` 把领域边界映射到代码边界。
+
+## 建议产物
+
+### 术语表
+
+| 主名称 | 定义 | 不是什么 | 所属上下文 | 旧称/别名 |
+| --- | --- | --- | --- | --- |
+
+每个概念只选一个主名称。代码标识符可使用稳定的英文映射，但文档与沟通保持同一业务名称。
+
+### 行为与状态
+
+```markdown
+- Actor：谁发起？
+- Command：想做什么？
+- Preconditions：需要满足什么？
+- Invariants：始终不能被破坏什么？
+- State transition：状态如何变化？
+- Event：业务上发生了什么？
+- Failure：为什么可能被拒绝？
+```
+
+### 边界关系
+
+记录上下文间交换的业务含义、所有权和翻译规则。不要让共享数据库表或共享类型自动决定领域边界。
+
+## 更新项目知识
+
+只有写入当前仓库的领域文档已获授权时才落盘。先读取项目规则和既有格式，再按以下顺序处理：
+
+1. **确定上下文**：已有 `CONTEXT-MAP.md` 时按映射找到目标上下文；只有根目录 `CONTEXT.md` 时视为单上下文；两者都没有时，在第一个稳定术语确认后才懒创建根目录 `CONTEXT.md`。
+2. **对照证据**：用代码、现有文档和真实场景检查用户描述。发现冲突时展示证据并让用户裁决，不静默选择一方。
+3. **最小更新**：只修改承载当前已确认结论的最小片段。多上下文归属不清时先问，不新建一套平行文档结构。
+
+### CONTEXT.md 门禁
+
+- 只记录项目特有且已确认的领域语言，不记录通用编程概念。
+- 每个概念选择一个主名称，用一至两句定义“它是什么”，并列出应避免的别名。
+- 不写实现细节、规格、任务清单、会议纪要、偏好或待验证假设。
+
+### ADR 门禁
+
+只有决策已被明确接受，并同时满足以下条件时才提出 ADR：
+
+1. 后续改变成本明显，难以轻易回退；
+2. 缺少背景时，未来维护者会对当前选择感到意外；
+3. 存在真实替代方案，并基于具体取舍作出选择。
+
+创建前再次确认，遵循仓库现有目录、编号和格式。没有既有约定时使用 `docs/adr/NNNN-short-title.md`，用最短文字记录背景、选择和原因；可选方案、后果和状态只在确有价值时增加。已有相同决策时优先更新、废弃或建立 supersede 关系，不重复创建。
+
+## 完成标准
+
+- 冲突术语已收敛为一个主名称或明确的上下文差异。
+- 关键行为、状态变化和不变量能用真实示例解释。
+- 业务模型与数据库、API 或框架实现没有混为一谈。
+- 需要沉淀的稳定知识有明确落点。
+- 项目文档只包含获得授权且经过确认的内容，ADR 全部通过三项门禁。
+
+## 反模式
+
+- 不要从数据库表直接反推完整领域模型。
+- 不要为了使用模式而创造无业务意义的实体、聚合或事件。
+- 不要让同一概念在不同文档中继续使用多个主名称。
+- 不要把未确认的推断写进项目事实文件。
+- 不要把 `CONTEXT.md` 写成实现说明或访谈纪要。
+- 不要为容易撤销、没有真实替代方案或显而易见的选择创建 ADR。

package/skills/domain-modeling/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Domain Modeling"
+  short_description: "统一领域术语、概念边界、对象关系以及关键业务不变量"
+  default_prompt: "请使用 $domain-modeling 梳理当前领域概念、术语、关系和业务不变量。"
+policy:
+  allow_implicit_invocation: true

package/skills/grill/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: grill
+description: 当用户明确要求深入盘问，或路由器判断一项重要计划、产品设计、技术设计或关键决策需要挑战与确认时使用。它是默认不写项目文档的访谈入口，负责整理背景并调用 grilling；需要边访谈边维护 CONTEXT.md 或 ADR 时改用 grill-with-docs，普通小问题或已明确的执行任务不使用。
+---
+
+# Grill
+
+`grill` 是用户可直接调用、也可由路由器选择的深入访谈入口。它没有个人化角色设定，核心职责是为 `grilling` 准备上下文并启动访谈，默认只输出确认记录，不修改项目文档。
+
+## 启动前
+
+1. 明确本次要确认的决策对象，以及访谈结束后用户希望得到的产物。
+2. 读取用户提供的计划、规格、设计稿和仓库内直接相关的资料。不要询问文件中已经写明的事实。
+3. 提炼已知事实、当前假设、明显冲突和最高风险未知项。
+4. 调用同一套 skills 中的 `grilling`，把上述上下文作为访谈起点。Codex 使用 `$grilling`；Claude Code 的普通用户级 skill 使用 `/grilling`，插件安装模式使用 `/netpilot-skills:grilling`。
+
+如果任务尚未形成值得深入访谈的决策对象，先返回 `ask` 或 `wayfinder`，不要假装开始审查。
+如果用户明确要求把访谈中确认的术语和重要决策同步写入 `CONTEXT.md` 或 ADR，把控制权转交给 `grill-with-docs`，不要在本 skill 内临时增加写入模式。
+
+## 访谈范围
+
+优先覆盖会造成返工或不可逆影响的内容：
+
+- 用户与问题是否真实、边界是否清楚；
+- 成功指标和明确的非目标；
+- 关键业务规则、数据与权限边界；
+- 技术约束、集成点和失败模式；
+- 方案取舍、替代方案与可逆性；
+- 验收方式、发布策略和剩余风险。
+
+## 结束产物
+
+访谈结束后，输出一份紧凑的确认记录：
+
+- 已确认的事实与决策；
+- 被否定的选项及原因；
+- 仍未解决的问题与负责人；
+- 建议进入的下一 skill，通常是 `to-spec`、`research` 或 `prototype`。
+
+未经用户明确授权，不创建远程 issue、不修改外部系统，也不把访谈结论直接当成已批准规格。
+
+## 完成标准
+
+- 已把决策对象、背景和风险交给 `grilling` 逐题确认。
+- 关键决策有明确答案或被显式标记为未决。
+- 形成可供下一阶段使用的确认记录。
+
+## 反模式
+
+- 不要复制一套独立于 `grilling` 的访谈算法。
+- 不要在普通 `grill` 会话中静默创建或更新项目文档。
+- 不要一次发送十几个问题。
+- 不要只接受含糊回答而不追问影响。
+- 不要用对抗语气；挑战的是假设，不是用户。

package/skills/grill/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Grill"
+  short_description: "对重要计划、设计与关键决策进行一次一个问题的深入访谈"
+  default_prompt: "请使用 $grill 对当前重要决策进行逐题访谈，并在结束时总结确认结果。"
+policy:
+  allow_implicit_invocation: true

package/skills/grill-with-docs/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: grill-with-docs
+description: 当用户明确要求在深入访谈中同步维护当前仓库的 CONTEXT.md、领域术语文档或 ADR 时使用。它组合 grilling 与 domain-modeling，把已确认的语言和重要决策最小化沉淀；仅需访谈、仅需建模、没有项目仓库或尚未授权文档写入时不使用。
+---
+
+# Grill With Docs
+
+`grill-with-docs` 是带项目文档沉淀的访谈入口。它不实现第二套访谈算法，也不取代 `domain-modeling`；它只负责让两者在一个有明确写入边界的会话中协作。
+
+## 使用边界
+
+- 用户显式调用本 skill，或明确要求“边访谈边更新术语表、CONTEXT 或 ADR”时启动。
+- 用户只要求深入盘问、没有要求留下项目文档时，改用 `grill`。
+- 没有项目仓库、当前讨论尚未形成稳定知识，或目标只是编辑普通说明文档时，不使用本 skill。
+- 由 `ask` 或模型隐式推荐、但用户原始要求没有文档写入意图时，先保持只读，并在首次写入前确认目标文件与范围。
+
+用户显式调用 `$grill-with-docs`，可视为授权在当前仓库内最小化更新相关领域文档；这不授权修改代码、系统级目录、提交、推送、创建 PR 或写入远程系统。
+
+## 启动流程
+
+1. 读取项目规则、当前计划或设计、相关代码、已有 `CONTEXT-MAP.md`、`CONTEXT.md` 和 ADR。能通过只读检查确认的事实不要询问用户。
+2. 说明本次访谈的决策对象、预计维护的文档和明确不在范围内的文件。写入意图不明确时，只问一个范围问题。
+3. 判断当前主题属于哪个领域上下文。已有 `CONTEXT-MAP.md` 时遵循其映射；归属不清时先确认，不凭目录结构猜测。
+4. 启动 `grilling` 的逐题循环，同时应用 `domain-modeling` 的术语、边界、不变量和文档判断规则。
+
+## Skill 组合关系
+
+- `grilling` 是唯一访谈引擎：Codex 使用 `$grilling`；Claude Code 用户级安装使用 `/grilling`，插件安装使用 `/netpilot-skills:grilling`。
+- `domain-modeling` 是唯一领域文档能力：Codex 使用 `$domain-modeling`；Claude Code 用户级安装使用 `/domain-modeling`，插件安装使用 `/netpilot-skills:domain-modeling`。
+- 每个答案完成建模和必要的最小文档更新后，控制权回到当前 `grilling` 循环，再选择下一题。
+- 不再调用 `grill`，也不允许 `domain-modeling` 在已有活跃访谈时重新启动 `grilling`，避免双重访谈和循环调用。
+
+## 访谈与沉淀循环
+
+1. 由 `grilling` 选择当前最可能改变范围、模型或风险的一个问题。
+2. 将回答区分为事实、已确认决策、待验证假设和未决问题。
+3. 用现有术语表、ADR 和代码交叉检查回答。发现冲突时展示证据并让用户裁决，不静默覆盖项目事实。
+4. 术语已确认、所属上下文明确且属于领域语言时，立即对相应 `CONTEXT.md` 做最小更新；不要把多个结论积压到会话结束。
+5. 决策可能值得长期保留时，先检查 ADR 门禁。只有同时满足以下三项才提出创建或更新 ADR，并等待用户确认：
+   - 后续改变成本明显，难以轻易回退；
+   - 缺少背景时，未来维护者会对当前选择感到意外；
+   - 存在真实替代方案，并基于具体取舍选择了其中一个。
+6. 假设、临时偏好、容易撤销的实现细节和普通库选择只留在访谈记录中，不写成项目事实。
+7. 继续下一题，直到剩余未知项不再阻塞下一阶段，或必须转入 `research`、`prototype` 才能回答。
+
+## 文档规则
+
+- `CONTEXT.md` 只保存项目特有的领域语言：主名称、紧凑定义、所属上下文和应避免的别名。不得写实现细节、规格草稿、任务清单或未验证假设。
+- 单上下文项目在第一个稳定术语出现时才懒创建根目录 `CONTEXT.md`。多上下文项目遵循已有 `CONTEXT-MAP.md` 和各上下文位置；不要为了本次会话擅自重组文档体系。
+- ADR 遵循仓库现有目录、编号和格式。已有相同决策时优先更新、废弃或建立 supersede 关系，不重复创建。
+- 文档改动保持最小，并在每次写入后检查其是否准确表达刚刚确认的结论。
+
+## 结束产物
+
+会话结束时输出：
+
+- 已确认的领域术语、边界和重要决策；
+- 实际修改的文档及每项修改原因；
+- 未写入文档的假设和未决问题；
+- 建议进入的下一 skill，通常是 `to-spec`、`research` 或 `prototype`。
+
+## 完成标准
+
+- 访谈由 `grilling` 逐题推进，没有复制另一套提问循环。
+- 已确认术语与现有模型、代码和文档的冲突得到裁决。
+- `CONTEXT.md` 只包含稳定领域语言，ADR 全部满足门禁并获得确认。
+- 文档写入范围、实际改动和未决项均已明确报告。
+
+## 反模式
+
+- 不要因为仓库里存在 `CONTEXT.md` 就自动触发本 skill。
+- 不要把每个回答都写进文档，或把 `CONTEXT.md` 变成会议纪要。
+- 不要为容易撤销、没有替代方案或显而易见的选择创建 ADR。
+- 不要在同一会话中递归启动 `grill`、第二个 `grilling` 或另一个 `grill-with-docs`。
+- 不要把显式文档写入授权扩展成代码修改或远程发布授权。

package/skills/grill-with-docs/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Grill With Docs"
+  short_description: "在逐题访谈中收敛领域术语，并按门禁更新 CONTEXT.md 与 ADR"
+  default_prompt: "请使用 $grill-with-docs 深入检验这个方案，并把已确认术语与关键决策沉淀到项目文档。"
+policy:
+  allow_implicit_invocation: true

package/skills/grilling/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: grilling
+description: 当另一项 skill 需要通过自适应、一次一个问题的访谈来消除需求歧义，确认边界、约束、取舍和验收标准时使用。它是可复用的内部访谈引擎；不要作为普通问答、头脑风暴或简单任务的默认入口。
+---
+
+# Grilling
+
+通过高信息密度的逐题访谈，把“听起来合理”推进到“决策足以执行”。语气应直接、尊重并保持合作。
+
+## 访谈循环
+
+1. **建立状态**：整理已知事实、假设、决策、未知项和矛盾。优先读取现有资料。
+2. **选择问题**：挑选当前最可能改变范围、方案或风险的一个未知项。
+3. **提出一题**：一次只问一个问题。适合时给出 2 至 3 个互斥选项，说明推荐项和主要取舍；不要限制用户自由回答。
+4. **检验答案**：把回答转成明确决策，并检查它是否与先前答案冲突、是否留下模糊词或不可验证目标。
+5. **自适应推进**：根据新信息选择下一题，而不是照搬固定清单。
+6. **停止**：当剩余未知项不会阻塞下一阶段，或必须依赖研究、原型、外部权限才能解决时，结束访谈。
+
+## 提问原则
+
+- 先问影响最大的分叉，不先问装饰性偏好。
+- 将“快速”“灵活”“企业级”“体验好”等词转成可观察的标准。
+- 发现隐含前提时明确指出，并询问前提不成立时的处理方式。
+- 对高成本、不可逆、安全或数据相关决策，要求说明失败路径和回滚方式。
+- 用户说“不确定”时，提供最小研究或原型建议，不施压猜答案。
+- 能通过只读检查确认的事实，直接检查并展示证据。
+
+## 状态记录
+
+在内部维护以下列表，必要时向用户回顾：
+
+- `Facts`：已有证据支持的事实；
+- `Decisions`：用户已确认的选择；
+- `Assumptions`：暂时采用、仍需验证的前提；
+- `Open questions`：尚未解决的问题；
+- `Risks`：失败影响与缓解方式。
+
+不要在每轮都重复完整列表；只在发生冲突、阶段转换或访谈结束时汇总。
+
+## 结束格式
+
+```markdown
+## 访谈结论
+- 目标：
+- 范围内：
+- 范围外：
+- 关键决策：
+- 验收标准：
+- 待验证假设：
+- 剩余风险：
+- 建议下一步：
+```
+
+## 完成标准
+
+- 目标、范围、关键约束和验收方式足以支持下一阶段。
+- 决策、假设和事实没有混写。
+- 未决项都有明确的验证方式或负责人。
+
+## 反模式
+
+- 不要并排发送多题或隐藏问题清单。
+- 不要问已经能从资料中得到答案的问题。
+- 不要为了显得深入而无止境追问。
+- 不要在访谈中直接实施未批准的方案。
+- 不要把自己的偏好包装成用户已经作出的决定。

package/skills/grilling/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Grilling"
+  short_description: "通过自适应追问消除需求歧义并确认边界、约束与验收标准"
+  default_prompt: "请使用 $grilling 逐题澄清当前需求，直到关键决策和验收标准都明确。"
+policy:
+  allow_implicit_invocation: true

package/skills/handoff/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: handoff
+description: 当工作需要跨会话、上下文压缩、工具切换、agent 切换或交给人工继续，且必须保留可靠恢复点时使用。它汇总目标、状态、证据、改动和下一步；普通阶段性进度更新或已经完整结束的任务不使用。
+---
+
+# Handoff
+
+生成一份接手者无需重做调查即可继续工作的交接包。它应记录事实和证据，而不是复述整段对话。
+
+## 收集状态
+
+在交接前进行只读检查：
+
+- 当前目标、范围和完成标准；
+- 已确认的决策、约束和项目规则；
+- 已完成、进行中、未开始和被阻塞的工作；
+- 当前分支、工作树状态和本任务涉及文件；
+- 实际运行过的命令、测试与结果；
+- 关键日志、错误、复现步骤和证据位置；
+- 仍未解决的问题、风险与所需授权。
+
+不要把计划中的命令写成已经执行，不要遗漏用户已有的未提交改动。
+
+## 交接格式
+
+```markdown
+# 工作交接
+
+## 目标与完成标准
+## 当前状态
+- 已完成：
+- 进行中：
+- 未开始：
+- 阻塞项：
+
+## 关键决策与约束
+## 相关文件与改动
+## 验证证据
+| 命令/检查 | 结果 | 说明 |
+
+## 已排除的路径
+## 剩余风险与未知项
+## 下一步
+1. 第一条可直接执行的动作
+2. 后续动作
+
+## 恢复提示
+```
+
+`恢复提示` 应包含接手者必须读取的文件、第一条命令和禁止重复或覆盖的工作。路径、分支、版本和错误信息应精确。
+
+## 安全与体积
+
+- 不记录密钥、token、个人数据或完整敏感日志；使用安全位置的引用。
+- 不粘贴可从文件读取的大段内容，提供路径和关键行即可。
+- 若工作树含用户改动，明确标记归属和重叠风险。
+- 交接本身不授权 commit、push、部署或外部写入。
+
+## 完成标准
+
+- 新接手者能从一条明确动作继续，而无需重新探索核心上下文。
+- 已执行事实、计划和推断清楚分开。
+- 文件、命令、验证结果和阻塞条件可定位。
+- 敏感信息未进入交接内容。
+
+## 反模式
+
+- 不要只写“继续完成剩余工作”。
+- 不要粘贴完整聊天记录代替提炼。
+- 不要虚构测试、提交或远程状态。
+- 不要遗漏失败尝试及其教训，导致接手者重复踩坑。
+- 不要在任务已完全结束时制造无意义交接文档。

package/skills/handoff/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Handoff"
+  short_description: "为跨会话、跨工具或人工接手生成完整、可恢复的工作交接包"
+  default_prompt: "请使用 $handoff 总结当前状态、证据、未决事项和下一步，生成可直接继续的交接包。"
+policy:
+  allow_implicit_invocation: true

package/skills/implement/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: implement
+description: 当用户已经提供或批准了明确规格、任务边界与验收标准，并要求实际修改代码或项目文件时使用。它按小切片实施、持续验证并报告偏差；探索、只读分析、根因未知的 bug 或尚未批准的设计不使用。
+---
+
+# Implement
+
+按已确认的范围交付最小、正确、可验证的改动。实施不是重新发明规格；发现重大偏差时停止并让决策回到用户。
+
+## 开始前
+
+1. 读取仓库规则、规格、当前任务、相邻实现和测试命令。
+2. 检查工作树，区分用户已有改动与本任务范围。保留无关改动，重叠且无法安全处理时报告。
+3. 确认验收标准和允许的写入范围。认证、权限、支付、数据迁移、部署、安全等高风险内容必须先有计划。
+4. 若行为或架构仍有关键歧义，返回 `to-spec` 或 `codebase-design`；若 bug 根因未知，先用 `diagnosing-bugs`。
+
+## 实施循环
+
+对每个最小垂直切片：
+
+1. 说明当前要实现的可观察结果。
+2. 适用时调用 `tdd`，先建立可信失败测试。
+3. 只修改实现该结果必须修改的文件，不做无关重构。
+4. 运行最小定向验证，确认失败或通过的原因符合预期。
+5. 在绿色状态整理局部结构，再运行受影响范围验证。
+6. 检查 diff，确认没有意外文件、调试代码、敏感信息或范围漂移。
+7. 更新任务状态并进入下一切片。
+
+优先使用仓库现有依赖和模式。新增生产依赖前说明必要性、替代方案、维护与安全影响，并获得用户同意。
+
+## 偏差处理
+
+可以自行处理不改变目标的局部实现细节。以下情况必须暂停并说明证据、影响与选项：
+
+- 规格与现有系统事实冲突；
+- 需要改变公共 API、schema、权限、数据或部署策略；
+- 必须扩大范围或引入新生产依赖；
+- 验收标准无法在当前环境验证；
+- 用户已有改动与任务目标直接冲突。
+
+不要悄悄把推断升级为新需求。
+
+## 外部操作
+
+本 skill 不默认执行 commit、push、创建 PR、部署、发布、合并、关闭远程 issue 或修改外部系统。只有用户明确授权相应动作后才执行；授权实施代码不等于授权这些外部操作。
+
+## 交付检查
+
+- 运行与风险成比例的定向测试、类型检查、构建或端到端验证。
+- 宿主提供 `agent:test-verifier` 且验证命令边界清楚时，可以委派它执行现有检查并压缩日志；主 agent 必须核对实际命令、退出码和工作树，不能把子代理摘要本身当成通过证据。
+- 调用 `code-review` 对中大型改动进行独立审查；轻量改动至少自查 diff。
+- 如实记录未运行或失败的验证及原因，不用“应该通过”替代证据。
+- 说明改动摘要、关键文件、设计取舍、验证结果和剩余风险。
+
+## 完成标准
+
+- 所有已批准验收标准都有实现与验证证据。
+- 改动限于任务所需范围，用户已有工作被保留。
+- 没有未解释的测试失败、意外文件或隐藏偏差。
+- 外部可见动作只在明确授权范围内执行。
+
+## 反模式
+
+- 不要在规格仍模糊时边写边替用户做重大决策。
+- 不要为了顺手优化而扩大重构。
+- 不要删除测试、弱化断言或绕过检查来获得绿色结果。
+- 不要把未执行的验证报告为通过。
+- 不要默认提交、推送或关闭任务。

package/skills/implement/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Implement"
+  short_description: "按已确认规格和任务边界实现功能，并持续验证和报告偏差"
+  default_prompt: "请使用 $implement 按当前规格实施任务，持续验证，并在偏离规格前先报告。"
+policy:
+  allow_implicit_invocation: true