mcpField
S
sdlc-apply

sdlc-apply

github.com/acourtiol开发039 次安装3 周前更新
代码仓库

关于 sdlc-apply

sdlc-apply 是在仓库中实现已接受开发意图的技能。它指导编码 Agent 分解变更、收集验证证据、提交代码并交由审查和用户验收,不会自行推送或部署。

主要功能

  1. 01实现前要求意图已接受
  2. 02将工作拆分为检查并提交的步骤
  3. 03保留其他贡献者未提交的变更
  4. 04规定测试和迁移的证据要求
  5. 05将完成的变更交给 sdlc-verify

适用场景

  1. 01实现包含验收标准的变更
  2. 02验证数据库迁移并保留现有数据
  3. 03准备经过审查、待用户验收的候选变更

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/acourtiol/ai-sdlc --skill sdlc-apply

安装后在 Claude Code 中输入/sdlc-apply确认已加载。

详细介绍

sdlc-apply

实现已接受的意图所要求的内容,展示其运行效果,并让用户验收。除非用户要求,否则不要推送或部署。

需要有 intent/<slug>/intent.md,且其 status: accepted(对于 tier: critical,验收还必须包括其 ## Spec)。如果仍有会改变架构、安全性或验收标准的选项未定,请向用户提一个问题;否则说明你的假设并继续。

工作约定

  • 工作区。 默认在当前检出中一次处理一个意图。相互独立的意图(文件不重叠、没有共享契约或迁移顺序依赖)可以并行处理,每个意图使用一个工作树,路径为 $(git rev-parse --show-toplevel)/.worktrees/<slug>,位于仓库内,且绝不放在存放项目的文件夹中(如果未被忽略,请将其加入 .git/info/exclude;只锚定一次根目录,绝不嵌套)。验证通过后,通过快进或变基合并到主分支。不要使用集成分支。工作树不等于隔离:并发运行的服务需要各自的数据库、compose 项目和端口,使用产品现有的工作树配置。
  • 子 Agent。 当只读调研或互不相关的并行工作能节省实际耗时或主上下文空间时,使用子 Agent,并为每个子 Agent 设定明确且有限的目标。不要派出一群 Agent;协调本身也有成本。
  • **重启或中断后,**继续之前重新读取 intent.md、git status 和已勾选的步骤。之前派发过任务不代表工作已经完成。
  • 所有权。 写入之前记录 git status --short。其他人修改过且未提交的文件归其所有;绝不要重置、暂存或提交这些文件。
  • YAGNI。 优先复用现有代码和模式,其次使用已安装的依赖或平台能力。只有在明确存在缺口时才添加依赖或抽象。保留验证、错误处理、安全性和无障碍支持。
  • 不增加未要求的范围。 不新增用户未要求的屏幕、必填输入项或关卡。如果看起来确有必要,请先停下并说明权衡。
  • 提交。 每个连贯步骤提交一次,并在同一提交中勾选该步骤的复选框以及提交其代码。遵循 Conventional Commits:type(scope): imperative summary,空一行,再用一句话说明原因。不要只为记录验证结果而提交。

步骤

  1. 阅读 intent.md,并在其 frontmatter 中记录 base: <HEAD hash>(与第一步一起提交)。如果 ## Steps 为空或内容含糊,现在就写好步骤:拆分成少量连贯的切片,每一步都要有 check:。按风险边界优先验证的顺序排列。
  2. 对每一步:实现、运行检查,确认检查通过后再勾选复选框并提交。
  3. 证明必须覆盖真实路径,而非替代方案:
    • 管道中新增或变更的输入,必须在实际使用处(发出的请求或消费者)断言,而不能只验证其存储位置。
    • 对有状态或异步流程,失败、重试和重新加载后都要检查持久化状态,而不能只检查即时响应。
    • 对架构变更,在一次性数据库上从之前已应用的迁移状态升级,并证明已有行得以保留。新建数据库通过检查还不够。绝不要编辑已应用的迁移。
    • 确认测试运行器确实会发现所依赖的测试(组件测试及其他扩展)。
    • 绝不要针对生产数据库或共享默认数据库运行检查。在执行任何会造成修改的操作之前,确认连接目标。
  4. 完成最后一步后,运行类型检查、lint 和受影响的测试。对于 UI,在本地运行的应用中操作主流程及一条错误流程,并保存截图或 DOM 摘录的路径。
  5. 在 intent.md 的 ## Result 中填写结果:每条 Acceptance 项目占一行,标注 PASS 或 FAIL 并附上证据,同时注明任何未检查的项目。FAIL 或未检查的必需项目必须如实报告,不能隐瞒。
  6. 提交已完成的候选结果,并交给 sdlc-verify(两个层级都要执行)进行验证。根据发现的问题修复并创建新提交,然后重新审查。
  7. 向用户呈现 Result 并汇报。由用户验收。

关闭(仅在验证通过且用户接受后)

顺序固定:应用、sdlc-verify(report.md 中包含 verdict: pass)、用户接受,然后关闭。切勿在最后一步后直接关闭。关闭操作记录用户接受;不表示已发布。

检查:各步骤均已勾选,## Result 中没有未解释的 FAIL,report.md 验证通过,且自验证后经审查的文件未发生变化(git diff --quiet <reviewed_head> HEAD -- $(git diff --name-only <base> <reviewed_head> -- . ':(exclude)intent');期间其他提交落地不影响此项),除非用户放弃审查,或对于没有独立审查途径的 change 层级,用户接受“未经独立审查”。然后删除文件夹并将故事保留在历史记录中:rm -rf intent/<slug> && git add -A intent/<slug>,提交 chore(<slug>): close intent,正文包含 Result 中的各行(每个 Acceptance 项一行),以及任何尚未解决的审查者发现。文件夹存在时,intent 即为开放状态;已完成的 intent 可通过 git log --diff-filter=D --format='%h %s' -- intent/ 列出,并通过 git show <commit>^:intent/<slug>/intent.md 查看。如果项目有知识包,且此工作取代了一条持久笔记,请通过相应工作流更新知识包。不要推送。

同类失败发生两次后,停止重复执行完整门禁,改为针对性复现失败。如果工作最终需要不同的结果,请与用户一起更新 intent,而不是偏离它。

评论

支持 Markdown