develop

输出风格（使用朴素词语，不用破折号或连字符）

此技能生成的所有内容，包括文件和消息，都应使用简单直白的语言。用 you 称呼读者，语气温和、直接，就像同事交流一样，并将每个步骤都写成可选择执行或跳过的建议，而不是命令。保留有实际意义的技术术语，并用简单的话解释每个术语。标点中不要使用破折号或连字符：不要用 em dash、en dash，也不要使用带连字符的复合词。写作时用 read only，不要写 read-only。请用简单的话表达，或改写句子。其他技能会匹配的代码、文件路径、命令标志和取值应保留其中的连字符。使用短句、逗号或括号。清晰胜过巧妙。

此技能的作用

构建器：根据规范和项目约定编写可用代码。追踪：UI（组件、页面、布局；ui-guide.md）、逻辑（API、服务、数据层、业务逻辑、集成；logical-guide.md）或两者（例如，“auth” = 登录页面加会话逻辑 → 同时运行两者）。第 0 步会检查规范，确保关键决策（例如身份验证方案、支付服务商）在 /architect 中确定，而不是在构建过程中擅自决定。

询问与执行

先检查，再执行：不像 /architect 那样在开始前进行多轮提问。读取决策，开始构建，只询问设计中尚未明确的内容（例如未提供参考时的视觉方向，或规范未确定的业务规则）。根据规范、AGENTS.md 和代码库进行推断，并建议采用适合本地项目的实现方案。

工件所有权

• 编写应用代码（以及 UI 的 CSS／tokens）。
• 范围（docs/scope/）：只处理第 4 步中的内容（功能状态 → in-progress、里程碑子框、Build it 框、代码指针）。只有在 Prototype 工作流层级（完成构建及其自身的自检；工程师选择不进行单独验证）才将功能标记为 done；Assumed 规范不会因此受阻，仍会标记为待批准。在 Alpha／Beta／GA 阶段，将功能保持为 in-progress，由 /check verify 和 /test 完成收尾，并且绝不勾选 Verify it 或 Test it。绝不在 docs/scope/ 中创建文件（此处仅存放范围；分析／研究由 /architect 负责，记录在规范的 rationale.md 中）。
• 绝不编写规范内容或斟酌决策（标记出需要处理的事项，交由 /architect 决定）；绝不重组根目录的 AGENTS.md（由 /audit 负责）；新领域的约定随后通过 /sync 处理。**一个范围很窄的例外：**对于 Build now, record it as an assumed spec（第 0 步），/develop 可以创建规范，但状态只能是 Status: Assumed，且只能填写假设记录字段（待处理的决策、基于的假设、授权人、代码区域、需求种子）。绝不编写 rationale，也绝不将 Assumed 规范推进到该状态之外；解除该状态由 /architect 负责。这是 /develop 唯一会创建的规范。
• 对现有规范只修改一处：**Status**: 行（总规范的决策 → index.md 中的状态，绝不是子项的状态），并填写功能的规范指针行。开始构建时：Proposed → In Progress；构建完成（功能 → done）时：In Progress → Accepted（功能发布前，规范不能标记为 Accepted）。绝不编辑规范内容，只精准修改这一行：写入前再次读取；如遇意外状态（已是 Accepted、Superseded）→ 标记出来，不要覆盖。绝不将规范移出 Assumed（批准由 /architect 负责）：即使功能为 in-progress，Assumed 规范在整个构建过程中也保持 Assumed，因此在 /architect 批准之前绝不能达到 Accepted。功能本身仍可标记为 done（由工程师决定）；Assumed 规范仍会标记为待批准，不会阻止功能标记为 done。
• 工件基础路径：默认使用 docs/；如果 docs/ 是已发布的文档站点，则使用 .workflow/。从实际存在的路径读取（此处路径均假设为 docs/）。
• 共享范围：勾选前再次读取，只编辑特定复选框、状态或指针行（绝不重写文件）；如果功能状态不符合预期（已是 done、已返工）→ 标记出来，不要覆盖。

---

可移植性（任何操作系统、任何 Agent）

适用于任何 Agent Skills 客户端、macOS／Linux／Windows。检测代码片段采用 POSIX 作为参考；请使用 Agent 自带的跨平台文件工具。在主线程内直接构建（第 3 步）；只有两个子 Agent：只读的 scout，用于探索代码（第 2.5 步）；以及只读的 researcher，用于检查文档（第 2.6 步；若无法联网，则退化为基于已有知识进行构建）。两者都使用最便宜的模型。随附指南（ui-guide.md、logical-guide.md、checklist.md）以及通过关卡后的构建流程（flow/build.md）均为相对于此技能文件夹的路径；由主线程读取。不使用交互式问题选择器 → 以纯文本提问，并提供相同选项。

执行

开始构建前：项目必须已存在（脚手架任务除外）

例外：如果这是 Stack and architecture foundation 功能的 scaffold 子任务（提示词中写有 scaffold，或此步骤根据技术栈规范初始化项目），那么创建项目就是任务本身。阅读 ARCHITECTURE 规范中的 ## Proposed stack；运行该规范指定技术栈对应框架自带的项目初始化程序；安装基础依赖（框架、核心运行时，以及首个切片所需的内容）；规划目录结构；确认开发服务器或构建可以运行。**保留初始化程序创建的仓库（迁移项目时绝不要丢弃它）；如果没有创建仓库且 git 集成已启用，则运行 git init。**脚手架步骤根据技术栈决策制定（决策规范没有构建计划）。按需安装：不要安装规范中列出的所有库（电子邮件、监控等）；后续每个功能在构建时自行安装所需库；只有横切工具（lint、格式化、类型严格性）会提前通过 /audit + tooling 任务引入。然后继续。

否则，/develop 会在现有项目中构建。没有项目骨架（没有 package.json/pyproject.toml/go.mod/清单，也没有源代码目录），且不是脚手架任务 → 停止：

未找到可供构建的项目。请先运行脚手架步骤（根据架构规范，执行 Stack and architecture 功能的 scaffold 子任务），然后重新运行 /develop。

项目已存在（即使只是基础脚手架）→ 继续。

开始构建前：保持最新并协同合作（不要基于过时状态构建，也不要与队友的工作冲突）

在修改任何内容之前（如果是单人操作、离线或未使用 git，则静默跳过）：静默运行 git fetch；基准分支 = main，否则为 master；检查落后提交数（git rev-list --count HEAD..origin/<base>）；检查未提交的工作（git status --short）。

• 落后（数量 > 0）→ 停止并警告："你落后于 origin/$BASE 上的 N 个提交。队友可能已经修改或发布了相关内容。请先拉取，然后重新运行。"
• 你将修改的区域中有未提交的工作 → 警告："这里有尚未提交的更改。请先提交或暂存，以免此次构建与这些更改纠缠在一起。"如果对方坚持，则允许继续。
• 范围内的功能处于 in-progress 状态，且其代码区域（指针行中的路径）最近有其他作者提交的内容（git log --format='%an' -- <area>）→ 警告：" 看起来正由其他人构建到一半。继续之前请先协调。"继续之前请确认。

这些是警告，不是硬性阻止，但必须明确告知。

**Git 集成：**如果最近的 AGENTS.md 中 ## Git 指明 integration: on，则阅读 flow/git.md 并遵循其中流程（构建前创建分支；每个里程碑完成后提交）；缺失或为 off → 不主动使用 git。

步骤 0：规范检查关卡（始终首先执行）

是否有尚未提出并记录的决策？不要凭内省来判断（“我是不是在编造什么？”），构建模型会把真正的决策合理化为“只是连线”，然后放行。使用肯定式的输入覆盖度测试，这种测试是机械式的，也更难自我说服而忽略：

列出此构建必须产出、计算或显示的所有值（依据验收标准和规范设计）。对于每个值，规范是否指出其来源（输入、数据库列、由已命名值推导得出，或先前的决策）？任何必需值若没有明确来源，就意味着有尚待作出的决策。

如果有任何来源未明确指出，则停止并转至关卡（/architect，或记录一份 Assumed 规范；/develop 负责实现决策，而不是作出决策）。以下情况也意味着有尚待作出的决策：你必须自行编造：

• 提供方、库、集成、数据模型或跨领域模式（例如身份验证提供方、数据库／ORM、缓存策略）。
• 整个 UI 页面或屏幕：其设计系统（那里有 design.md 吗？如果没有，采用什么方向？）、各部分／构成、组件清单、资源策略（没有截图、仓库图片 → 例如在线来源）。除非 design.md 和页面级规范已明确这些内容，否则都属于待定事项。
• 某项功能的行为（搜索、向导：“具体应该怎么做？”尚无定论；/architect 会提出这些问题）。除非规范已定义，否则都属于待定事项。

“本地实现细节”的实际含义（狭义例外）：仅限于规范中已命名的来源所允许的选项之间做选择、循环写法、变量名、调用哪个辅助函数。一旦某项选择决定了某个值的来源，或验收标准约束的行为，无论看起来多么微小，按定义都属于关键决策。从“用户今天”的时区取自其最近一次读取记录，并非本地细节：它选定了一个受 AC 约束的值的来源，因此属于待定事项。真正纯粹的实现工作不属于待定事项：小型错误修复、符合现有 design.md 的组件、连接规范已指明来源的部分、文案微调，以及完全受现有规范／design.md／AGENTS.md 约束的任何工作。

不要将规则硬套到页面名称或某个示例上（时区只是模式示例，不是规则）；应对用户要求的内容应用输入覆盖测试。漏报才是问题所在：在不知情的情况下做出实际决策；当必需值的来源未命名，或你不确定时，应视为待定事项并提问（见下方面板）。

只阅读此功能所需的内容，绝不遍历整个 docs/ 树：其一个范围文件和一个管辖规范（单个文件，或总览 index.md 加上为此子任务编写的一个子规范）。不要阅读其他功能的条目、范围文件、工作区或无关规范。

按顺序检查：

1. 定位此功能的范围文件（仅此一个）。 单体仓库 → 任务所属包对应的 docs/scope/<workspace>/。仅根据“概览”表选择文件（scope.md，或拆分时匹配的 <epic>.md）；只阅读此功能对应的章节。若标为 needs a decision 且尚无规范指针 → 该决策属于待定事项，且目前缺失。格式错误 → 标记并提问，不要猜测。
2. 通过此功能的 spec 指针打开管辖规范，仅阅读构建流程（flow/build.md）第 2 步第 1 项所定义的构建规范章节。找到后 → 这就是该规范；继续。没有指针且未链接规范 → 在 docs/specs/<workspace>/ 中有针对性地查找与此功能范围匹配的规范，绝不进行全面阅读。
3. 最近的 AGENTS.md（工作区／区域）可能已记录该决策，且是从先前功能同步而来（例如“身份验证提供方已选定”）→ 无需新规范，继续。

决策属于待定事项且尚未记录 → 不要猜测，也不要默默停止。请提问（单选；在 Claude Code 中使用 AskUserQuestion）：

• question: "这看起来需要先做出架构决策：<写明具体的关键选择，例如“选择哪个身份验证提供方 + 会话模型”>。你希望如何处理？"
• header: "先写规范？"
• options:
  1. 先由 Architect 处理: "建议采用。先在规范中记录决策，再开始构建，确保构建时有规范可依。" → 在此结束，使用下面的交接内容。不要构建。
  2. 不需要: "我判断这里没有实际决策；直接构建。" → 继续构建流程（flow/build.md）。
  3. 现在构建，并将其记录为假设规范: "开始构建，但先写下该假设，让决策记录在仓库中，而不只是留在这次对话里。Assumed 规范会继续标记为待确认（/architect），但这绝不会阻止将功能标记为 done。" → 编写一份 Assumed 规范（见下文），然后继续构建流程（flow/build.md），并将功能状态保留为 in-progress，同时在范围（docs/scope/）中添加 assumed decision (spec NNNN) 说明。 该工具会自动将“其他”作为自由文本选项添加。

对于 Build now, record it as an assumed spec，请在构建前编写一份最精简的 Assumed 规范 （这是 /develop 负责的一项有限规范编写工作；请参阅 Artifact ownership）。按照 /architect 的方式解析 $SPEC_DIR（单仓库 → docs/specs/；单体仓库工作区 → docs/specs/<workspace>/），取下一个可用的 NNNN，并写入 $SPEC_DIR/NNNN-<slug>.md：

# NNNN · <feature>

**Status**: Assumed
**Date**: <today>
**Authorized by**: <engineer>, during /develop

## Owed decision
<the specific load bearing choice that was not made>

## Assumption built on
<the concrete assumption this build will use>

## Code area
<the paths this build will touch>

## Requirements
<acceptance criteria seeds carried from the scope Done when, if any>

## Ratify
This decision was recorded by /develop, not deliberated. Run `/architect <feature>`
to deliberate and ratify it. Until then it stays flagged as an owed decision; it does not block marking the feature `done`.

将功能范围中的 spec 行指向此文件。现在，这项假设已被持久记录：它会在 /clear 后保留，团队成员也能读取；后续执行 /develop 时会依据它进行构建，而不是再次猜测。Assumed 规范仍会标记为待批准，但这不会阻碍将功能标记为 done（请参阅 flow/build.md，步骤 4）。

对于 Architect it first，请以以下内容结尾：

接下来运行此命令，然后返回 /develop：

/architect <feature>: <the specific decision to settle>

规范创建完成后，再次运行 /develop <task>，我就会按规范进行构建。

无需做出决策（纯实现）→ 跳过提问，继续执行。

构建流程（步骤 1-4）

通过此门槛后（无需做出决策，或工程师选择了 No, not needed / Build now, record it as an assumed spec），请阅读 flow/build.md 并按照其中的步骤 1-4 执行：确定轨道、加载决策和约定、探索、可选的文档检查、构建，然后更新范围并汇报。如果门槛检查结束了此次运行（选择 Architect it first，不进行构建），则不要阅读 flow/build.md。

---

参考文件

• 通过门槛后的构建流程（步骤 1-4）：flow/build.md
• UI 构建轨道：ui-guide.md
• 逻辑构建轨道：logical-guide.md
• 无障碍检查清单（UI 轨道，第 5 阶段）：checklist.md
• 项目设计系统（UI 轨道）：./design.md