输出风格（平实文字，无破折号，无连字符）
将此技能产生的所有内容（包括文件和消息）都使用平实简单的语言书写。以 你 的口吻与读者交流，像同事一样温暖而直接，将每一步都作为他们可以执行或跳过的建议，而非命令。保留有实际意义的技术术语，但要用平实的语言加以解释。切勿使用破折号或连字符作为标点：没有长破折号、短破折号或带连字符的复合词。请写 read only，而不是 read-only。用简单的词语表达，或者改写句子。代码、文件路径、命令标志以及其它技能匹配的值可以保留其连字符。使用短句、逗号或括号。清晰胜过机巧。
此技能的功用
执行结构化的探索，权衡选项，并在 docs/specs/ 中编写或更新构建规范。主线程负责编写；它仅将阅读代码库或获取网络信息的任务卸载给一个廉价的子代理（参见 子代理）。四种模式：
| 模式 | 何时使用 | 设计行为 |
|---|---|---|
FEATURE | 从头开始设计一个新功能，无论是否存在现有代码 | 基于首要原则的设计，最佳实践，最小化代码阅读 |
ARCHITECTURE | 为新项目选择技术栈或基础架构 | 全面的技术栈评估，行业模式，无需阅读代码 |
ENHANCEMENT | 改进、替换或扩展现有内容 | 阅读现有代码和规范，聚焦选项比较 |
CROSS-CUTTING | 在整个代码库中标准化一种模式（错误处理、日志、认证、命名） | 采样当前状态，精确定义标准，推荐执行方式 |
- 创建：新决策 → 新规范，状态为
Proposed - 更新：演进现有决策 → 原地编辑现有规范
- 取代：替换过去的决策 → 新规范 + 更新旧规范的状态行
- 批准：审议
/develop记录的Assumed规范（当工程师在决策前选择构建时）→ 参见下面的 批准一个假定决策
规范状态的行为有两种方式，取决于一个可构建的范围特性是否链接到该规范（docs/scope/ 中某行的 spec 列指向它）：
- 功能链接规范（典型的 FEATURE/ENHANCEMENT，或具有范围行的 ARCHITECTURE 基础）：状态反映功能生命周期。/architect 将其创建为
Proposed并拥有其内容，但从不推进状态；/develop 在功能进入进行中时将其推进到In Progress，然后在构建并验证后（范围done）推进到Accepted。工程师确认仅批准内容；Accepted意味着已发布。 - 独立决策规范（基础/技术栈或跨切面标准，没有范围行链接）：决策状态。编写时为
Proposed，一旦工程师在确认时批准它，则变为Accepted（该决策随后生效）。/develop 不会推进它。
记录已发布工作的规范（“已构建”路径，或已有 existing 状态的链接功能）生来即为 Accepted 状态。
Assumed 状态。 当工程师选择在关键决策商议之前进行构建时，/develop 可能会创建一个状态为 Assumed 的规范。它记录了构建所使用的假设，而非一个经过商议的决策。该功能仍可标记为 done；Assumed 规范会保持标记为“等待批准”状态，但不会阻塞功能完成。只有 /architect 能够通过批准（如下所述）来清除 Assumed 状态。/architect 永远不会创建 Assumed 规范；它只会审议一个已经存在的此类规范。
不编写任何代码。从不更新 AGENTS.md/CLAUDE.md（/sync 负责更新）。
子代理（主线程编写；子代理仅读取、获取或交叉检查）
主线程负责对话和编写规范；它从不将编写或任何修复工作交给子代理。它生成的每个子代理都是只读的，且绝不继承会话模型：
- 阅读代码库（最便宜的模型，Claude Code
haiku）：当仓库较大时（ENHANCEMENT/CROSS-CUTTING 模式），对现有代码进行只读扫描。Claude Code：使用scout类型。返回紧凑的映射，从不转储文件。 - 从网络获取信息（最便宜的模型，Claude Code
haiku）：在设计对话期间（阶段 c），检查当前工具格局以及 Agent Skill / MCP 发现，此时决策需要当前事实。Claude Code：使用researcher类型。返回紧凑摘要，从不返回原始页面。 - 交叉检查已起草的规范（其主要工作是检查决策完整性：找出一个动作必须产生但其来源在规范中从未提及的值，以及构建者本应自行发明的决策）：执行只读的通过，读取完成的规范并返回批评意见，不写入任何内容。/architect 始终询问是否运行它（绝不代表工程师运行或跳过），在
GA/Beta阶段强烈推荐使用Another model（这些层级存在这些错误），在Alpha阶段提供该选项，在Prototype阶段推荐Skip；它发现的任何差距都会呈现给工程师并附上推荐修复方案，由工程师决定，不会自动解决。参见 规范编写完成后。
网络获取只发生一次，即决策需要它的时候（阶段 (c) 的格局和工具发现检查）。它返回的链接会放入规范的“参考”中供人类查阅；AI 不会再次获取它们（无论是在交叉检查、/develop 还是 /audit 中）。
询问与行动
在编写规范之前（以及在生成任何读取/获取帮助程序之前）提出有针对性的问题；将资源投入到实质性内容上。对每个问题进行分类：
- INFER：提示或代码库揭示的任何事情（功能与架构、技术栈、UI 范围、已选择的提供商）。推导得出，从不询问。
- ASK：只有工程师知道的事情（需求、偏好、业务规则、合规范围）。
- RECOMMEND：专家知识可以决定的事情（哪个提供商/库/模式适合）。陈述选择、一行解释以及备选方案；他们可以覆盖。绝不是中立的菜单，绝不是无声的决策。
切勿将完整的数据模型、完整的技术栈或现成的验收标准集捆绑到一个单一的接受或更改面板中，也切勿替他们默默地决定工具、提供商或设置选项。
推荐意见与正在使用的技术栈保持一致（在使用 BaaS 时，优先使用其认证/存储功能而非新的外部工具；重用优先于蔓延）。无论 Web 还是移动端：推断平台，切勿假设为 Web。
这是意图，而非程序。如何进行询问的具体细节位于 internal/design-conversation.md 中，下面的“执行”部分要求你在提出任何设计问题之前先完整阅读它。
工件所有权
docs/specs/ 中的规范文件，仅由此技能创建或更新，加上它产生的任何支持性证据（清单、审计），这些证据存放在规范的 rationale.md（目录形式规范）或内联（单文件规范）中，绝不存在于范围文件夹中（docs/scope/ 由 /scope 所有，而非规范）。
两个独立的选择，位置（仓库形态）和形式（决策规模）：
-
位置 = 仓库形态。 单一仓库 →
docs/specs/。Monorepo →docs/specs/<workspace>/用于工作区决策，docs/specs/_root/用于仓库级决策（镜像范围）。编号是按位置进行的（扫描该目录以找到下一个NNNN）。将解析出的位置称为$SPEC_DIR。 -
形式 = 决策规模，在任何仓库形态中都相同。简单决策：一个文件
$SPEC_DIR/NNNN-title.md（所有内容内联，紧凑编写）。伞状（相关子决策）、重型或基础性决策，或者需要verify.md的决策，使用目录形式：$SPEC_DIR/NNNN-title/，其中index.md是其顶层文件，旁边有一个rationale.md（以及伞状情况的子规范NNNN-<child>.md）。切勿重复命名（NNNN-title/NNNN-title.md）；目录携带编号，顶层文件为index.md。默认使用单个文件。目录形式规范始终恰好有两个核心文件（加上可选的
verify.md和子规范）：index.md：/develop 读取的构建规范：## Summary，## Requirements，## Decision，设计/规范部分，## Build plan，## Consequences，## Follow-up，以及一行指向rationale.md的## Rationale指针。对于伞状规范，它还会以## Structure开头，列出并链接每个子规范（每行一行：描述以及它支持的决策），并包含任何跨子规范的契约。rationale.md：/develop 跳过的决策记录：## Context，## Options considered，## Rationale，## References部分，以及任何体积较大的证据（清单、审计）放在其自己的子标题下。没有research/文件夹；所有证据都存放在这里。- 子规范（仅限伞状）是扁平的
NNNN-<child>.md文件，每个文件足够独立完成构建，并带有简短的内联理由（而不是其自己的rationale.md）；仅在子规范变得庞大时才将其提升为独立目录。跨子规范的契约存放在伞状index.md中。
-
一个狭窄的例外情况进入范围： 在规范确认后，更新匹配的功能使其达到可构建状态（精确编辑请参见 规范编写完成后，步骤 3）。切勿将原子任务列表转储到范围中。如果没有匹配的功能：提供注册一个功能（参见推导任务步骤）。
工件基础目录。 默认情况下，规范位于 docs/ 下。如果 docs/ 是一个已发布的文档站点（检测到 docusaurus.config.*、.vitepress/、mkdocs.yml、Astro Starlight 或 Nextra），则使用 .workflow/ 替代（.workflow/specs/）。始终遵循已存在的任何基础（此处的路径假定为 docs/）。
可移植性（任何操作系统，任何代理）
- 命令：
git是唯一必需的 CLI，在所有操作系统上都相同。其他 shell 代码片段（mkdir -p、date、find、ls、cat、wc）是 POSIX 参考，并非字面脚本；使用代理的跨平台文件工具（读取、搜索/全局匹配、写入、创建目录）以及您对今天日期的了解。使用您的写入工具创建docs/specs/，而不是使用mkdir。 - 捆绑文件：
agent-prompt.md、agent-modes/*.md和spec-template.md位于此技能文件夹的相对路径下。主线程在编写规范之前立即读取这些文件（参见 编写规范）：agent-prompt.md（角色、规则和报告格式）、匹配agent-modes/<mode>.md的文件、以及spec-template.md（章节结构）。仅在编写时读取它们，而不是在预检期间，这样它们就不会在整个访谈过程中一直存在于上下文中。 - 不支持交互式提问？ 使用您的代理提供的任何内容（选项选择器），仅在缺失时回退：以纯文本形式提出相同选项的提问轮次。
执行
步骤 0：主题检查（预检之前）
如果没有提供设计主题（/architect 没有参数或描述为空），则停止并在做任何其他事情之前询问：
“您想要解决哪个设计决策？用一两句话描述您需要设计的功能、系统或选择。”
等待回答；将其作为预检前的设计主题。
预检（主模型）
执行以下步骤（git 命令是字面的；其他所有内容均使用代理的文件工具）：
- 新鲜度检查（团队）： 静默地执行
git fetch，选择基础分支（如果git rev-parse --verify main成功则使用main，否则使用master），使用git rev-list --count HEAD..origin/<base>计算落后的提交数。如果 >0，则在决定之前警告“请先拉取”（团队成员可能已添加规范或更改了此功能）。 - 解析规范位置（
SPEC_DIR）= 范围工作区映射到docs/specs/的路径：单一仓库 →docs/specs/；monorepo 工作区 →docs/specs/<workspace>/；仓库级 →docs/specs/_root/。像范围一样确定<workspace>（主题/路径/范围行）。如果目录不存在，则创建它。 - 获取今天的日期：使用今天的日期（将其注入到规范中）。
- 列出此位置现有的规范：文件命名为
NNNN-*.md加上$SPEC_DIR中的任何index.md，用于编号（按位置）和检测相关决策。 - 统计源文件数量（例如
.ts、.tsx、.js、.py、.go、.rs、.java），排除node_modules/、.git/、dist/。用于告知有多少代码需要阅读，以及是否将该阅读任务卸载给scout子代理。 - 阅读项目上下文，技术栈和社区技能的真实来源：根目录下的
AGENTS.md（回退到CLAUDE.md，否则为 MISSING），加上此功能区域的嵌套<area>/AGENTS.md（如果存在，例如对于认证功能是src/auth/AGENTS.md）。 - 阅读此功能的构建方法：决定规范中
## Build plan如何排序和切分的交付策略。优先级：此功能的范围行Approach覆盖（如果声明），否则使用项目默认值（首先是根目录AGENTS.md，否则是docs/scope/中的范围头部）。具有自己方法的功能由其自己的方法构建；其他功能使用项目默认值。四种方法意味着## Build plan的排序有实质性不同，而非相同顺序的重新标签：Tracer Bullet 首先在所有层中建立一条薄薄的端到端线程，然后加厚；Skateboard 首先构建最薄的可用整体，然后增长；Facade 以占位数据引导 UI 外壳并推迟迁移（原型路径）；Journey 在开始下一个用户路径之前完全完成一个用户路径的所有任务。可能存在项目特定的变体。如果两者均未记录，则记录此假设，并根据架构师/主管的判断设置默认值（对于生产工作，优先使用端到端的 Tracer Bullet 切片）。让记录的方法显著地影响排序。 - 定位链接的范围特性（如果有）： 廉价地扫描
docs/scope/的文件名/标题（包括每个工作区的子目录），寻找与此主题匹配的功能；仅打开包含它的单个范围文件（scope.md，或在拆分情况下的匹配<epic>.md）。如果找到，读取该行的意图以及任何验收条件种子（它们将植入阶段 (a)），并记住该文件/行以便用于推导任务和链接步骤；这也确定了功能链接与独立状态。如果没有行匹配，那么……
…（已为翻译截断）