superpowers-zh 子智能体驱动开发实战：Svelte Todo 设计规格与验收驱动的测试夹具全解析

AI 技能AI 插件人工智能开发工具【免费下载链接】superpowers-zh AI 编程超能力 · 中文增强版 — superpowers250k ⭐完整汉化 4 个中国原创 skills让 Claude Code / Copilot CLI / Hermes Agent / Cursor / Windsurf / Kiro / Gemini CLI / Qoder 等 26 款 AI 编程工具真正会干活项目地址https://gitcode.com/gh_mirrors/su/superpowers-zh点击查看免费下载本文围绕 superpowers-zh 仓库中 tests/subagent-driven-dev/svelte-todo/design.md 这一设计规格文档展开剖析它以 localStorage 持久化 Todo 清单应用为载体的完整需求定义方式并揭示它如何在subagent-driven-development子智能体驱动开发技能中充当可自动验收的测试夹具。读完本文你将掌握如何用一份「功能 界面 组件结构 数据模型 验收标准」五段式的设计文档驱动多智能体流水线把规格转化为可测试、可交付的实现。设计文档的定位SDD 技能的自动化测试夹具在 superpowers-zh 的subagent-driven-development技能体系中设计文档design.md不只是给人看的蓝图它更是测试夹具的权威规格。仓库里存放着两套完整的测试场景Go 语言实现的 go-fractals 分形命令行工具 和 Svelte 前端应用 svelte-todo后者即本文主体。这两份文档的共同使命正如 tests/subagent-driven-dev/run-test.sh 所演示的那样先由脚手架脚本把设计文档与实现计划复制进一个全新 git 仓库再以一句claude -p Execute this plan using superpowers:subagent-driven-development. The plan is at: ...启动整个子智能体流水线最后用真实测试命令如npm test npx playwright test验证产出是否达标。因此这份 design.md 的质量直接决定了自动化演练能跑多深——它必须是「可裁决」的规格而不只是愿望清单。功能清单一条 Todo 应用的完整需求基线设计文档的 Features 一节定义了应用的全部功能边界共七项新增 TodoAdd new todos标记完成 / 未完成Mark todos as complete/incomplete删除 TodoDelete todos按 全部 / 进行中 / 已完成 过滤Filter by: All / Active / Completed一键清除所有已完成项Clear all completed todos持久化到 localStoragePersist to localStorage展示剩余未完成项计数Show count of remaining items这份清单是计划plan.md与验收标准Acceptance Criteria的共同出处。值得注意的是它刻意维持了「经典 TodoMVC 最小集」的规模没有拖拽排序、没有编辑行内文本、没有服务端同步——这种刻意收敛正是设计文档作为 SDD 夹具的可贵之处它让每个任务都能被一个隔离上下文的实现子智能体独立消化参见 SKILL.md 中「每个任务一个全新子智能体」的核心原则。用户界面设计用 ASCII 原型锁定交互布局设计文档用一段等宽 ASCII 线框图锁定了界面结构这是纯文本规格中最有约束力的部分——实现者必须照此还原布局┌─────────────────────────────────────────┐ │ Svelte Todos │ ├─────────────────────────────────────────┤ │ [________________________] [Add] │ ├─────────────────────────────────────────┤ │ [ ] Buy groceries [x] │ │ [✓] Walk the dog [x] │ │ [ ] Write code [x] │ ├─────────────────────────────────────────┤ │ 2 items left │ │ [All] [Active] [Completed] [Clear ✓] │ └─────────────────────────────────────────┘从这幅原型可以读出四个必须实现的交互区域顶部输入区文本输入框 Add 按钮对应TodoInput组件中部列表区每条 Todo 由复选框、文本、右侧删除按钮X组成完成项显示对勾✓与删除线对应TodoItem状态栏左侧显示未完成计数「X items left」右侧依次为 All / Active / Completed 三个过滤按钮与 Clear Completed✓按钮对应FilterBar整体容器由App.svelte负责装配。结合 plan.md 中任务 10Styling and Polish的要求这份原型还隐含了视觉细则完成项需要删除线与弱化色muted color、当前激活的过滤按钮需要高亮、输入框需要有 focus 样式、删除按钮在桌面端悬停时出现移动端常显、整体需要响应式布局。组件架构与目录结构单一职责的文件划分设计文档给出了明确的组件树这是实现子智能体唯一的文件组织依据src/ App.svelte # Main app, state management lib/ TodoInput.svelte # Text input Add button TodoList.svelte # List container TodoItem.svelte # Single todo with checkbox, text, delete FilterBar.svelte # Filter buttons clear completed store.ts # Svelte store for todos storage.ts # localStorage persistence这是一份「关注点分离」的教科书式划分store.ts负责全局状态Svelte store对应计划任务 2需要导出addTodo(text)、toggleTodo(id)、deleteTodo(id)、clearCompleted()四个操作函数storage.ts负责 localStorage 持久化对应计划任务 3需要实现loadTodos(): Todo[]与saveTodos(todos: Todo[])并对 JSON 解析错误做优雅降级返回空数组TodoInput / TodoItem / TodoList / FilterBar四个组件各司其职分别对应计划任务 4–7App.svelte承担集成职责持有过滤状态默认all计算过滤后的列表并逐组件下发 props对应计划任务 8。从实现子智能体视角看这种「一文件一职责」的结构让 implementer-prompt.md 中「每个文件应有单一明确的职责和定义清晰的接口」的约束变得可执行——实现者不需要任何额外判断就能落盘。数据模型类型即契约设计文档用 TypeScript 类型定义了唯一的数据契约interface Todo { id: string; // UUID text: string; // Todo text completed: boolean; } type Filter all | active | completed;两个要点值得展开id 使用 UUID这保证了 localStorage 中的每条记录全局唯一删除与切换状态操作可以稳定定位目标条目计划任务 2 要求createTodo类函数生成新条目时填充该字段Filter 为联合类型all | active | completed三个字符串字面量把过滤逻辑限制在三个可穷举的取值内直接服务于计划任务 9 的过滤语义——all显示全部、active仅显示未完成、completed仅显示已完成并透传给 FilterBar 的onFilterChange回调。这份契约在计划中也被严格继承FilterBar 的 props 签名todos: Todo[]、filter: Filter、onFilterChange: (f: Filter) void与数据模型一一对应没有出现类型漂移。验收标准9 条可机器验证的完成定义设计文档末尾的 Acceptance Criteria 是整套流水线的「有约束力的权威」binding authority——SDD 技能中的任务审查者会拿着它逐条比对 diff可输入文本并按回车或点击 Add 新增 Todo点击复选框可切换完成状态点击 X 按钮可删除 Todo过滤按钮显示正确的 Todo 子集「X items left」显示未完成项计数「Clear completed」移除全部已完成项刷新页面后 Todo 仍然存在localStorage 持久化空状态下显示有帮助的提示文案所有测试通过。注意第 8 条空状态提示并非 UI 原型中的显式元素而是写在验收标准里——这正是设计文档「补全原型盲区」的地方。对应到计划任务 6TodoList组件需要在列表为空时渲染「No todos yet」这类文案。第 9 条则把「测试全绿」直接写进了规格为审查者的规格合规性检查提供了硬性依据。从设计到计划12 个任务的实现分解design.md 并不直接描述实现步骤真正的执行剧本在姊妹文档 plan.md 中两者以「设计为权威、计划为论证」的关系配套使用。计划将整个应用拆解为 12 个可独立分派的原子任务任务主题关键动作与验证命令1项目脚手架npm create vitelatest . -- --template svelte-tsnpm install验证 dev server 与npm run build2Todo Store创建store.ts与四个操作函数配store.test.ts跑npm run test必要时安装 vitest3localStorage 持久化loadTodos/saveTodosJSON 解析错误返回空数组含错误处理测试4TodoInput 组件输入框 Add 按钮Enter 提交输入为空时禁用按钮5TodoItem 组件props:todo: Todo复选框切换、完成删除线、X 删除6TodoList 组件props:todos: Todo[]空状态显示「No todos yet」7FilterBar 组件计数 三过滤按钮 高亮 Clear completed无已完成项时隐藏8App 集成装配全部组件持有默认all的过滤状态9过滤端到端三种过滤语义验证 清除后重置过滤 集成测试10样式打磨对齐设计原型focus / hover / 响应式样式11E2E 测试npm init playwrightlatest覆盖增删改查、过滤、清除、持久化六条用户流12README记录npm install/npm run dev/npm test/npx playwright test/npm run build每个任务都遵循统一的「Do / Verify」模板Do 列出具体动作与产出文件Verify 给出可执行的验证手段。这种结构化任务文本正是 SDD 技能中scripts/task-brief能够自动化抽取的前提——该脚本按标题把单个任务完整抽到独立简报文件scripts/task-brief 同时兼容英文Task N与中文任务 N标题让实现子智能体「一次 Read 调用就读完需求」而无需翻阅整个计划。跑通整套演练scaffold.sh 与 run-test.sh 的配合设计文档的价值最终通过自动化演练被验证。两条脚本构成完整的测试链scaffold.sh用法./scaffold.sh /path/to/target负责在目标目录搭建隔离演练场mkdir -p目标目录并git init把design.md与plan.md复制进去写入.claude/settings.local.json授予 Read/Edit/Write 及npm:*、npx:*、mkdir:*、git:*的 Bash 权限供实现子智能体读写建立初始提交打印启动提示用--plugin-dir指向 superpowers 插件目录执行计划。run-test.sh用法./run-test.sh svelte-todo --plugin-dir path则完成编排先调用 scaffold 脚本再以claude -p携带--dangerously-skip-permissions --output-format stream-json --verbose启动无头执行把流式 JSON 输出含 token 用量落盘到时间戳目录最后给出两条验证命令npm test单元/组件测试与npx playwright testE2E。对 svelte-todo 场景而言「测试全绿」正是验收标准第 9 条的直接落地。规格如何驱动审查设计文档在 SDD 流水线中的作用这份 design.md 之所以称得上「有约束力的权威」在于它贯穿了 SKILL.md 定义的完整审查闭环准备阶段控制者通读计划并扫描冲突时若计划与设计冲突以设计为准作出裁决并记入账本任务审查审查者拿到任务简报、实现者报告与审查包scripts/review-package PLAN_FILE BASE HEAD生成含提交列表、stat 摘要与 -U10 上下文 diff 的文件对照设计文档逐条核验规格合规性——缺失、多余、理解偏差三类问题都会作为发现抛出并按 Critical / Important / Minor 定级修复循环发现未解决时唤回原实现者第 1–3 轮或换更强模型第 4–5 轮修复后由 re-review-prompt.md 定向复审对每条发现给出 ADDRESSED / NOT ADDRESSED 结论每任务最多五轮最终审查所有任务完成后用最强模型对整个分支做宽范围审查账本中「延后的 Minor」与「已搁置的发现」一并送审。设计文档中「验收标准」这一节正是任务审查者核对「规格 ✅/❌」时逐条打勾的清单而 task-reviewer-prompt.md 要求审查者「不要信任报告、对照 diff 核实、给每条检查附 file:line」则保证了这份规格被真正执行而非被口头满足。总结一份可执行规格的构成要素纵观 design.md它用五个小节回答了「做什么、长什么样、怎么组织、数据是什么、怎样算完成」五个问题且每个答案都能被下游机械地消费功能清单喂给计划分解ASCII 原型喂给 UI 实现组件树喂给文件结构数据模型喂给类型与 store验收标准喂给审查者与测试脚本。这份文档本身就是 SDD 方法论「规格是有约束力的权威」的最佳注脚——当设计文档可裁决时子智能体流水线才能做到「高质量、快速迭代」。赞分享AI 技能AI 插件人工智能开发工具【免费下载链接】superpowers-zh AI 编程超能力 · 中文增强版 — superpowers250k ⭐完整汉化 4 个中国原创 skills让 Claude Code / Copilot CLI / Hermes Agent / Cursor / Windsurf / Kiro / Gemini CLI / Qoder 等 26 款 AI 编程工具真正会干活项目地址https://gitcode.com/gh_mirrors/su/superpowers-zh点击查看免费下载相关推荐Superpowers与TDD如何利用AI工具实现严格的测试驱动开发Superpowers与TDD如何利用AI工具实现严格的测试驱动开发 Superpowers是一个强大的AI辅助开发工具库它将Claude Code的核心技AI 技能AI 插件开发工具终极技能库揭秘Superpowers中的测试驱动开发实践终极技能库揭秘Superpowers中的测试驱动开发实践 测试驱动开发TDD是现代软件开发中不可或缺的核心技能它能显著提升代码质量并减少bug数量。在SAI 技能AI 插件开发工具superpowers-zh测试驱动开发TDD详解让AI先写测试再写代码告别低级bugsuperpowers zh测试驱动开发TDD详解让AI先写测试再写代码告别低级bug superpowers zhAI 编程超能力 · 中文增强版 内AI 技能AI 插件人工智能开发工具上一篇用 instructor 将杂乱表格转换为整洁数据基于 Structured Outputs 与 pandas 的完整实战指南下一篇Lynx CSS 编码器css_encoder深度解析模板包中 CSS 的解析、Token 编码与验证创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考