[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6RVRF892PFFG1N3RVZMGVEG":3,"skill-same:01M6RVRF892PFFG1N3RVZMGVEG":71},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":48,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M6RVRF892PFFG1N3RVZMGVEG","writing-plans",null,"当你有规格说明或需求用于多步骤任务时使用，在动手写代码之前","rzx007\u002FVykor","rzx007","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F22313722?v=4","01M6RVGB3GJ05PGEFHQ34TV6T0","Danovan","01M6RVGB7F20SDKPMEN9RS3N0N",3,"MIT","https:\u002F\u002Fgithub.com\u002Frzx007\u002FVykor\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwriting-plans\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[29,30,31,32,33],"writing","writing plans","plans","documentation","planning","2026-11-10 10:12:30",false,"---\nname: writing-plans\ndescription: 当你有规格说明或需求用于多步骤任务时使用，在动手写代码之前\nversion: \"1.0.0\"\nlicense: MIT\nmetadata:\n  hermes:\n    tags: [planning, documentation]\n---\n\n# 编写计划\n\n## 概述\n\n编写全面的实现计划，假设工程师对我们的代码库零上下文，且品味存疑。记录他们需要知道的一切：每个任务要修改哪些文件、代码、测试、可能需要查阅的文档、如何测试。将整个计划拆成小步骤任务。DRY。YAGNI。TDD。频繁 commit。\n\n假设他们是有经验的开发者，但对我们的工具链和问题领域几乎一无所知。假设他们不太擅长测试设计。\n\n**开始时宣布：** \"我正在使用 writing-plans 技能创建实现计划。\"\n\n**上下文：** 此技能应在专用 worktree 中运行（由 brainstorming 技能创建）。\n\n**计划保存位置：** `docs\u002Fsuperpowers\u002Fplans\u002FYYYY-MM-DD-\u003Cfeature-name>.md`\n- （用户对计划位置的偏好优先于此默认值）\n\n## 范围检查\n\n如果规格涵盖了多个独立子系统，它应该在头脑风暴阶段就被拆分为子项目规格。如果没有，建议将其拆分为独立的计划——每个子系统一个。每个计划应该能独立产出可工作、可测试的软件。\n\n## 文件结构\n\n在定义任务之前，先列出将要创建或修改的文件以及每个文件的职责。这是锁定分解决策的地方。\n\n- 设计边界清晰、接口定义良好的单元。每个文件应有一个明确的职责。\n- 你对能一次放入上下文的代码推理得最好，文件越专注你的编辑越可靠。优先选择小而专注的文件，而非承担过多功能的大文件。\n- 一起变更的文件应放在一起。按职责拆分，而非按技术层级拆分。\n- 在现有代码库中，遵循已有模式。如果代码库使用大文件，不要单方面重构——但如果你正在修改的文件已经变得难以管理，在计划中包含拆分是合理的。\n\n此结构决定了任务分解。每个任务应产出独立的、有意义的变更。\n\n## 任务粒度定界\n\n一个任务是**能独立承载自己那一轮测试循环、且值得一个全新审查者把关**的最小单元。划任务边界时：把搭建、配置、脚手架和文档这些步骤，折进那个真正需要它们的交付物所在的任务里；只在「审查者有可能否掉这个任务、同时批准它旁边那个」的地方才拆开。每个任务都以一个**可独立测试的交付物**结束。\n\n## 小步骤任务粒度\n\n**每步是一个操作（2-5 分钟）：**\n- \"编写失败的测试\" - 一步\n- \"运行它确认失败\" - 一步\n- \"实现最少代码让测试通过\" - 一步\n- \"运行测试确认通过\" - 一步\n- \"Commit\" - 一步\n\n## 计划文档头部\n\n**每个计划必须以此头部开始：**\n\n```markdown\n# [功能名称] 实现计划\n\n> **面向 AI 代理的工作者：** 必需子技能：使用 superpowers:subagent-driven-development（推荐）或 superpowers:executing-plans 逐任务实现此计划。步骤使用复选框（`- [ ]`）语法来跟踪进度。\n\n**目标：** [一句话描述要构建什么]\n\n**架构：** [2-3 句话描述方案]\n\n**技术栈：** [关键技术\u002F库]\n\n---\n```\n\n## 任务结构\n\n````markdown\n### 任务 N：[组件名称]\n\n**文件：**\n- 创建：`exact\u002Fpath\u002Fto\u002Ffile.py`\n- 修改：`exact\u002Fpath\u002Fto\u002Fexisting.py:123-145`\n- 测试：`tests\u002Fexact\u002Fpath\u002Fto\u002Ftest.py`\n\n- [ ] **步骤 1：编写失败的测试**\n\n```python\ndef test_specific_behavior():\n    result = function(input)\n    assert result == expected\n```\n\n- [ ] **步骤 2：运行测试验证失败**\n\n运行：`pytest tests\u002Fpath\u002Ftest.py::test_name -v`\n预期：FAIL，报错 \"function not defined\"\n\n- [ ] **步骤 3：编写最少实现代码**\n\n```python\ndef function(input):\n    return expected\n```\n\n- [ ] **步骤 4：运行测试验证通过**\n\n运行：`pytest tests\u002Fpath\u002Ftest.py::test_name -v`\n预期：PASS\n\n- [ ] **步骤 5：Commit**\n\n```bash\ngit add tests\u002Fpath\u002Ftest.py src\u002Fpath\u002Ffile.py\ngit commit -m \"feat: add specific feature\"\n```\n````\n\n## 禁止占位符\n\n每个步骤都必须包含工程师需要的实际内容。以下是**计划缺陷**——绝不要写出来：\n- \"待定\"、\"TODO\"、\"后续实现\"、\"补充细节\"\n- \"添加适当的错误处理\" \u002F \"添加验证\" \u002F \"处理边界情况\"\n- \"为上述代码编写测试\"（没有实际测试代码）\n- \"类似任务 N\"（重复代码——工程师可能不按顺序阅读任务）\n- 只描述做什么而不展示怎么做的步骤（代码步骤必须有代码块）\n- 引用了未在任何任务中定义的类型、函数或方法\n\n## 自检\n\n编写完整计划后，以全新视角审视规格并对照检查计划。这是你自己执行的检查清单——不是子代理调度。\n\n**1. 规格覆盖度：** 浏览规格中的每个章节\u002F需求。你能指出实现它的任务吗？列出所有遗漏。\n\n**2. 占位符扫描：** 搜索计划中的红旗——上方\"禁止占位符\"章节中的任何模式。修复它们。\n\n**3. 类型一致性：** 后续任务中使用的类型、方法签名和属性名是否与前面任务中定义的一致？任务 3 中叫 `clearLayers()` 但任务 7 中叫 `clearFullLayers()` 就是 bug。\n\n如果发现问题，直接内联修复。无需重新审查——修好继续推进。如果发现规格中的需求没有对应任务，就添加任务。\n\n## 执行交接\n\n保存计划后，提供执行选项：\n\n**\"计划已完成并保存到 `docs\u002Fsuperpowers\u002Fplans\u002F\u003Cfilename>.md`。两种执行方式：**\n\n**1. 子代理驱动（推荐）** - 每个任务调度一个新的子代理，任务间进行审查，快速迭代\n\n**2. 内联执行** - 在当前会话中使用 executing-plans 执行任务，批量执行并设有检查点\n\n**选哪种方式？\"**\n\n**如果选择子代理驱动：**\n- **必需子技能：** 使用 superpowers:subagent-driven-development\n- 每个任务一个新子代理 + 两阶段审查\n\n**如果选择内联执行：**\n- **必需子技能：** 使用 superpowers:executing-plans\n- 批量执行并设有检查点供审查\n","# 编写计划\n\n## 概述\n\n编写全面的实现计划，假设工程师对我们的代码库零上下文，且品味存疑。记录他们需要知道的一切：每个任务要修改哪些文件、代码、测试、可能需要查阅的文档、如何测试。将整个计划拆成小步骤任务。DRY。YAGNI。TDD。频繁 commit。\n\n假设他们是有经验的开发者，但对我们的工具链和问题领域几乎一无所知。假设他们不太擅长测试设计。\n\n**开始时宣布：** \"我正在使用 writing-plans 技能创建实现计划。\"\n\n**上下文：** 此技能应在专用 worktree 中运行（由 brainstorming 技能创建）。\n\n**计划保存位置：** `docs\u002Fsuperpowers\u002Fplans\u002FYYYY-MM-DD-\u003Cfeature-name>.md`\n- （用户对计划位置的偏好优先于此默认值）\n\n## 范围检查\n\n如果规格涵盖了多个独立子系统，它应该在头脑风暴阶段就被拆分为子项目规格。如果没有，建议将其拆分为独立的计划——每个子系统一个。每个计划应该能独立产出可工作、可测试的软件。\n\n## 文件结构\n\n在定义任务之前，先列出将要创建或修改的文件以及每个文件的职责。这是锁定分解决策的地方。\n\n- 设计边界清晰、接口定义良好的单元。每个文件应有一个明确的职责。\n- 你对能一次放入上下文的代码推理得最好，文件越专注你的编辑越可靠。优先选择小而专注的文件，而非承担过多功能的大文件。\n- 一起变更的文件应放在一起。按职责拆分，而非按技术层级拆分。\n- 在现有代码库中，遵循已有模式。如果代码库使用大文件，不要单方面重构——但如果你正在修改的文件已经变得难以管理，在计划中包含拆分是合理的。\n\n此结构决定了任务分解。每个任务应产出独立的、有意义的变更。\n\n## 任务粒度定界\n\n一个任务是**能独立承载自己那一轮测试循环、且值得一个全新审查者把关**的最小单元。划任务边界时：把搭建、配置、脚手架和文档这些步骤，折进那个真正需要它们的交付物所在的任务里；只在「审查者有可能否掉这个任务、同时批准它旁边那个」的地方才拆开。每个任务都以一个**可独立测试的交付物**结束。\n\n## 小步骤任务粒度\n\n**每步是一个操作（2-5 分钟）：**\n- \"编写失败的测试\" - 一步\n- \"运行它确认失败\" - 一步\n- \"实现最少代码让测试通过\" - 一步\n- \"运行测试确认通过\" - 一步\n- \"Commit\" - 一步\n\n## 计划文档头部\n\n**每个计划必须以此头部开始：**\n\n```markdown\n# [功能名称] 实现计划\n\n> **面向 AI 代理的工作者：** 必需子技能：使用 superpowers:subagent-driven-development（推荐）或 superpowers:executing-plans 逐任务实现此计划。步骤使用复选框（`- [ ]`）语法来跟踪进度。\n\n**目标：** [一句话描述要构建什么]\n\n**架构：** [2-3 句话描述方案]\n\n**技术栈：** [关键技术\u002F库]\n\n---\n```\n\n## 任务结构\n\n````markdown\n### 任务 N：[组件名称]\n\n**文件：**\n- 创建：`exact\u002Fpath\u002Fto\u002Ffile.py`\n- 修改：`exact\u002Fpath\u002Fto\u002Fexisting.py:123-145`\n- 测试：`tests\u002Fexact\u002Fpath\u002Fto\u002Ftest.py`\n\n- [ ] **步骤 1：编写失败的测试**\n\n```python\ndef test_specific_behavior():\n    result = function(input)\n    assert result == expected\n```\n\n- [ ] **步骤 2：运行测试验证失败**\n\n运行：`pytest tests\u002Fpath\u002Ftest.py::test_name -v`\n预期：FAIL，报错 \"function not defined\"\n\n- [ ] **步骤 3：编写最少实现代码**\n\n```python\ndef function(input):\n    return expected\n```\n\n- [ ] **步骤 4：运行测试验证通过**\n\n运行：`pytest tests\u002Fpath\u002Ftest.py::test_name -v`\n预期：PASS\n\n- [ ] **步骤 5：Commit**\n\n```bash\ngit add tests\u002Fpath\u002Ftest.py src\u002Fpath\u002Ffile.py\ngit commit -m \"feat: add specific feature\"\n```\n````\n\n## 禁止占位符\n\n每个步骤都必须包含工程师需要的实际内容。以下是**计划缺陷**——绝不要写出来：\n- \"待定\"、\"TODO\"、\"后续实现\"、\"补充细节\"\n- \"添加适当的错误处理\" \u002F \"添加验证\" \u002F \"处理边界情况\"\n- \"为上述代码编写测试\"（没有实际测试代码）\n- \"类似任务 N\"（重复代码——工程师可能不按顺序阅读任务）\n- 只描述做什么而不展示怎么做的步骤（代码步骤必须有代码块）\n- 引用了未在任何任务中定义的类型、函数或方法\n\n## 自检\n\n编写完整计划后，以全新视角审视规格并对照检查计划。这是你自己执行的检查清单——不是子代理调度。\n\n**1. 规格覆盖度：** 浏览规格中的每个章节\u002F需求。你能指出实现它的任务吗？列出所有遗漏。\n\n**2. 占位符扫描：** 搜索计划中的红旗——上方\"禁止占位符\"章节中的任何模式。修复它们。\n\n**3. 类型一致性：** 后续任务中使用的类型、方法签名和属性名是否与前面任务中定义的一致？任务 3 中叫 `clearLayers()` 但任务 7 中叫 `clearFullLayers()` 就是 bug。\n\n如果发现问题，直接内联修复。无需重新审查——修好继续推进。如果发现规格中的需求没有对应任务，就添加任务。\n\n## 执行交接\n\n保存计划后，提供执行选项：\n\n**\"计划已完成并保存到 `docs\u002Fsuperpowers\u002Fplans\u002F\u003Cfilename>.md`。两种执行方式：**\n\n**1. 子代理驱动（推荐）** - 每个任务调度一个新的子代理，任务间进行审查，快速迭代\n\n**2. 内联执行** - 在当前会话中使用 executing-plans 执行任务，批量执行并设有检查点\n\n**选哪种方式？\"**\n\n**如果选择子代理驱动：**\n- **必需子技能：** 使用 superpowers:subagent-driven-development\n- 每个任务一个新子代理 + 两阶段审查\n\n**如果选择内联执行：**\n- **必需子技能：** 使用 superpowers:executing-plans\n- 批量执行并设有检查点供审查\n",{"name":5,"license":15,"version":39,"metadata":40,"description":7},"1.0.0",{"hermes":41},{"tags":42},[33,32],"main","11fa3057bb1aff51d77b97648803dec2b2ea62d9",".agents\u002Fskills\u002Fwriting-plans",2,"https:\u002F\u002Fgithub.com\u002Frzx007\u002FVykor","https:\u002F\u002Frzx007.github.io\u002FVykor\u002F","https:\u002F\u002Fgithub.com\u002Frzx007","2026-11-13 23:57:39",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add rzx007\u002FVykor --skill writing-plans",{"tool":57,"command":58},"bunx","bunx skills add rzx007\u002FVykor --skill writing-plans",{"tool":60,"command":61},"pnpm","pnpm dlx skills add rzx007\u002FVykor --skill writing-plans","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frzx007\u002FVykor\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwriting-plans\u002FSKILL.md",true,[65],{"path":66,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":69,"sourceHtmlUrl":70},"plan-document-reviewer-prompt.md","REFERENCE","参考文档",1603,"https:\u002F\u002Fgithub.com\u002Frzx007\u002FVykor\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwriting-plans\u002Fplan-document-reviewer-prompt.md",[72,82,89,112,124,137],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":80,"publishedAt":34},"01M6RVYYTPGG9WWWV4QAY0YEY3","writing-skills","当创建新技能、编辑现有技能或在部署前验证技能是否有效时使用","https:\u002F\u002Fgithub.com\u002Frzx007\u002FVykor\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[78,79],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[81,29,32],"writing skills",{"skillNo":83,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":88,"publishedAt":34},"01M6RVYE486HE8NQ2M4G5DNG63","https:\u002F\u002Fgithub.com\u002Frzx007\u002FVykor\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwriting-plans\u002FSKILL.md",[86,87],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[31,30,29,33,32],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":98,"publishedAt":34},"01M6RVY778PEDPWQ0DCM25QW3A","workflow-runner","在 Claude Code \u002F OpenClaw \u002F Cursor 中直接运行 agency-orchestrator YAML 工作流——无需 API key，使用当前会话的 LLM 作为执行引擎。当用户提供 .yaml 工作流文件或要求多角色协作完成任务时触发。","https:\u002F\u002Fgithub.com\u002Frzx007\u002FVykor\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fworkflow-runner\u002FSKILL.md",[95],{"categoryNo":96,"categoryName":97,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[99,100,101,102,103,104,105,106,107,108,109,110,111],"workflow runner","runner","workflow","协作","文件","agency","orchestrator","cursor","api","execution","yaml","code","openclaw",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":34},"01M6RVY4NR6RRPV174AB706A13","verification-before-completion","在宣称工作完成、已修复或测试通过之前使用，在提交或创建 PR 之前——必须运行验证命令并确认输出后才能声称成功；始终用证据支撑断言","https:\u002F\u002Fgithub.com\u002Frzx007\u002FVykor\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[],[119,120,121,122,123],"verification before completion","verification","quality","pr","testing",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":34},"01M6RVY1ZQ6ADVCZGBS371HD88","using-superpowers","在开始任何对话时使用——确立如何查找和使用技能，要求在任何响应（包括澄清性问题）之前调用 Skill 工具","https:\u002F\u002Fgithub.com\u002Frzx007\u002FVykor\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fusing-superpowers\u002FSKILL.md",[],[131,132,133,134,135,136],"superpowers","using superpowers","对话","Meta","工具","getting-started",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":34},"01M6RVXJFEQ00P7XBQ8FBEKKJ2","using-git-worktrees","当需要开始与当前工作区隔离的功能开发，或在执行实现计划之前使用——通过原生工具或 git worktree 回退机制确保隔离工作区存在","https:\u002F\u002Fgithub.com\u002Frzx007\u002FVykor\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fusing-git-worktrees\u002FSKILL.md",[],[144,145,146,147,148,101,149,150,135],"using git worktrees","git","git worktrees","worktrees","Using git","worktree","git worktree"]