@netpilot/skills 0.3.2

package/skills/prototype/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: prototype
+description: 当关键技术、集成、性能或体验假设不能仅靠讨论和文档确认，需要用最小可运行实验快速获得证据时使用。原型用于学习和淘汰风险，不等同于生产实现；低风险且行为已明确的任务不使用。
+---
+
+# Prototype
+
+构建最小可验证原型（minimum viable experiment），用运行证据回答一个重要问题。默认把原型视为一次性研究资产，除非后续明确批准产品化。
+
+## 先写实验卡
+
+在写代码前记录：
+
+```markdown
+- 决策：这个结果将支持什么选择？
+- 假设：我们认为会发生什么？
+- 反证：什么结果会证明假设不成立？
+- 指标：观察什么，阈值是多少？
+- 边界：本实验刻意不覆盖什么？
+- 时限：何时停止？
+- 环境：版本、数据、硬件和依赖条件。
+```
+
+没有明确反证条件的原型容易变成演示项目，应先补齐实验定义。
+
+## 构建原则
+
+1. 只实现产生关键证据所需的最短端到端路径。
+2. 优先使用隔离目录、测试夹具、模拟数据和可重复命令，不污染正式代码与用户环境。
+3. 固定会影响结果的版本和配置，记录环境差异。
+4. 保留必要的日志、测量和失败输出，使其他人能够复核。
+5. 不为原型补齐生产级抽象、兼容层、部署、监控或界面细节，除非它们正是待验证对象。
+6. 新增生产依赖、使用真实凭证、访问生产数据或执行外部写入前，必须获得明确授权。
+
+如果验证目标是业务行为，调用 `tdd` 建立失败测试；如果根因未知，先调用 `diagnosing-bugs`。
+
+## 运行与判断
+
+- 至少执行一次可重复的验证，记录命令、输入和结果。
+- 同时记录支持与反驳假设的证据。
+- 结果受环境或样本限制时，不外推到未测试范围。
+- 若原型未回答问题，说明实验设计为何失效，并决定缩小、改写或停止，不用追加功能掩盖失败。
+
+## 交付格式
+
+```markdown
+## 原型结论
+- 假设：
+- 结果：支持 / 反驳 / 不确定
+- 证据：
+- 适用边界：
+- 原型代码位置：
+- 复现方式：
+- 是否建议产品化：
+- 产品化前必须补齐：
+```
+
+## 完成标准
+
+- 原型回答了一个明确、重要且可证伪的问题。
+- 结果可复现，环境和限制已记录。
+- 明确区分实验代码与生产实现。
+- 结论能触发继续、换路或停止中的一个决策。
+
+## 反模式
+
+- 不要把“能跑起来”自动解释为方案可用。
+- 不要在原型阶段提前建设通用平台。
+- 不要隐藏失败结果或只展示最佳一次运行。
+- 不要未经批准把原型直接合入生产路径。
+- 不要使用真实敏感数据来换取方便。

package/skills/prototype/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Prototype"
+  short_description: "用最小可验证原型快速检验高风险技术假设与方案可行性"
+  default_prompt: "请使用 $prototype 设计并实现一个最小验证，用证据判断核心假设是否成立。"
+policy:
+  allow_implicit_invocation: true

package/skills/research/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: research
+description: 当任务依赖陌生技术、快速变化的事实、候选方案比较或用户明确要求调研与核验时使用。它把问题拆成可证伪的研究项，优先使用一手资料并区分事实、推断和未知；单纯代码阅读或已有可靠答案时不使用。
+---
+
+# Research
+
+研究的目标是降低决策不确定性，而不是收集尽可能多的链接。
+
+## 定义研究任务
+
+开始前明确：
+
+- 要支持的具体决策；
+- 必须回答的 1 至 5 个问题；
+- 时间、版本、平台、预算等适用边界；
+- 什么证据足以改变当前方案；
+- 何时停止研究并进入验证或实施。
+
+如果问题过大，先调用 `wayfinder`；如果需求本身不清楚，先调用 `grilling`。
+
+## 证据优先级
+
+按以下顺序寻找证据：
+
+1. 当前仓库代码、配置、测试和可复现运行结果；
+2. 官方文档、规范、源代码、发布说明和维护者声明；
+3. 原始论文、数据集或厂商技术资料；
+4. 高质量二手分析，仅用于补充解释或发现线索；
+5. 社区帖子与搜索摘要，只能作为待核验线索。
+
+技术问题优先依赖官方文档和原始资料。涉及当前版本、价格、规则、安全或其他可能变化的信息时，必须联网核验日期和版本。不要把搜索结果摘要当作证据。
+
+## 执行方式
+
+1. 把问题拆成互不重叠的研究项，可并行时分配给只读子代理。
+2. 为每个关键主张记录来源、发布日期或版本、适用范围和可信度。
+3. 交叉核对重要结论。来源冲突时展示冲突，不用多数票代替判断。
+4. 对候选方案使用一致维度比较，例如能力、约束、成熟度、运维成本、迁移成本和退出路径。
+5. 遇到只能通过运行确认的行为，转交 `prototype`，不要从文档继续推测。
+
+并行研究时，主 agent 负责统一问题、去重、核验引用并形成最终判断；子代理结论不能直接当成事实。
+
+## 输出格式
+
+```markdown
+## 研究结论
+- 要支持的决策：
+- 建议：
+- 置信度与适用边界：
+
+## 关键证据
+| 主张 | 类型（事实/推断） | 证据 | 日期或版本 | 限制 |
+
+## 候选方案
+| 方案 | 优势 | 代价 | 主要风险 | 适用条件 |
+
+## 未知项与验证方式
+## 建议下一步
+```
+
+引用应尽量靠近它所支持的主张。清楚标记自己的推断，不制造来源未明确表达的确定性。
+
+## 完成标准
+
+- 每个核心问题都有答案、证据或明确的未知标记。
+- 推荐结论与决策维度直接对应，并包含适用边界。
+- 时间敏感信息已核验日期和版本。
+- 需要运行验证的部分已形成最小原型建议。
+
+## 反模式
+
+- 不要用链接数量代表研究质量。
+- 不要引用搜索摘要、AI 摘要或无来源转述作为最终证据。
+- 不要忽略与偏好方案相冲突的证据。
+- 不要无限研究；达到停止条件后进入决策或原型。
+- 不要未经验证执行网上获得的高风险命令或脚本。

package/skills/research/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Research"
+  short_description: "基于一手资料并行研究陌生技术、候选方案与关键事实证据"
+  default_prompt: "请使用 $research 调查当前问题，优先核验一手资料并给出带证据的结论。"
+policy:
+  allow_implicit_invocation: true

package/skills/tdd/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: tdd
+description: 当实现可观察的行为变更、核心业务逻辑、复杂条件、bug 回归或需要安全重构时使用。它严格执行红灯、绿灯、重构的小步循环并保留证据；纯文档、机械配置或没有可测试行为的改动不强制使用。
+---
+
+# Test-Driven Development
+
+测试驱动开发（TDD）用失败测试定义下一个行为，再用最小实现满足它。测试不是事后装饰，而是实现边界和回归证据。
+
+## 开始前
+
+1. 读取项目测试约定和相邻测试，使用现有框架与命令。
+2. 把需求转成一个可观察行为，包括输入、结果和失败条件。
+3. 选择能证明行为的最低测试层级。业务规则优先单元或集成测试，跨边界行为才使用端到端测试。
+4. bugfix 先用 `diagnosing-bugs` 确认根因和复现路径，再把复现转成回归测试。
+
+## 循环
+
+### 1. Red：建立可信失败
+
+- 一次只写一个最小测试。
+- 运行测试并确认它因“目标行为尚未实现”而失败。
+- 若测试意外通过，说明它没有覆盖新行为，先修正测试。
+- 若因环境、语法或夹具错误失败，先修复测试基础，不能把它算作红灯证据。
+
+### 2. Green：最小实现
+
+- 只写让当前失败测试通过所需的生产代码。
+- 不顺手实现下一项行为，不提前抽象。
+- 运行目标测试，再运行受影响范围的相关测试。
+
+### 3. Refactor：在绿色状态整理
+
+- 消除重复、改善命名和结构，但不改变外部行为。
+- 每个小改动后重跑相关测试。
+- 只有观察到真实重复或职责边界后才抽象。
+
+然后为下一个行为重复循环。
+
+## 测试质量
+
+- 测试公共行为和业务结果，避免绑定私有实现细节。
+- 测试名表达场景与结果，不只重复函数名。
+- 每个失败应能指出哪个规则被破坏。
+- 覆盖正常路径、关键边界和有业务意义的失败路径。
+- mock 只用于真实外部边界；能用稳定的内存实现或集成测试时，不滥用交互断言。
+- 时间、随机、并发等非确定因素应显式控制。
+
+## 验证记录
+
+交付时记录：
+
+- 首个失败测试和失败原因；
+- 使它通过的行为实现；
+- 执行过的定向测试与更广验证；
+- 未执行的验证及原因。
+
+## 完成标准
+
+- 每个新增或修复行为都有先失败、后通过的测试证据。
+- 目标测试和相关回归测试通过。
+- 重构没有改变范围外行为。
+- 未通过删除测试、弱化断言、跳过类型检查或隐藏失败来获得绿色结果。
+
+## 反模式
+
+- 不要先写完整实现再补一个会通过的测试并称为 TDD。
+- 不要一次写大量测试后才运行。
+- 不要测试框架本身或私有调用顺序。
+- 不要为了容易测试而改变正确的业务契约。
+- 不要把当前环境无法运行的测试报告为已通过。

package/skills/tdd/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "TDD"
+  short_description: "以失败测试驱动行为实现、回归保护以及安全的小步重构"
+  default_prompt: "请使用 $tdd 先建立可观察的失败测试，再用最小实现使其通过并安全重构。"
+policy:
+  allow_implicit_invocation: true

package/skills/teach/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: teach
+description: 当用户明确要在专用目录中开始或继续一个跨会话学习项目，并希望用可信资料、短课程、练习和学习记录持续提升时使用。一次性解释、普通技术调研、代码库熟悉或直接项目实现不使用。
+---
+
+# Teach
+
+把一个经用户确认的目录作为长期学习工作区。围绕具体目标安排小步课程、练习、反馈和间隔复习，并用文件保存跨会话状态。
+
+## 权限与边界
+
+- 只有用户明确表达长期学习意图，或明确调用 `$teach` 时才启动。
+- 写入前确认教学工作区路径。当前目录是业务代码仓库且尚无教学状态时，推荐建立独立目录，不要直接污染项目根目录。
+- 明确调用只授权在已确认工作区内维护下列教学文件，不授权修改业务代码、项目配置、宿主设置、Git 状态或远程资源。
+- 一次性概念解释直接回答；需要核验技术事实但不建立学习工作区时使用 `research`；要完成工程任务时返回相应工程工作流。
+
+## 教学工作区
+
+按需创建文件，不要预先生成空目录：
+
+- `MISSION.md`：学习动机、可观察成功标准、约束和非目标。创建或修订时读取 [mission-format.md](references/mission-format.md)。
+- `RESOURCES.md`：经筛选并带用途说明的可信资料。创建或修订时读取 [resources-format.md](references/resources-format.md)。
+- `GLOSSARY.md`：用户已经理解并能正确使用的统一术语。需要维护时读取 [glossary-format.md](references/glossary-format.md)。
+- `lessons/NNNN-*.html`：每次一个目标、可快速完成的自包含课程。
+- `reference/*`：可重复查阅的速查表、示例、流程图或术语资料；默认使用适合内容的 HTML 或 Markdown。
+- `learning-records/NNNN-*.md`：已经有证据表明用户掌握的关键知识。写入时读取 [learning-record-format.md](references/learning-record-format.md)。
+- `assets/*`：至少会被两个课程复用的样式、测验或模拟组件。
+- `NOTES.md`：稳定的教学偏好、约束和必要工作笔记；不要写成逐次聊天日志。
+
+一个工作区只服务一个主学习目标。无关主题使用另一个目录。
+
+## 工作流
+
+1. 读取已有的 `MISSION.md`、`RESOURCES.md`、`GLOSSARY.md`、学习记录、近期课程和必要笔记，恢复当前状态。
+2. 如果目标不具体，一次只问一个问题；需要系统访谈时调用 `grilling`，由它返回目标、成功标准、约束和已知基础后继续本流程。
+3. 通过短诊断、回忆题或小任务判断用户当前基础和最近发展区。不要只依据“我看懂了”判断掌握。
+4. 资源不足、事实可能变化或用户要求核验时，调用 `research` 完成一个有停止条件的研究项；接收其带来源结论并筛选进 `RESOURCES.md`。不要把搜索摘要或模型记忆当作事实依据。
+5. 只设计下一节最小课程：给出单一学习目标、必要知识、一个主动练习、即时反馈方式和可信来源。优先让用户检索、应用和解释，而不是继续阅读。
+6. 用户完成练习后检查证据。只有能够正确回忆、应用或迁移时，才更新学习记录或术语表；“已经讲过”不等于“已经学会”。
+7. 给出本次收获、仍不稳固之处、建议复习时间和下一节候选目标。不要一次生成完整课程体系。
+
+调用关系必须保持单向：`teach` 可以调用 `grilling` 或 `research`，它们返回访谈结果或证据后由原流程继续；被调用 skill 不得重新启动新的 `teach`。
+
+## 课程设计
+
+- 每节课程只追求一个可观察的小胜利，并直接服务 `MISSION.md`。
+- 知识讲解降低无关难度；技能练习增加适度的检索难度，并提供尽可能短的反馈回路。
+- 通过间隔复习和相关主题交错提升长期保持，不用当下答题流畅度冒充长期掌握。
+- 选择题不得通过选项长度、格式或措辞泄露答案。
+- 课程引用尽量链接到官方文档、规范、论文、原始数据或公认的一手材料；推断和经验判断要明确标注。
+- HTML 课程应可访问、响应式、可打印并复用已有资产。只有产生第二个真实复用点时才抽取新组件。
+- 只返回课程文件路径；仅在用户要求时打开浏览器或其他应用。
+
+## 完成标准
+
+- 已确认工作区、学习目标和当前基础。
+- 本次课程只有一个清楚目标，并包含主动练习、反馈方式和可信来源。
+- 学习状态只依据真实证据最小更新，没有把覆盖内容当成掌握。
+- 用户知道本次结果、建议复习时间和下一步。
+
+## 反模式
+
+- 不要在普通代码仓库根目录未经确认地创建一组教学文件。
+- 不要依靠模型记忆编造课程事实或引用。
+- 不要把课程做成长篇百科、完整训练营或华而不实的页面。
+- 不要因为用户读过或听过就写入学习记录或术语表。
+- 不要自动加入社区、发帖、联系他人、购买课程或打开外部应用。
+- 不要让教学工作流修改业务代码、提交、推送或代替工程交付流程。

package/skills/teach/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Teach"
+  short_description: "建立可信资料驱动的跨会话学习工作区，用短课程与练习持续推进"
+  default_prompt: "请使用 $teach 在专用目录中建立跨会话学习工作区，并从我的目标设计第一课。"
+policy:
+  allow_implicit_invocation: true

package/skills/teach/references/glossary-format.md

@@ -0,0 +1,21 @@
+# `GLOSSARY.md` 格式
+
+`GLOSSARY.md` 保存用户已经理解的统一术语，而不是待背诵的外部词典。
+
+```markdown
+# {主题} Glossary
+
+## Terms
+
+**{主术语}**：
+{一至两句准确、紧凑的定义。}
+_避免使用_：{容易混淆的别名，如有}
+```
+
+规则：
+
+- 只有用户能正确解释或使用术语后才收录。
+- 同一概念选择一个主名称，把其他叫法标为应避免别名。
+- 定义说明“它是什么”，保持一至两句；需要教程时链接课程或参考资料。
+- 已收录术语应在后续课程和记录中保持一致。
+- 理解加深时原位修订，并在存在实质认知变化时补充学习记录。

package/skills/teach/references/learning-record-format.md

@@ -0,0 +1,18 @@
+# 学习记录格式
+
+学习记录位于 `learning-records/`，使用 `0001-slug.md`、`0002-slug.md` 的连续编号。仅在出现第一条合格记录时创建目录。
+
+```markdown
+# {已经掌握或修正的关键认识}
+
+{1 至 3 句说明用户展示了什么理解、证据是什么，以及它如何改变后续教学。}
+```
+
+满足以下任一条件才记录：
+
+1. 用户能正确回忆、应用或迁移一个非平凡概念。
+2. 用户说明已有基础，并提供了足以判断深度的证据。
+3. 一个重要误解已经通过练习被纠正。
+4. 学习结果使目标发生变化，且用户已确认修订 `MISSION.md`。
+
+不要记录仅仅讲过的内容、重复的术语定义或逐次会话流水账。后来的证据推翻旧记录时，标记旧记录被新编号取代，不要删除学习轨迹。

package/skills/teach/references/mission-format.md

@@ -0,0 +1,28 @@
+# `MISSION.md` 格式
+
+`MISSION.md` 位于教学工作区根目录，说明为什么学习以及什么结果才算成功。所有课程、资料和练习都应能追溯到它。
+
+```markdown
+# Mission: {主题}
+
+## Why
+{1 至 3 句具体说明：掌握后，工作或生活会发生什么可观察变化。}
+
+## Success looks like
+- {用户能够完成的具体行为}
+- {另一项可观察结果}
+
+## Constraints
+- {时间、预算、基础、可用工具或学习偏好}
+
+## Out of scope
+- {当前明确不学习的相邻主题}
+```
+
+规则：
+
+- 一个工作区只保留一个主目标。
+- 用“完成某事”替代“了解某物”。
+- 目标不具体时先访谈，不要用假设填空。
+- 现实目标变化时先向用户确认，再修订文件并记录原因。
+- 保持在一屏左右；它是方向标，不是完整学习计划。

package/skills/teach/references/resources-format.md

@@ -0,0 +1,28 @@
+# `RESOURCES.md` 格式
+
+`RESOURCES.md` 保存经过筛选的可信资料以及可选的真实实践社区。课程中的事实性知识优先来自这里。
+
+```markdown
+# {主题} Resources
+
+## Knowledge
+
+- [{资料标题} — {作者或机构}]({URL})
+  适用：{它回答什么问题，何时使用}。版本或日期：{如适用}。
+
+## Practice and community
+
+- [{社区、课程或实践场所}]({URL})
+  适用：{能够获得什么真实反馈}。
+
+## Gaps
+- {当前缺少可靠资料的问题}
+```
+
+规则：
+
+- 优先官方文档、规范、原始论文、数据、维护者声明和公认专业资料。
+- 每条都写清用途；无注释链接不进入清单。
+- 标注版本、日期和适用边界，区分事实、推断与经验。
+- 发现资料错误、过时或偏离目标时删除或替换，不用数量掩盖质量。
+- 社区仅作建议；记录用户拒绝参与的偏好，不重复推动。

package/skills/to-spec/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: to-spec
+description: 当需求、访谈或研究结论已经基本明确，需要整理成范围清楚、决策完整、可实现且可验收的规格时使用。它消除剩余歧义并定义行为与边界；探索阶段的大想法或已经存在合格规格时不使用。
+---
+
+# To Spec
+
+把已确认的意图转换成实现团队和 AI 可以独立执行的规格（specification）。规格描述问题、行为和约束，不预写未经论证的代码实现。
+
+## 输入门禁
+
+先确认已有：目标用户或调用方、要解决的问题、范围、主要约束和成功信号。缺少会改变方案的信息时调用 `grilling`；方向仍模糊时返回 `wayfinder`；事实或可行性未知时调用 `research` 或 `prototype`。
+
+读取仓库中的规则、相邻功能、领域文档和现有接口，避免规格与实际系统脱节。
+
+## 编写规格
+
+使用与项目匹配的结构，至少包含：
+
+```markdown
+# 标题
+## 背景与问题
+## 目标与成功指标
+## 范围内
+## 范围外
+## 用户或系统场景
+## 功能需求
+## 业务规则与不变量
+## 数据、接口与状态变化
+## 错误与边界情况
+## 权限、安全、隐私与审计影响
+## 兼容、迁移与回退
+## 可观测性与运维要求
+## 验收标准
+## 未决问题
+```
+
+与任务无关的章节可以标记“不适用”并说明原因，不要填充空泛模板文字。
+
+## 写作规则
+
+- 每项需求使用可观察、可验证的语言，避免“快速”“友好”“智能”等未定义形容词。
+- 清楚区分事实、已批准决策、暂定假设和未决问题。
+- 用 Given/When/Then 或等价场景描述关键行为，包括失败和边界路径。
+- 公共 API、schema、权限、计费、迁移、部署等高风险变更要明确兼容和回退策略。
+- 只包含当前范围需要的设计约束。代码结构由 `codebase-design` 负责，任务拆分由 `to-tickets` 负责。
+- 发现现有行为与目标冲突时，展示证据并请求决策，不悄悄选择一方。
+
+## 验收标准检查
+
+每条验收标准都应：
+
+- 能由测试、可观察运行结果或人工验收直接判断；
+- 包含必要前置条件和预期结果；
+- 不依赖“实现得合理”之类主观判断；
+- 覆盖至少一个关键失败或边界场景；
+- 能追溯到某项目标或业务规则。
+
+## 交付
+
+默认在回答中给出规格，或写入用户指定/项目约定的本地文档位置。未经明确授权，不创建远程文档、issue 或项目任务。
+
+## 完成标准
+
+- 目标、范围、非目标和验收标准一致且可追溯。
+- 关键业务规则、状态、失败路径和风险边界已定义。
+- 未决问题不阻塞拆票；若阻塞，明确指出并停止进入 `to-tickets`。
+- 规格足以让另一位执行者在不猜核心决策的情况下实施。
+
+## 反模式
+
+- 不要把会议纪要重新排版后称为规格。
+- 不要隐藏未决问题或把假设写成要求。
+- 不要把具体文件改动列表冒充产品行为。
+- 不要在规格中提前锁定没有证据的复杂架构。
+- 不要用大而模糊的“完成所有功能”作为验收标准。

package/skills/to-spec/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "To Spec"
+  short_description: "将已澄清需求整理为范围明确、决策完整且可验收的实现规格"
+  default_prompt: "请使用 $to-spec 把当前讨论整理成可实现、可审查且有验收标准的规格。"
+policy:
+  allow_implicit_invocation: true

package/skills/to-tickets/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: to-tickets
+description: 当已有经过确认且不存在关键阻塞问题的规格，需要拆成可独立交付、可验证和可排序的垂直任务时使用。它建立依赖关系与完成证据；需求仍在探索、只有模糊想法或用户只要高层路线时不使用。
+---
+
+# To Tickets
+
+把规格拆成小而完整的价值切片。每个任务应让执行者知道为什么做、做什么、如何验证，同时避免把核心设计决策下放成猜测。
+
+## 前置检查
+
+1. 读取完整规格、仓库规则和相关代码结构。
+2. 确认规格中的阻塞问题已经解决。若关键行为、范围或契约仍未定，返回 `to-spec` 或 `grilling`。
+3. 提取目标、业务规则、外部契约、迁移要求和验收标准，建立追踪关系。
+
+## 拆分原则
+
+- **垂直切片**：优先交付一个可观察的端到端行为，不按数据库、后端、前端机械拆成孤立层任务。
+- **单一结果**：每票只有一个清楚的业务或工程结果。
+- **独立验证**：每票有可执行的测试、命令、截图、检查或其他证据。
+- **最少依赖**：明确真实先后关系，能并行的任务不要人为串行。
+- **可回退**：高风险变化包含兼容、迁移、开关或恢复步骤。
+- **边界完整**：把安全、权限、数据、观测和文档要求放进相关切片，不留到模糊的“收尾票”。
+
+必要时先用 `codebase-design` 明确模块与契约，再拆票。
+
+## 任务格式
+
+```markdown
+## T01 — 动词开头的结果标题
+- 目的：这项工作支持哪个目标？
+- 范围：包含哪些行为和边界？
+- 不包含：明确避免范围漂移。
+- 依赖：无 / Txx / 外部决策。
+- 实现提示：必须遵守的契约与约束，不预写全部代码。
+- 验收标准：可观察结果。
+- 验证：具体测试、命令或人工检查。
+- 风险与回退：仅在相关时填写。
+```
+
+推荐每票可在一次专注工作周期内完成并审查。如果任务标题包含多个无关“以及”，继续拆分；如果拆分后没有独立价值或无法验证，则合并回垂直切片。
+
+## 排序
+
+先做能够降低未知、建立必要契约或形成最小端到端路径的任务。排序时说明：
+
+- 阻塞关系；
+- 风险降低价值；
+- 是否可以并行；
+- 哪些任务在某项验证失败时应取消。
+
+## 本地与远程
+
+默认在回答或用户指定的本地 Markdown 文件中输出任务。只有用户明确授权、指定仓库/项目和目标系统后，才创建或修改 GitHub、Jira 等远程任务；创建前先展示拟写入内容和数量。
+
+## 完成标准
+
+- 规格中的每项验收标准都能追溯到至少一个任务。
+- 每个任务都有明确范围、依赖和验证方式。
+- 任务以垂直价值切分，没有孤立的“建表”“写接口”“做页面”层票。
+- 执行顺序和可并行部分清楚。
+
+## 反模式
+
+- 不要在规格未确认时用拆票掩盖决策缺失。
+- 不要创建无法独立验收的技术层任务堆。
+- 不要把测试、安全和迁移全部推迟到最后。
+- 不要未经授权写入远程 tracker。
+- 不要用任务数量代表计划质量。

package/skills/to-tickets/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "To Tickets"
+  short_description: "将确认后的规格拆分为独立、可交付并且可验证的垂直任务"
+  default_prompt: "请使用 $to-tickets 将这份规格拆成有依赖关系和验收方式的垂直任务。"
+policy:
+  allow_implicit_invocation: true

package/skills/wayfinder/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: wayfinder
+description: 当用户有一个规模较大但边界模糊的产品、技术或工作流想法，不知道从哪里开始、先验证什么或如何形成路线时使用。它通过探索、研究和风险排序收敛方向；已有明确规格的任务不使用。
+---
+
+# Wayfinder
+
+把模糊愿景转成一条可验证、可调整的路线。重点不是一次设计完整终局，而是找到最短的可信学习路径。
+
+## 阶段一：建立地图
+
+先检查现有资料，然后回答：
+
+- 想改变谁的什么现状，为什么现在值得做？
+- 可观察的成功结果是什么？
+- 哪些内容明确不在当前范围？
+- 已有哪些代码、数据、流程、约束和可复用资产？
+- 哪些未知项一旦判断错误，会使整个方向失效？
+
+必要时调用 `grilling` 逐题访谈；术语混乱时调用 `domain-modeling`。
+
+调用子 skill 时必须传递用户的权限约束、当前范围、已知事实、唯一待回答问题和预期返回格式。“只读”“仅规划”“不创建文件”或“禁止外部写入”等约束自动继承，子 skill 不得放宽。默认一次只推进一个信息价值最高的访谈、研究或原型；子 skill 只回答被分配的问题，完成后把控制权交回 `wayfinder`，由这里整合路线，避免递归扩大任务。
+
+## 阶段二：探索路径
+
+提出 2 至 4 条真正不同的候选路径。每条都说明：
+
+- 核心假设；
+- 最小用户价值；
+- 主要依赖和约束；
+- 最大失败模式；
+- 最便宜的验证方式；
+- 成功后下一步与失败后的退路。
+
+需要外部事实时调用 `research`，需要运行证据时调用 `prototype`。不要用更多文档替代本应进行的验证。
+
+## 阶段三：选择第一段路
+
+按“信息价值、用户价值、风险降低、实施成本、可逆性”排序。推荐一条路径，同时保留至少一个被否定方案及原因，避免把唯一提案误当成唯一可能。
+
+将路线拆成阶段，而不是伪精确的长期任务表：
+
+1. **探索**：解决会改变方向的未知项。
+2. **成形**：确认最小端到端价值和领域边界。
+3. **交付**：形成规格、垂直任务与验证门禁。
+4. **扩展**：仅在证据支持时增加范围和自动化。
+
+推荐路线的第一阶段必须是一张可检查的实验卡，至少包含：要支持的决策、可证伪假设、成功与失败门槛、时间或成本上限，以及结果出现后“继续、换路、停止”三个出口。
+
+## 默认产物
+
+在回答中或用户指定的本地 Markdown 文件中形成：
+
+```markdown
+# 路线图
+## 愿景与成功信号
+## 当前资产与约束
+## 关键未知项
+## 候选路径与取舍
+## 推荐路径
+## 分阶段验证
+## 停止条件与回退方案
+## 下一步
+```
+
+默认不创建远程 issue、项目看板或其他外部资源。只有用户明确授权并指定目标系统后才执行外部写入。
+
+## 完成标准
+
+- 愿景已转成可观察的目标和明确非目标。
+- 最大未知项有研究、原型或访谈方式，而不是被当成事实。
+- 第一阶段足够小，可以产生决策证据。
+- 当前阶段允许的读取、本地写入、外部写入和需再次授权的动作已经明确。
+- 用户知道下一步进入 `research`、`prototype`、`domain-modeling`、`codebase-design` 或 `to-spec` 中的哪一个；关键假设未验证前不进入代码库结构设计。
+
+## 反模式
+
+- 不要把头脑风暴清单冒充路线。
+- 不要在关键假设未验证前设计完整平台。
+- 不要用抽象愿景替代成功信号。
+- 不要未经授权把本地规划同步到外部系统。