Documenso AI 开发命令 continue.md 深度解析：跨会话规格续接与自主工程闭环

Documenso AI 开发命令 continue.md 深度解析跨会话规格续接与自主工程闭环【免费下载链接】documensoThe Open Source DocuSign Alternative.项目地址: https://gitcode.com/GitHub_Trending/do/documensocontinue.md是 Documenso 仓库中 OpenCode 自定义命令slash command之一专门用于“接续上一次会话未完成的功能规格实现”。它把“读规格 → 评估现状 → 补齐差异 → 类型检查/静态检查/E2E 测试”固化成一套可重复执行的自主工作流。读完本文你能完整理解该命令的指令契约、每一步检查命令在仓库中的真实落点Biome、tsc、Playwright 等以及它与implement.md、.agents/plans/规格目录共同构成的 AI 协作开发链路。命令定位为什么需要“continue”而不是重新“implement”Documenso 为 AI 编码代理准备了一套 OpenCode 命令位于 .opencode/commands/ 目录包括 implement.md、commit.md、create-plan.md、create-scratch.md、create-justification.md、create-documentation.md、interview.md 等而 continue.md 是其中“续接型”命令。对照 implement.md 可以看出两者的分工implement 面向全新规格流程是“读规格 → 用 TodoWrite 拆任务 → 直接实现”而 continue 额外强制了两个前置动作——评估当前状态Assess current state和对照规格确定剩余工作Determine what remains。这解决的正是长会话被中断后的典型问题AI 不知道上一次会话写到了哪里、哪些代码已经存在、哪些还是半成品。Frontmatter 指令契约description 与 argument-hintcontinue.md 文件头部的 YAML frontmatter 定义了命令的元信息--- description: Continue implementing a spec from a previous session argument-hint: spec-file-path ---description用于在命令列表中展示该命令的用途从上一次会话续接一份规格spec的实现。argument-hint: spec-file-path表明调用时需要传一个参数规格文件的路径。正文中的$ARGUMENTS占位符会被该实参替换例如“Read the spec at$ARGUMENTS”即“读取 你传入的路径 处的规格文件”。从源码结构看规格文件通常来自仓库的 .agents/plans/ 目录——其中存放着十余份以“三词 ID 功能名”命名的规格文档如 bright-emerald-flower-bullmq-background-jobs.md、smooth-coral-earth-database-rate-limiting.md均带date与title的 frontmatter并包含 Context、Current Architecture 等章节。这种“计划文件带 frontmatter、正文描述背景与目标架构”的格式正是 continue 命令能够“读取并对照规格”的前提。六步任务流水线从读规格到续接实现文档的核心是 “Your Task” 一节给出的六步流程读取规格读$ARGUMENTS指向的 spec 文件读取 CODE_STYLE.md加载代码格式与模式约定评估当前状态检查 git 未提交改动、跑测试确认通过/失败情况若存在 E2E 测试、审阅已有实现确定剩余工作把规格与当前实现逐项对比找出差距用 TodoWrite 规划剩余任务形成可勾选的任务清单持续实现直至完成。其中第 3、4 步是 continue 区别于 implement 的灵魂。第 4 步隐含了一个“规格即验收标准”的思想spec 中列出的需求就是完成判据实现进度必须逐项回填。评估现状四条命令及其在仓库中的真实落点文档给出的现状检查命令如下git status # See uncommitted changes git log --oneline -10 # See recent commits npm run typecheck -w documenso/remix # Check for type errors npm run lint:fix # Check for linting issues结合仓库实际脚本定义可以逐条核实这些命令的落点git status/git log --oneline -10识别上一次会话遗留的未提交改动与最近提交判断“代码写了一半”还是“已提交推进”。npm run typecheck -w documenso/remix-w表示在 npm workspace根 package.json 声明了workspaces: [apps/*, packages/*]中定位documenso/remix包执行其脚本。查 apps/remix/package.json 可知该包的typecheck定义为react-router typegen tsc——先做 React Router 的类型生成再跑完整 TypeScript 编译检查。这也是为什么续接时必须先跑它Remix/React Router 的路由类型Route.Params、Route.LoaderData依赖 typegen 产物。npm run lint:fix根 package.json 中定义为biome check --write .即由 Biome 对整个仓库做检查并自动修复。修复后再复查可快速抹平格式类差异。文档还要求在跑完命令后通读已有代码回答三个问题已实现什么Whats already implemented、半成品是什么Whats partially done、尚未开始的是什么Whats not started yet。这一步的输出直接决定后续 TodoWrite 里应列哪些任务。实现规范CODE_STYLE.md 与代码质量红线编码期间的规则文档 “During Implementation” 小节规定严格遵循 CODE_STYLE.md2 空格缩进、双引号、大括号必写等遵循 workspace 层对 TypeScript、React、TRPC 模式和 Remix 约定的规则每完成一个任务就勾选 todo按逻辑块logical chunks提交而不是把所有改动堆成一个大提交。CODE_STYLE.md 正文覆盖 TypeScript 约定、导入与依赖、函数、React 组件、错误处理、async/await、空白格式、命名、模式匹配、数据库与 Prisma、TRPC 模式等 12 个章节例如“优先type而非interface”“优先早返回/守卫子句”等AGENTS.md 则补充了 TRPC 路由文件的组织方式每路由一个文件routers/teams/create-team.ts、配套.types.ts、Z[RouteName]RequestSchema命名与 i18n 宏用法。两条规则链互为补充CODE_STYLE.md 管“怎么写”AGENTS.md 管“工程命令与目录约定”。代码质量红线“Code Quality” 小节列出六条硬性要求其中大部分能在仓库中找到对应实现禁止桩实现No stubbed implementations处理边界条件与错误场景错误信息必须带上下文所有 I/O 一律使用 async/await抛错必须使用 AppError 类——对应仓库中的 packages/lib/errors/app-error.ts其中定义了AppErrorCode枚举NOT_FOUND、UNAUTHORIZED、FORBIDDEN、LIMIT_EXCEEDED、RECIPIENT_OUT_OF_TURN等数十种业务错误码AGENTS.md 还进一步要求前端捕获时用AppError.parse(error)解析错误码表单校验用 Zod、表单状态用 react-hook-form——这与代码库中 tRPC 路由普遍使用Zod定义输入 Schema 的做法一致。测试策略只为“非平凡功能”写 E2E文档特别强调“E2E 测试耗时只对非平凡功能写测试”并给出具体规则E2E 测试写在packages/app-tests/e2e/使用 Playwright只测关键用户流和边界场景遵循代码库既有 E2E 测试模式测试名要能自解释琐碎改动简单 UI 微调、小重构直接跳过。仓库结构印证了这一策略packages/app-tests/e2e/ 下按功能域划分了约三十个测试目录envelope-editor-v2/、document-auth/、teams/、webhooks/等API 类测试集中在e2e/api/。packages/app-tests/playwright.config.ts 的配置也解释了“为什么 E2E 昂贵”testDir: ./e2e、fullyParallel: true、workers: 10注释说明 10 个 worker 主要服务 API 测试、CI 下maxFailures: 1且retries: 4本地retries: 1、失败时保留 trace 与 videotrace: retain-on-failure、video: retain-on-failure、actionTimeout: 15s/navigationTimeout: 30s并通过 cookie 关闭动画以保证测试稳定。自主工作流六步循环直至收敛文档的 “Autonomous Workflow” 是 continue 命令的执行引擎要求代理在以下循环中连续工作、不主动中断Implement实现当前 todo 项的代码Typechecknpm run typecheck -w documenso/remix校验类型Lintnpm run lint:fix修复静态检查问题Test非平凡改动则运行npm run test:dev -w documenso/app-testsFix测试失败则修复并重跑Repeat推进到下一个 todo直到清单清空。对照 packages/app-tests/package.json 的脚本定义可验证该循环的测试环节test:dev即NODE_OPTIONS--import tsx playwright test用 tsx 直接跑 TypeScript 用例无需预编译test-ui:dev在其后追加--ui打开 Playwright 的交互式 UItest:e2e则通过start-server-and-test先启动documenso/remix生产服务并等待http://localhost:3000就绪后再跑playwright test $E2E_TEST_PATH支持用环境变量只跑指定路径的用例。停止条件何时报喜、何时求助文档明确划定了两类停止信号避免代理无限循环或擅自扩大范围完成并报告成功Stop and report success当且仅当规格的全部需求已实现Typecheck 通过Lint 通过已编写针对非平凡功能的 E2E 测试通过。停下来求助Stop and ask for help当出现规格存在歧义需要澄清遇到自己无法解决的阻塞问题需要做明显偏离规格的重大决策缺少外部依赖。这套“成功判据可验证typecheck/lint/test 三绿、求助条件显式化”的设计使命令在无人值守场景下既不会提前收工也不会悄悄改需求。命令速查表Commands 小节完整继承文档末端的 Commands 一节提供了完整速查原样整理如下# Type checking npm run typecheck -w documenso/remix # Linting npm run lint:fix # E2E Tests (only for non-trivial work) npm run test:dev -w documenso/app-tests # Run E2E tests in dev mode npm run test-ui:dev -w documenso/app-tests # Run E2E tests with UI # Development npm run dev # Start dev server补充仓库侧的事实注记typecheck由 apps/remix/package.json 定义react-router typegen tsc通过-w documenso/remix定向执行lint:fix由根 package.json 定义biome check --write .test:dev/test-ui:dev定义在 packages/app-tests/package.json文档速查表中列出的npm run test:e2e全量 E2E 套件对应的实现同样位于 app-tests 工作区[AGENTS.md](https://link.gitcode.com/i/a2b33dd5045ad72ce1d50307403aacd2)的 Build/Test/Lint Commands 一节也将其列为标准命令之一npm run dev在根 package.json 中定义为npm run translate:compile turbo run dev --filterdocumenso/remix即先编译 Lingui 翻译产物再用 Turborepo 启动 Remix 开发服务器。在仓库 Agent 工具链中的位置把 continue.md 放回整个工具链中看一条完整的规格驱动开发链路由此拼合create-plan.md在 .agents/plans/ 创建新规格三词 ID frontmatterimplement.md对全新规格从零实现走“TodoWrite 拆解 → 实现 → 类型/静态检查 → E2E”流程continue.md会话中断后先评估 git 状态与测试现状再对照规格补齐剩余工作——本文主题commit.md实现完成后按 Conventional Commitsfeat/fix/refactor等类型祈使句主题行禁止--amend与--no-verify禁止提交疑似密钥文件生成规范提交。也就是说continue.md 承担的是“长任务断点续跑”这一环它以 git 与测试状态为事实源以规格文件为验收标准以 CODE_STYLE.md/AGENTS.md 为风格与工程约束最终把 AI 代理约束在“实现—验证—修复”的收敛循环内直到 typecheck、lint、E2E 全部通过才允许宣告完成。小结continue.md 是 OpenCode 命令参数为规格文件路径$ARGUMENTS核心差异是强制“现状评估 剩余工作判定”两步评估手段是git status、git log --oneline -10、npm run typecheck -w documenso/remixreact-router typegen tsc、npm run lint:fix Biome 自动修复实现约束锚定 CODE_STYLE.md 与 AGENTS.mdAppError 抛错、Zod 校验、async/await、按逻辑块提交测试策略是“非平凡才测”Playwright 用例集中在 packages/app-tests/e2e/配置见 packages/app-tests/playwright.config.ts收敛条件是三重绿灯typecheck / lint / E2E歧义、阻塞、偏离规格、缺依赖则停止并求助。【免费下载链接】documensoThe Open Source DocuSign Alternative.项目地址: https://gitcode.com/GitHub_Trending/do/documenso创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考