输出风格（平实语言，无破折号，无连字符）
本技能产出的所有内容（文件和信息）均使用平实简单的语言。以“你”称呼读者，像同事一样热情直接，将每一步呈现为可以执行或跳过的建议，而非命令。保留有实际意义的技术术语，并用平实的语言解释它们。永远不要使用破折号或连字符作为标点：不包含长破折号、短破折号或连字符复合词。写 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应用。一个狭窄的例外： 在“立即构建，将其记录为假定规范”（第 0 步）时，/develop可以创建一个规范，但仅限于Status: Assumed，且仅包含假设记录字段（待决决策、构建所依据的假设、授权人、代码区域、需求种子）。它从不编写理由，也从不将Assumed规范推进到该状态之后；/architect负责清除它。这是/develop创建的唯一规范。 - 对现有规范的一次更改：
**Status**:行（总体决策 →index.md的，而非子规范的），以及填写特性的规范指针行。构建开始：Proposed→In Progress；构建完成（特性 →done）：In Progress→Accepted（规范直到其特性交付后才Accepted）。永远不要编辑规范内容，只编辑该行，并且精准操作：在写入之前再次读取它；遇到意外状态（已Accepted、已Superseded）→ 标记，不要覆盖。永远不要将规范移出Assumed（那是确认，是/architect的工作）：即使特性处于in-progress，Assumed规范在构建过程中也保持Assumed，因此它永远无法达到Accepted状态，直到/architect确认它。特性本身仍然可以标记为done（由工程师决定）；Assumed规范保持标记为需要确认，不会阻止done。 - 产物基础：默认使用
docs/，如果docs/是已发布的文档站点，则使用.workflow/。从存在的路径读取（此处路径假设为docs/）。 - 共享作用域：在勾选之前再次读取它，仅编辑特定的复选框、状态或指针行（从不重写文件）；特性不符合预期（已
done、已重做）→ 标记，不要覆盖。
可移植性（任何操作系统，任何代理）
任何 Agent Skills 客户端，macOS/Linux/Windows。检测代码片段是 POSIX 参考；请使用您代理自己的跨平台文件工具。在主线程上内联构建（第 3 步）；唯一的子代理是只读的 scout（用于探索代码，第 2.5 步）和只读的 researcher（用于文档检查，第 2.6 步，在没有 Web 能力的情况下降级为从知识构建），两者均使用最便宜的模型。捆绑的指南（ui-guide.md、logical-guide.md、checklist.md）和关卡后的构建流程（flow/build.md）是相对于此技能文件夹的路径；主线程读取它们。没有交互式问题选择器 → 以纯文本形式提问，并附上相同选项。
执行
构建前：项目必须已存在（脚手架任务除外）
例外：如果这是栈和架构基础特性的脚手架子任务（提示说 scaffold，或者步骤从栈规范初始化项目），那么创建项目就是任务。阅读架构规范的 ## Proposed stack；为规范指定的栈运行框架自己的项目初始化器；安装基础依赖项（框架、核心运行时，仅第一块切片所需的内容）；布局目录；确认开发服务器或构建可以运行。保留初始化器创建的仓库（在重新定位项目时切勿丢弃它）；如果未创建任何仓库且启用了 git 集成，则 git init。 脚手架步骤源自栈决策（决策规范没有构建计划）。即时安装：并非规范中列出的每个库（电子邮件、监控等）；每个后续特性在构建时安装自己的库；只有交叉工具（lint、format、类型严格）提前引入，通过 /audit + 工具任务来完成。然后继续。
否则 /develop 会构建到现有的项目中。没有骨架（没有 package.json/pyproject.toml/go.mod/manifest，没有源代码树）且不是脚手架任务 → 停止：
找不到要构建到的项目。请先运行脚手架步骤（根据您的架构规范，执行栈和架构特性的脚手架子任务），然后再次运行
/develop。
项目存在（即使是空脚手架）→ 继续。
构建前：新鲜度与协作（不要在陈旧状态或团队成员之上构建）
在修改任何内容之前（如果是单人工作、离线或未使用 git，则静默跳过）：静默 git fetch；基础分支 = main，否则 master；落后计数（git rev-list --count HEAD..origin/<base>）；未提交的工作（git status --short）。
- 落后（计数 > 0）→ 停止并警告：“您落后于
origin/$BASEN 次提交。团队成员可能已更改或交付了此内容。请先拉取，然后再次运行。” - 在您将触及的区域存在未提交的更改 → 警告：“您在此处有未提交的更改。请先提交或暂存，这样此构建就不会与它们纠缠。” 如果他们坚持，允许他们继续。
- 作用域中的特性
in-progress且其代码区域（指针行的路径）有最近由其他作者提交的更改（git log --format='%an' -- <area>）→ 警告：“<特性> 看起来正在被其他人构建。在继续之前请协调。” 继续前确认。
警告，而非硬性阻止，但需要呈现出来。
Git 集成： 如果最近的 AGENTS.md ## Git 显示 integration: on，则读取 flow/git.md 并遵循它（在构建前创建分支，在里程碑落地时提交）；不存在或设置为 off → 不执行主动 git 操作。
第 0 步：规范关卡（始终第一）
是否存在待决且未记录的决策？不要通过内省（“我觉得我在发明什么吗？”）来判断，构建模型将真正的决策合理化视为“仅仅是连接”并让其通过。使用一个积极的输入覆盖测试，这种测试是机械性的，更难说服自己通过：
枚举此构建必须产生、计算或显示的每个值（来自验收标准和规范的设计）。对于每个值，规范是否指明了它的来源（一个输入、一个数据库列、从一个命名值推导而来、一个先前的决策）？任何所需值如果没有命名的来源，则是一个欠妥的决策。
如果任何来源未命名，停止并路由到关卡（/architect，或记录一个 Assumed 规范；/develop 实现决策，不制定决策）。当一个决策需要您发明以下内容时，该决策也是欠妥的：
- 提供者、库、集成、数据模型或交叉模式（例如，认证提供者、DB/ORM、缓存策略）。
- 整个 UI 页面或屏幕：其设计系统（那里的
design.md？如果没有，哪个方向？）、部分/组成、组件清单、资源策略（没有截图，没有仓库图片 → 例如，在线来源）。除非design.md和页面级规范明确了这些内容，否则欠妥。 - 功能的行为（搜索、向导：“它到底应该做什么？” 是开放的；
/architect会问那些问题）。除非规范定义了它，否则欠妥。
“本地实现细节”实际上意味着什么（狭窄的例外）： 仅在规范命名来源已允许的选项中进行选择时，循环样式、变量名、调用哪个辅助函数。当选择确定了一个值的来源，或一个验收条件约束的行为时，无论看起来多么细小，它按定义都是关键的。从“用户上次读取行的时区”推导“用户的今天”不是本地细节：它选择了验收条件约束的值的来源，因此是欠妥的。对于真正的纯粹实现而言并非欠妥：小错误修复、匹配现有 design.md 的组件、连接规范已命名的来源部分、复制调整、任何由现有规范/design.md/AGENTS.md 完全管控的内容。
不要硬编码为页面名称或任何示例（时区是模式的说明，而非规则）；对被问到的情况应用输入覆盖测试。假阴性是失败模式，即在未注意的情况下构建真正的决策：当所需值的来源未命名，或者您不确定时，将其视为欠妥并询问（下面的面板）。
仅读取此功能所需的内容，永远不要读取整个 docs/ 树：其一个作用域文件及其一个管理规范（单个文件，或总体 index.md 加上指定此子任务的一个子规范）。没有其他功能的行、作用域文件、工作区或无关的规范。
按顺序检查：
- 定位此功能的作用域文件（仅该文件）。 单仓库 →
docs/scope/<workspace>/用于任务的包。仅从“概览”表格中选择文件（scope.md，或拆分版本中匹配的<epic>.md）；仅读取此功能的部分。needs a decision但没有规范指针 → 决策欠妥且缺失。格式错误 → 标记并询问，不要猜测。 - 通过功能的
spec指针打开管理规范，仅按构建流程（flow/build.md）中定义的第 2 步第 1 项读取其构建规范部分。找到 → 这就是规范；继续。没有指针且没有链接规范 → 在docs/specs/<workspace>/中有针对性地查找一个匹配此功能作用域的规范，永远不要全面读取。 - 最近的
AGENTS.md（工作区/领域）可能已经捕获了决策，从早期功能同步而来（例如，“认证提供者已选定”）→ 在无需新规范的情况下继续。
决策欠妥且未记录 → 不要猜测，不要静默停止。询问（单选；在 Claude Code 上使用 AskUserQuestion）：
- question：“这似乎需要一个架构决策：<命名具体的负载相关选择，例如 '哪个认证提供者 + 会话模型'>。您希望如何处理它？”
- header：“先有规范？”
- options：
Architect it first：“推荐。在构建前将决策捕获到规范中，这样构建就有了规范。”→ 在此处结束，附带下面的交接。不要构建。No, not needed：“我判断这里没有真正的决策；直接构建。”→ 继续到构建流程（flow/build.md）。Build now, record it as an assumed spec：“构建它，但先写下假设，这样决策就存储在仓库中，而不仅仅是在这个聊天里。Assumed规范保持标记为需要确认（/architect），但这从不阻止将功能标记为done。”→ 编写一个Assumed规范（如下），然后继续到构建流程（flow/build.md），在作用域（docs/scope/）中以assumed decision (spec NNNN)注释保留功能为in-progress。
工具会自动附加“Other”作为自由文本选项。
在“立即构建，将其记录为假定规范”时，在构建前编写一个最小的 Assumed 规范（这是 /develop 拥有的一个狭窄规范写入；请参阅“产物所有权”）。像 /architect 那样解析 $SPEC_DIR（单仓库 → docs/specs/；多仓库工作区 → docs/specs/<workspace>/），取下一个空闲的 NNNN，然后写入 $SPEC_DIR/NNNN-<slug>.md：
# NNNN · <功能>
**状态**：已假定
**日期**：<今天>
**授权人**：<工程师>，在 /develop 期间
## 欠妥决策
<未做出的具体负载相关选择>
## 构建所依据的假设
<此构建将使用的具体假设>
## 代码区域
<此构建将触及的路径>
## 需求
<从作用域的“完成条件”中继承的验收标准种子（如有）>
## 确认
此决策由 /develop 记录，未经审议。运行 `/architect <功能>`
以审议并确认它。在此之前，它保持标记为欠妥决策；它不会阻止将功能标记为 `done`。
将功能作用域的 spec 行指向此文件。假设现在持久化：它能够承受 /clear，团队成员可以读取它，后续的 /develop 可以基于它构建，而无需再次猜测。Assumed 规范保持标记为需要确认；它不会阻止将功能标记为 done（请参阅 flow/build.md，第 4 步）。
在“先架构”时，以以下内容结束：
接下来运行此命令，然后返回
/develop：/architect <功能>：<要解决的具体决策>一旦规范存在，再次运行
/develop <任务>，我将据此构建。
没有欠妥决策（纯粹实现）→ 跳过问题，继续。
构建流程（第 1-4 步）
第 1-4 步在此处按顺序执行。
（此处续接完整的构建流程步骤……由于截断，以下为占位符，表示实际构建逻辑应在完整文档中提供。）
第 1 步：【待定】 第 2 步：【待定】 第 3 步：【待定】 第 4 步：【待定】