# 线性问题实现 ## 概述该技能提供了通过专业软件工程实践实现线性问题的全面工作流程。它自动化了从问题分析到 PR 创建的整个开发生命周期，通过测试驱动开发、并行代码审查和系统验证来确保质量。 ## 何时使用此技能在以下情况下使用此技能： * 用户提供线性问题 ID（格式：`TRA-9`、`DEV-123` 等） * 用户请求实施线性问题 * 用户想要一种带有代码审查的结构化 TDD 方法 * 用户需要从问题到 PR 的自动化工作流程示例： *“实施TRA-142” *“帮我构建 DEV-89 中的功能” *“线性问题 ABC-456 的工作” ## 核心工作流程该技能遵循 14 个步骤： 1. **获取线性问题** \- 通过线性 MCP 检索完整的问题详细信息 2. **收集其他上下文** \- 搜索 Obsidian、Sentry 和 GitHub 以获取相关信息 3. **移至进行中** \- 更新问题状态以指示正在进行的工作 4. **创建Feature分支** \-使用Linear建议的git分支命名 5. **分析和计划** \- 分解需求并制定实施计划 6. **保存到内存** \- 将计划存储在内存图中以供跟踪 7. **审查计划** \- 提出计划以供用户确认 8. **TDD 实现** \- 调用“tdd-workflow”技能进行测试驱动开发 9. **并行代码审查** \- 调用`parallel-code-review`技能进行综合分析 10. **解决反馈** \- 调用“code-review-implementer”技能来系统地解决问题 11. **验证** \- 确保所有测试和 linter 通过 12. **逻辑提交** \- 创建有意义的提交历史记录 13. **创建 PR** \- 使用线性链接生成全面的拉取请求 14. **最终验证** \- 确认 CI/CD 管道和线性集成 ## 工作流程实施细节 ### 第 1 步：获取线性问题详细信息使用 Linear MCP 工具检索完整问题： mcp__linear__get_issue(id: <问题 ID>) 提取关键信息： * 标题和描述 * 当前状态和优先级 * 建议的 git 分支名称（`branchName` 字段） * 团队和项目背景 * 附件或相关作品 * 标签和指定的团队成员 ### 第 2 步：收集更多背景信息在规划之前，从多个来源收集相关背景信息，为实施方法提供信息。 #### 搜索黑曜石宝库搜索可能与此问题相关的任何现有注释： # 按问题 ID 搜索在黑曜石金库中搜索：“TRA-142” # 按问题摘要/关键字搜索在黑曜石保险库中搜索：“<问题标题/描述中的关键字>” 寻找： * 之前讨论此功能的会议记录 * 架构决策或技术说明 * 类似工作中的相关实施说明 * 用户研究或需求文档 #### 获取哨兵上下文（如果引用）如果线性问题引用任何 Sentry 问题或错误跟踪： mcp__sentry__get_issue(issue_id: <哨兵问题 id>) 哨兵摘录： * 错误堆栈跟踪和频率 * 受影响的用户和环境 * 相关事件和面包屑 * 任何现有的评论或作业此上下文有助于理解： * bug的根本原因 * 哪些代码路径受到影响 * 问题发生的频率 * 需要考虑的环境因素 #### 获取 GitHub 上下文（如果引用）如果线性问题引用 GitHub 拉取请求、问题或讨论： # 查看PR详情和讨论 gh pr 查看 # 查看 PR 评论和评论主题 gh pr view --comments # 查看问题详情 gh 问题视图 <问题编号> # 查看问题评论 gh 问题视图 <问题号> --comments 摘自 GitHub： * 之前的实施尝试 * 审查反馈和提出的问题 * 设计讨论和决策 * 相关代码更改或上下文 **上下文摘要：** 收集上下文后，总结一下： * 在黑曜石中找到相关信息 * Sentry 错误详细信息（如果适用） * GitHub 讨论见解（如果适用） * 这种背景如何影响实施方法 ### 步骤 3：将问题移至进行中更新问题状态以反映积极的开发： 1. 从问题中识别团队 ID 2. 使用 `mcp__linear__list_issue_statuses(team: )` 检索“进行中”状态 3. 使用 `mcp__linear__update_issue(id: , state: )` 更新问题这为团队成员提供了工作已经开始的可见性。 ### 步骤 4：创建功能分支使用 Linear 建议的分支名称以保持一致性： # 确保主要且最新 git checkout 主要 git pull origin 主要 # 从 Linear 的branchName字段获取分支名称 BRANCH_NAME="<来自线性分支名称字段>" # 如果有新分支则创建分支，如果存在则签出（幂等） git checkout -b "$BRANCH_NAME" 2>/dev/null || git checkout“$BRANCH_NAME” # 验证分支是否正确 git 分支 --显示当前该模式确保： * 现有分支的重用 * 一致的线性建议命名 * 幂等操作（可以安全地重新运行） * 始终从最新的主版本开始工作 ### 步骤 5：分析和规划解决方案将问题分解为可行的实施计划： **分析过程：** 1. 从问题描述中提取具体需求 2. 识别受影响的组件和系统 3.确定测试策略（单元→集成→系统） 4. 按照项目模式规划实施方法 5. 识别潜在风险和依赖性 **规划输出：** * **目标**：明确说明实施目标 * **要求**：具体功能和技术要求 * **架构**：解决方案如何适应现有代码库（模型、服务、控制器） * **测试策略**：全面测试，包括系统规格 * **实施步骤**：开发任务的有序列表 * **验收标准**：完成的定义 ### 第 6 步：将计划保存到内存中使用内存MCP工具存储实施计划： mcp__memory__create_entities（实体：[ { name: "线性问题 ", 实体类型：“实施计划”，观察结果：[ “要求：<要求>”， “架构：<架构决策>”， “测试策略：<测试方法>”， “状态：计划完成” ] } ]）这将创建永久跟踪： * 问题背景和要求 * 实现思路及推理 * 整个开发过程中的进步 * 为今后的工作吸取的经验教训 ### 第 7 步：与用户一起审查计划提出完整的计划以供确认： **计划介绍：** * 将实施的内容摘要 * 关键技术决策和理由 * 测试策略和预期覆盖范围 * 估计的复杂性和已识别的风险 * 明确的确认请求 **用户选项：** * 批准继续实施 * 请求修改方法 * 添加要求或约束 * 提出澄清问题 ### 步骤 8：测试驱动开发实施批准后，调用 TDD 工作流程技能：使用以下命令调用技能工具：tdd-workflow TDD 工作流程技能强制执行： * 红-绿-重构循环 * 测试金字塔策略（单元→集成→系统） * 在实施之前编写测试 * 全面的测试覆盖范围，包括系统规格 **预期结果：** * 新功能的完整测试覆盖率 * 遵循项目 POODR 原则实施 * 可能失败的操作的结果模式 * 干净、可维护的代码结构 ### 步骤 9：并行子代理代码审查实现后，调用并行代码审查技能：使用以下命令调用 Skill 工具：parallel-code-review 这会同时启动专门的审核子代理： **安全审查：** * OWASP 十大漏洞 * 多租户安全（ActsAsTenant验证） * XSS、CSRF、SQL注入预防 * 身份验证和授权检查 * 敏感数据处理 **Rails 最佳实践回顾：** * POODR 原则（SRP、依赖管理、Tell Don't Ask） * Rails 7+ 约定 * N+1查询预防 * ActiveRecord优化 * 服务对象模式 * 结果模式的使用 **前端审查（如果适用）：** * ViewComponent最佳实践 * Tailwind CSS 约定 * StimulusJS 模式 * 辅助功能（ARIA 属性） **输出：** * 综合审查报告 * 决策跟踪以防止冗余 * 根据严重性和影响对反馈进行优先排序 ### 第 10 步：处理审核反馈调用代码审查实施者技能：使用以下命令调用技能工具：code-review-implementer 该技能系统地处理反馈： **流程：** 1. 根据影响和努力来解析反馈并确定其优先级 2. 识别常见的重构模式 3. 通过测试验证逐步实施修复 4.确保向后兼容性 5. 根据需要更新文档 **架构反馈是强制性的：** * 如果控制器/模型有太多职责，则提取服务对象 * 对可能失败的操作应用结果模式 * 重构以提高可测试性和可维护性 * 为新的服务对象添加全面的规范 **注意：** 在实施所有架构反馈之前，请勿创建 PR。 ### 第 11 步：验证和质量保证在创建提交之前，确保一切都通过： **验证步骤：** # 运行完整的测试套件捆绑执行 rspec # 运行 linting（标准、ERB、Brakeman）垃圾箱/棉绒 # 修复任何失败或警告 # 验证系统规格在干净的环境中通过 **质量检查：** * 代码遵循项目 POODR 原则 * 正确使用结果模式 * 无安全漏洞 * 考虑性能影响（无N+1查询） * 所有子代理反馈均得到解决 * 测试覆盖率足够 **检查注释：** * 如果仅在 Rails 代码上工作，则可以忽略 Yarn 故障 * 关于 `MigeratedSchemaVersion` 和 `ContextCreatingMethods` 的警告是无害的 * **必须解决实际违规问题**（查找文件路径和行号） ### 第 12 步：创建逻辑提交创建有意义的提交来讲述实施故事： **承诺策略：** 1. **测试提交**：添加新功能的失败测试 2. **实现提交** ：添加代码以使测试通过 3. **重构提交**：改进代码结构 4. **安全修复**：解决安全审查反馈 5. **模式改进**：实施 OOP/Rails 模式建议 6. **文档提交**：如果需要更新文档 **提交消息格式：** 50 个字符以内的现在时摘要 - 如有需要，请提供详细说明（每行 72 个字符以下） - 参考已处理的审核反馈 - 注意任何重大更改或迁移要求线性问题：<线性问题 URL> 使用克劳德代码实现 **使用heredoc进行正确的格式化：** git commit -m "$(cat <<'EOF' 添加用户通知服务 - 从控制器中提取通知逻辑 - 应用结果模式进行错误处理 - 添加带有边缘情况的全面 RSpec 测试线性问题：https://linear.app/company/issue/TRA-142 使用克劳德代码实现 EOF ）” ### 第 13 步：创建拉取请求通过线性积分生成全面的 PR： **PR 创建命令：** gh pr create --title "<简洁标题>" --body "$(cat <<'EOF' ## 总结 - 实施内容的简明要点 - 做出的关键技术决策 ## 实施细节 - 使用的架构方法和模式 - 添加或修改的服务/模型/控制器 - 数据库更改（如果适用） ## 测试策略 - 添加了测试覆盖范围（单元、集成、系统） - 涵盖边缘情况 - 进行手动测试 ## 代码审查流程 - 安全审查结果和决议 - Rails 最佳实践审查结果和解决方案 - 解决了性能考虑因素 ## 重大变更 [无或列出任何重大更改] ## 线性问题关闭<线性问题 URL> --- 使用 Claude Code 实施，遵循 TDD 方法并进行并行代码审查。 EOF ）” **公关描述包括：** * 实施总结 * 技术方法和关键决策 * 测试策略和覆盖范围 * 代码审查结果和解决方案 * 解决安全考虑 * 重大变更或迁移说明 * 屏幕截图/演示（如果适用） **线性积分：** * 在 PR 正文中包含 `Closes ` * PR合并时Linear自动链接并更新问题状态 ### 第 14 步：最终验证验证 PR 设置和完成： **最终检查：** * ✅ CI/CD 管道成功触发 * ✅ 线性问题链接和更新 * ✅ 所有测试均在 CI 环境中通过 * ✅ 通知代码审查受让人 * ✅ 满足分支保护规则 * ✅ 记录安全和模式审查 **完成摘要：** 向用户展示清单： * ✅ 分析和规划线性问题 * ✅ 使用 TDD 实现的解决方案 * ✅ 添加了全面的系统规格 * ✅ 安全审核已完成 * ✅ Rails/OOP 模式审核已完成 * ✅ 所有评论反馈均得到解决 * ✅ 所有测试和 linting 通过 * ✅ 创建逻辑提交历史记录 * ✅ 通过线性积分创建 PR ## 与其他技能的整合该技能协调多种专业技能： **tdd 工作流程：** * 强制红-绿-重构循环 * 确保测试优先的开发 * 指导测试金字塔策略 **并行代码审查：** * 同时运行安全和 Rails 审查 * 整合调查结果以避免冗余 * 提供优先反馈 **代码审查实施者：** * 系统地处理所有反馈 * 应用常见的重构模式 * 通过测试验证修复 ## 项目特定约定该技能遵循“CLAUDE.md”的项目指南： **导轨图案：** * 业务逻辑的服务对象 * 可能失败的操作的结果模式 * POODR 原则（SRP、告诉不要问、迪米特定律） **多租户安全：** * ActsAsTenant 自动范围界定 * 租户隔离验证 * 查询中不需要明确的租户范围 **测试：** * RSpec 与 shoulda 匹配器 * 用户工作流程的系统规格 * 避免对被测系统进行存根操作 * 使用后门中间件在请求规范中进行身份验证 **代码风格：** * i18n 适用于所有面向用户的文本 * 时间戳列而不是布尔值 * 用于静态值的 Postgres 枚举 * `ENV.fetch` 获取所需的环境变量 ## 要求 **线性 MCP 集成：** * 线性 MCP 服务器必须已配置且可用 * 所需工具：`mcp__linear__get_issue`、`mcp__linear__update_issue`等 **Git 存储库：** * 当前目录必须是git仓库 * `main` 分支存在并且是最新的 * 使用用户凭据配置 Git **测试和检查：** * `bundle exec rspec` 可用于测试 * `bin/lint` 脚本可用于 linting * 配置Ruby/Rails开发环境 **GitHub CLI：** * 安装并验证了 `gh` CLI 工具 * 配置用于 PR 创建的存储库 **技能：** * 可用“tdd-workflow”技能 * 可用“并行代码审查”技能 * 可用的“代码审查-实施者”技能 ## 错误处理 **常见问题和解决方案：** **未找到线性问题：** * 验证问题 ID 格式（例如“TRA-9”，而不是“tra-9”） * 确认 Linear MCP 集成正常工作 * 检查用户是否有权访问团队/问题 **分支已存在：** * 预期行为 - 工作流检查现有分支 * 确保工作能够安全恢复 * 验证分支是否与远程同步 **测试或 Linting 失败：** * 在创建 PR 之前检查故障并修复 * 常见 lint 问题：StandardRB、ERB Lint、Brakeman * 切勿盲目使用 `standardrb --fix` - 检查更改 **代码审查发现问题：** * 必须在 PR 之前解决架构反馈 * 根据推荐提取服务对象 * 在建议的地方应用结果模式 * 仅在实施所有反馈后才创建 PR ## 工作流程示例 **用户请求：** 实施 TRA-142 **技能反应：** 1. 从 Linear 获取 TRA-142 2. 收集额外的背景信息： * 在黑曜石金库中搜索“TRA-142”和相关关键字 * 获取 Sentry 问题详细信息（如果在线性问题中引用） * 检索 GitHub PR 讨论（如果在线性问题中引用） 3.将问题更新为“进行中” 4. 创建分支 `dg/tra-142-user-notification-service` 5. 分析需求并制定计划（根据收集的背景信息） 6. 将计划保存到内存图表 7. 提出计划：“这将使用结果模式为用户通知创建一个新的服务对象......” 8. **等待用户批准** 9. 批准后，调用“tdd-workflow”技能 10. 实施后，调用“并行代码审查”技能 11. 评论确定：“将通知逻辑提取到服务对象，应用结果模式” 12.调用“代码审查-实施者”技能来解决反馈 13. 运行验证：`bundle exec rspec` ✅、`bin/lint` ✅ 14. 使用正确的消息创建逻辑提交 15. 创建具有全面描述和线性链接的 PR 16. 提交完成清单 **最终输出：** * 具有完整实现的工作功能分支 * 所有测试均通过 * 所有 linting 都通过 * 全面的公关与线性整合 * PR合并时问题自动更新 ## 最佳实践 **规划阶段：** * 花时间充分理解需求 * 识别边缘情况和错误情况 * 考虑多租户影响 * 规划全面的系统规格 **实施阶段：** * 严格遵循 TDD - 在代码之前进行测试 * 保持提交小而合乎逻辑 * 编写自文档化代码 * 对所有面向用户的文本使用 i18n **审核阶段：** * 解决所有架构反馈 * 不要跳过推荐的重构 * 通过测试验证修复 * 考虑性能影响 **公关创建：** * 撰写全面的描述 * 文件审查结果和决议 * 包括手动测试说明 * 确保线性链接正确 **质量门：** * 永远不要用失败的测试来创建 PR * 切勿创建带有 linting 错误的 PR * 切勿在未解决架构反馈的情况下创建 PR * 切勿跳过验证步骤

线性工具

包含技能