RuView SPARC 实现专家 Agent 模板解析TDD 红绿重构工作流与 Claude Code Agent 定义实战【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView本篇基于 RuView 仓库中的 Agent 模板 implementer-sparc-coder.md完整拆解 SPARC 实现专家sparc-coder这一 AI 编码代理的 YAML frontmatter 定义、pre/post 钩子脚本、TDD 三阶段工作流与配套代码模式。读完后你将掌握如何为 Claude Code / 多智能体编排系统编写一个规格到可运行代码的实现型 Agent 模板并能将其正确接入 SPARC 方法论的 Refinement 阶段。模板在 SPARC 多智能体体系中的定位RuView 仓库的.claude/目录下内嵌了一套完整的 SPARCSpecification, Pseudocode, Architecture, Refinement, Completion多智能体开发框架阶段专用 Agent 位于 sparc/specification.md、sparc/pseudocode.md、sparc/architecture.md、sparc/refinement.md分别覆盖规格、伪代码、架构、精炼四个阶段v3 编排器 sparc-orchestrator.md 定义了完整的阶段流转图与质量门其中明确第 4 阶段Refinement Phase (TDD)的执行 Agent 为sparc-codertester质量门为Tests pass, coverage 80%, no critical issues方法论技能文档 SKILL.md 定义了 17 种 SPARC 模式的激活方式MCP 工具与npx claude-flow sparc run mode task两种通道。而本文主体 implementer-sparc-coder.md 正是sparc-coder这个实现专家的完整模板它负责接收前序阶段产出的规格与设计并以测试驱动的方式将其转化为经过验证的生产代码。模板与同目录下的 sparc-coordinator.md、base-template-generator.md 等一起构成.claude/agents/templates/模板库供编排器按需派生spawn实例。Frontmatter 元数据Agent 身份、能力与优先级模板文件以标准 YAML frontmatter 开头第 1–32 行这是 Claude Code 加载 Agent 时的解析入口--- name: sparc-coder type: development color: blue description: Transform specifications into working code with TDD practices capabilities: - code-generation - test-implementation - refactoring - optimization - documentation - parallel-execution priority: high hooks: pre: | ... post: | ... ---各字段的设计意图字段取值作用namesparc-coderAgent 注册名。从源码结构看v3 编排器正是通过这个名字把 Refinement 阶段的 TDD 任务委派给它见 sparc-orchestrator.md 中Task(TDD Coder, Implement using TDD: Red-Green-Refactor cycle., sparc-coder)typedevelopment声明 Agent 角色类别便于编排器做类型路由colorblue终端/日志中的显示颜色与其他阶段 Agent 区分description一句话职责描述供 LLM 做任务匹配将规格转化为带 TDD 实践的可用代码capabilities6 项能力清单声明该 Agent 可被委派的技能面代码生成、测试实现、重构、优化、文档、并行执行priorityhigh多 Agent 竞争同一任务时的调度优先级pre 钩子环境自检hooks.pre是一段在 Agent 启动前执行的 Shell 脚本第 15–21 行核心逻辑是探测仓库中是否已存在测试目录echo SPARC Implementation Specialist initiating code generation echo Preparing TDD workflow: Red → Green → Refactor # Check for test files and create if needed if [ ! -d tests ] [ ! -d test ] [ ! -d __tests__ ]; then echo No test directory found - will create during implementation fi值得注意的是它同时覆盖了tests、test、__tests__三种常见命名约定——这对应 Python/Node 生态里不同的测试布局习惯例如 SKILL.md 中 TDD 模式默认假设 jest 生态的__tests__而 tdd.md 命令文档则展示了覆盖率目标可配置为 90% 等选项。pre 钩子本身不阻塞、不建目录只是把无测试目录这一事实写入执行上下文提示后续实现阶段需要自建测试骨架。post 钩子按语言生态自动选择测试运行器hooks.post第 22–31 行在实现阶段完成后运行用于自动验证实现结果echo ✨ Implementation phase complete echo Running test suite to verify implementation # Run tests if available if [ -f package.json ]; then npm test --if-present elif [ -f pytest.ini ] || [ -f setup.py ]; then python -m pytest --version /dev/null 21 python -m pytest -v || echo pytest not available fi echo Implementation metrics stored in memory这段脚本体现了一个务实的设计以文件存在性作为语言生态探针——存在package.json时走npm test --if-present--if-present保证没有 test script 时不会报错否则若存在pytest.ini或setup.py先探测pytest是否可用再执行python -m pytest -v不可用时降级为提示而非失败最后声明指标已写入记忆。这与同目录 sparc-coordinator.md 中 post 钩子收集各阶段成功标志、计算整体 reward 并store-pattern入库的自学习模式一脉相承每个 Agent 的钩子既是生命周期切面lifecycle aspect也是把执行指标回流到共享记忆ReasoningBank / memory.db的埋点。核心原则一测试驱动开发TDD模板Core Implementation Principles章节第 41–46 行给出的 TDD 纪律是Red先写失败的测试Green写最少代码让测试通过Refactor在测试保护下重构提升质量维持高测试覆盖率80%。这个 80% 覆盖率阈值不是孤立设定。从源码结构看它是整条 SPARC 流水线上的共享质量门v3 编排器 sparc-orchestrator.md 的Phase Responsibilities中 Refinement 阶段质量门写为Tests pass, coverage 80%, no critical issues质量门表格里 Refinement 行同样标注Tests pass, coverage 80%且Blocking: Yes。也就是说实现 Agent 的自评标准与编排器的阶段放行标准是同一把尺子避免了实现自认为完成、编排器判定不达标的口径漂移。核心原则二并行实现策略模板第 47–51 行定义了并行实现的四条准则同时创建多个测试文件并行实现相互关联的功能批量文件操作提升效率协调跨组件的联动修改。这与 SKILL.md 概述中Parallel Execution: Concurrent agent coordination的方法论主张一致。并行化的关键约束是协调多组件变更——并行写文件本身容易难的是多个 Agent/多个文件之间的接口一致性这也是模板把parallel-execution与code-generation并列为顶层能力的原因。三阶段实现工作流模板Implementation Workflow章节第 60–87 行把 TDD 循环展开为三个可观察的阶段每个阶段以批量文件操作 一次测试验证为节拍。以下三组伪代码完整继承自原文档Phase 1: Test CreationRed[Parallel Test Creation]: - Write(tests/unit/auth.test.js, authTestSuite) - Write(tests/unit/user.test.js, userTestSuite) - Write(tests/integration/api.test.js, apiTestSuite) - Bash(npm test) // Verify all fail要点是并行写入多层级测试unit integration并以验证全部失败作为阶段出口条件。Red 阶段的测试失败必须是预期的红——若测试一开始就绿说明断言没有覆盖尚未实现的行为TDD 循环失效。Phase 2: ImplementationGreen[Parallel Implementation]: - Write(src/auth/service.js, authImplementation) - Write(src/user/model.js, userModel) - Write(src/api/routes.js, apiRoutes) - Bash(npm test) // Verify all passGreen 阶段的纪律是最小实现文件按src/feature/role结构落位service / model / routes只做让 Phase 1 测试通过所必需的代码不做额外抽象。Phase 3: RefinementRefactor[Parallel Refactoring]: - MultiEdit(src/auth/service.js, optimizations) - MultiEdit(src/user/model.js, improvements) - Edit(src/api/routes.js, cleanup) - Bash(npm test npm run lint)注意 Refactor 阶段的验证命令变成了npm test npm run lint的复合门重构不仅要保持测试全绿还要通过静态检查。MultiEdit对应 Claude Code 的多处批量编辑能力与原则二中批量文件操作呼应。这套节奏与 commands/sparc/tdd.md 中 TDD 模式的五步流程写失败测试 → 最小实现 → 测试通过 → 重构 → 循环完全对应模板可视为该模式在 Refinement 阶段的 Agent 级落地。标准代码模式可直接复用的实现骨架模板Code Patterns章节给出三组 JavaScript 参考实现它们既是 Agent 生成代码的风格基准也是人工评审实现产出时的对照物。模式 1Service 实现依赖注入 错误处理// Pattern: Dependency Injection Error Handling class AuthService { constructor(userRepo, tokenService, logger) { this.userRepo userRepo; this.tokenService tokenService; this.logger logger; } async authenticate(credentials) { try { // Implementation } catch (error) { this.logger.error(Authentication failed, error); throw new AuthError(Invalid credentials); } } }设计要点依赖全部经构造函数注入而非内部new使userRepo、tokenService在测试中可替换为 mock——这正是后文测试模式beforeEach中Setup with mocks能成立的前提错误路径上先记录日志、再抛出领域错误AuthError而非通用Error让上层路由能按错误类型分支处理。模式 2API 路由校验 限流 统一错误通道// Pattern: Validation Error Handling router.post(/auth/login, validateRequest(loginSchema), rateLimiter, async (req, res, next) { try { const result await authService.authenticate(req.body); res.json({ success: true, data: result }); } catch (error) { next(error); } } );中间件链的顺序是刻意设计的先validateRequest(loginSchema)做请求体校验再rateLimiter限流最后才进入业务 handler响应统一包装为{ success: true, data }结构handler 内所有异常都通过next(error)交给统一的错误中间件而不是就地吞掉。这套模式与模板后文Performance Optimization → API Optimization中的Rate limiting条目首尾呼应。模式 3测试结构AAA 分组覆盖// Pattern: Comprehensive Test Coverage describe(AuthService, () { let authService; beforeEach(() { // Setup with mocks }); describe(authenticate, () { it(should authenticate valid user, async () { // Arrange, Act, Assert }); it(should handle invalid credentials, async () { // Error case testing }); }); } 结构约定describe 按类 → 方法两级分组beforeEach 统一完成 mock 装配每个 it 内部遵循 Arrange-Act-Assert 三段式且明确要求每个方法同时覆盖正向用例valid user与错误用例invalid credentials——这是 80% 覆盖率质量门在测试设计层的落地手段。 ## 代码组织与实现准则 模板Best Practices章节第 153–171 行给出目录组织约定src/ ├── features/ # Feature-based structure │ ├── auth/ │ │ ├── service.js │ │ ├── controller.js │ │ └── auth.test.js │ └── user/ ├── shared/ # Shared utilities └── infrastructure/ # Technical concerns采用 feature-based按功能域而非 layer-based按技术层的目录划分每个功能域内聚 service / controller / test 三类文件shared 与 infrastructure 分别隔离通用工具与技术关注点。测试文件与实现同目录共存auth.test.js 与 service.js 并列降低了 Phase 1 并行建测试文件时的路径决策成本。 五条实现准则及其含义 1. **Single Responsibility**每个函数/类只做一件事 2. **DRY**Dont Repeat Yourself 3. **YAGNI**You Arent Gonna Need It——与 Green 阶段最小实现纪律互为表里 4. **KISS**Keep It Simple, Stupid 5. **SOLID**遵循面向对象五大原则其中依赖注入模式、面向接口 mock 的测试模式分别支撑 D 与 L。 ## 与 SPARC 流水线其他 Agent 的集成契约 模板Integration Patterns章节第 173–191 行定义了 sparc-coder 与三类协作方的职责边界这些边界在仓库其他文件中有明确印证 **与 SPARC Coordinator**接收规格与设计即 [specification.md](https://link.gitcode.com/i/b381762d8577bc558816148157d90e4b) 产出的需求文档、[architecture.md](https://link.gitcode.com/i/eb078120ee689c67d71661150370ef14) 产出的组件与接口设计、汇报实现进度、需要时请求澄清、交付经过测试的代码。v3 编排器 [sparc-orchestrator.md](https://link.gitcode.com/i/9bc4455b9831a30d0289c19fa30ebe8c) 的Agent Delegation Pattern正是按此契约派发的Phase 1–3 依次委派 specification、pseudocode、architecturePhase 4 才 Task(TDD Coder, ..., sparc-coder) 并并行派发 tester。 **与 Testing Agents**协调测试策略、确保覆盖率要求、处理测试自动化、验证质量指标。tester 与 sparc-coder 在 Refinement 阶段是双 Agent 配置前者聚焦测试面含覆盖率工具链后者聚焦实现面。 **与 Code Review Agents**为评审做准备、响应反馈、落实建议、维持标准。这对应 SPARC 完整流程中 Refinement 之后的 Completion 阶段由 reviewer production-validator 执行质量门为No critical issues。 ## 性能优化三大维度 模板Performance Optimization章节把实现阶段内嵌的性能工作分为三层 **1. 算法优化**选择高效数据结构、优化时间复杂度、降低空间复杂度、在合适处引入缓存。这与 [sparc-orchestrator.md](https://link.gitcode.com/i/9bc4455b9831a30d0289c19fa30ebe8c) 质量门表中 Pseudocode 阶段要求Algorithms complete, O(n) analyzed形成上下游衔接——复杂度分析在伪代码阶段完成实现阶段负责兑现。 **2. 数据库优化**高效查询、合理索引、连接池、查询优化。 **3. API 优化**响应压缩、分页、缓存策略、限流——其中限流与前文路由模式中的 rateLimiter 中间件直接对应。 ## 错误处理模式降级与指数退避重试 模板Error Handling Patterns章节给出两个完整可运行的参考实现第 213–239 行。 ### 优雅降级Graceful Degradation javascript // Fallback mechanisms try { return await primaryService.getData(); } catch (error) { logger.warn(Primary service failed, using cache); return await cacheService.getData(); }主服务失败时回退到缓存且降级行为以warn级别留痕而非静默——对调用方透明、对运维可见。指数退避重试Retry with Exponential Backoff// Retry with exponential backoff async function retryOperation(fn, maxRetries 3) { for (let i 0; i maxRetries; i) { try { return await fn(); } catch (error) { if (i maxRetries - 1) throw error; await sleep(Math.pow(2, i) * 1000); } } }实现细节值得注意退避间隔为2^i * 1000ms1s → 2s → 4s默认maxRetries 3最后一次失败直接向外抛出原错误保留完整错误上下文不包装、不丢失堆栈。这类重试骨架适用于对网络/设备类依赖的容错封装例如仓库中涉及多节点 ESP32 传感链路的脚本在实现重试逻辑时可参照此模式。文档标准JSDoc 与 README 双轨模板Documentation Standards章节第 241–259 行要求实现阶段同步产出两类文档代码注释采用 JSDoc 规范完整示例/** * Authenticates user credentials and returns access token * param {Object} credentials - User credentials * param {string} credentials.email - User email * param {string} credentials.password - User password * returns {PromiseObject} Authentication result with token * throws {AuthError} When credentials are invalid */throws {AuthError}与 Service 模式中抛出的领域错误类型保持一致使文档、实现、测试三者对异常契约的描述闭环。README 更新覆盖四块内容API 文档、搭建步骤、配置项说明、使用示例。这与 SPARC 方法论Document Continuously: Maintain current documentation throughout的核心原则一致——文档不是 Completion 阶段的补票而是实现阶段的持续产物documentation也是 frontmatter 中显式声明的 capability。实践要点与适用前提综合模板本体与仓库上下文使用该模板时应注意文件位置与加载方式模板位于 implementer-sparc-coder.md属于.claude/agents/templates/模板库。Claude Code 会读取项目内.claude/下的 Agent 定义与 settings.json 中的 hooks 配置该仓库在PreToolUse/PostToolUse/UserPromptSubmit/SessionStart等生命周期点挂载了hook-handler.cjs等钩子模板本身内嵌的 pre/post 钩子在 Agent 执行生命周期内以 Shell 片段运行。运行环境前提post 钩子依赖npm或pytest之一可用并以文件存在性package.json/pytest.ini/setup.py判断生态若项目两者皆无如纯 Rust 的 v2/ crate 树该钩子会跳过测试执行此时应补充对应语言生态的验证命令否则 Green/Refactor 阶段的验证全绿出口条件失去自动保障。质量门对齐覆盖率阈值 80% 必须与编排侧保持一致sparc-orchestrator.md 质量门表否则会出现实现自评通过、阶段门拦截的反复返工tdd.md 展示了将覆盖率目标提升为 90% 的配置方式调整时两侧需同步。与完整流水线的衔接单跑sparc-coder只覆盖 Refinement 阶段若要执行全周期参考 sparc-orchestrator.md 提供的编排命令如按阶段执行 specification → pseudocode → architecture → refinement → completion并配合 SKILL.md 中的 MCP 工具激活方式与npx claude-flow sparc run mode taskCLI 回退通道。小结implementer-sparc-coder.md 是一个结构完整、可直接复用的实现型 Agent 模板frontmatter 声明身份/能力/优先级pre/post 钩子完成环境自检与按生态自动验证正文则以 TDD 三阶段工作流为骨架配套 Service 注入、路由校验、测试分组三组代码模式并以并行实现、feature-based 目录组织、降级与退避重试、JSDoc 文档标准收束。它与 sparc-orchestrator.md 的质量门、SKILL.md 的 17 种模式共同构成规格 → 可运行、可测试、可交付代码的闭环理解了这套模板你就能在任意项目中编写同类 TDD 实现专家 Agent并把它正确挂入 SPARC 流水线。【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考