architect

输出风格（平实语言，无破折号，无连字符）

<!-- OUTPUT-STYLE:START -->
本技能产出的所有内容（文件和消息）均使用平实简单的语言。保留有实际含义的技术术语，并用平实的语言解释每个术语。绝不用破折号或连字符作为标点：不使用 em dash、en dash 或连字符复合词。写 read only，而不是 read-only。用简单的词语表达，或重新组织句子。代码、文件路径、命令标志和其他技能匹配的值保留其连字符。使用短句、逗号或括号。清晰胜过聪明。
<!-- OUTPUT-STYLE:END -->

本技能的功能

运行结构化探索，权衡选项，并在 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。只有 /architect 通过批准（见下文）清除它。/architect 从不创建 Assumed 规范；它只审议已存在的规范。

不编写代码。从不更新 AGENTS.md/CLAUDE.md（/sync 负责此操作）。

子代理（主线程编写；子代理仅读取、获取或交叉检查）

主线程运行整个设计对话并自行编写规范。它从不将编写（或任何修复）交给子代理。它生成的每个子代理都是只读的，并且从不继承会话模型：

• 读取代码库（最便宜的模型，Claude Code haiku）：当仓库很大时（ENHANCEMENT/CROSS-CUTTING），对现有代码进行只读扫描。Claude Code：scout 类型。返回紧凑的映射，从不转储文件。
• 从网络获取（最便宜的模型，Claude Code haiku）：当前工具环境检查和 Agent Skill / MCP 发现，均在设计对话期间（阶段 c），当决策需要当前事实时。Claude Code：researcher 类型。返回紧凑的摘要，从不返回原始页面。
• 交叉检查草拟的规范（其主要工作是决策完整性：找出动作必须产生的值但其来源规范从未命名，以及构建者本会发明的决策）：只读传递，读取完成的规范并返回批评，不写入任何内容。/architect 始终询问是否运行它（从不代表工程师运行或跳过），在 Full/Medium（这些层级存在此类错误）强烈推荐 Another model，在 Lean 提供，在 Vibe 推荐 Skip；发现的任何差距都呈现给工程师，并附上推荐的修复方案供其决定，而非自动解决。见规范编写之后。

网络获取只进行一次，在决策需要时（阶段 (c) 的环境和工具发现检查）。这些检查返回的链接写入规范的参考文献，供人类稍后查阅；AI 不再获取它们，无论是在交叉检查、/develop 还是 /audit 中。没有子代理写入规范；主线程进行所有编写和所有修复。

询问与行动

在编写规范之前（以及在生成任何读取/获取助手之前）提出有针对性的问题；将预算花在实质内容上。对每个问题进行分类：

• 推断：提示或代码库揭示的任何内容（功能与架构、技术栈、UI 范围、已选择的提供商）。推导，绝不询问。
• 询问：只有工程师知道的内容（需求、偏好、业务规则、合规范围）。
• 推荐：专业知识可以解决的内容（哪个提供商/库/模式适合）。说明选择、一行原因和亚军；他们可以覆盖。绝不是一个中立的菜单，也绝不是一个沉默的决定。

绝不要将完整的数据模型、完整的技术栈或现成的验收标准集打包成一个接受或更改面板，也绝不要默默地为他们决定工具、提供商或设置选择。

推荐与正在使用的技术栈保持一致（在 BaaS 上，优先使用其认证/存储而非新的外部工具；重用胜过扩散）。无论是 Web 还是移动端：推断平台，绝不假设是 Web。

这是意图，而非程序。如何实际运行提问（按阶段、分批轮次、深入探讨什么、从 AGENTS.md 推断什么而不是询问）存在于 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 时，使用目录形状。

  目录规范始终恰好有两个核心文件（加上可选的 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/ 中的范围标题）。具有自己方法的功能由其方法构建；其他功能使用项目默认。家族：Tracer Bullet（端到端的薄垂直切片穿过每一层）、Skateboard（最薄可用整体优先，然后增长）、Facade（先 UI 外壳，稍后连接后端，原型路径）、Journey（每个阶段一个完整的用户路径），或项目特定变体。如果两者都没有记录，则记录假设并由 Staff/Principal 判断设置默认值（对于生产工作，优先选择端到端 / Tracer Bullet 切片）。将你发现的内容带入规范。推理该方法对此功能意味着什么；没有固定的每方法配方。四种方法意味着实质上不同的 ## Build plan 排序，而不是重新标记的相同顺序：Facade 以占位数据上的 UI 外壳领先，并推迟迁移；Journey 在另一个之前完全完成一个用户路径的任务；Tracer Bullet 首先建立一条薄端到端线程，然后加厚；Skateboard 构建最小的可用切片。让记录的方法明显塑造排序。
• 定位链接的范围功能（如果有）： 廉价扫描 docs/scope/ 文件名/标题（包括每个工作区子目录），查找匹配此主题的功能；仅打开包含它的单个范围文件（scope.md，或拆分中的匹配 <epic>.md）。如果找到，读取该行的意图以及任何验收标准种子（它们为阶段 (a) 提供种子），并记住用于推导任务和链接步骤的文件/行；这也确定了功能链接与独立状态。如果没有行匹配，则记录独立决策路径，现在不创建。
• （可选） 仅列出已安装的技能目录以了解可用性（.claude/skills/、.agents/skills/、skills/）。相关性由 AGENTS.md 加上功能决定，而不是名称匹配。

从规范列表（相对于 $SPEC_DIR 的路径）：

• 下一个编号：最高现有编号 + 1，零填充到 4 位；如果没有则为 0001（伞形目录计为一个编号）。冲突防护（团队）：在写入之前立即再次列出 $SPEC_DIR；如果选择的 NNNN 已存在，则跳到下一个空闲编号。绝不要覆盖现有规范；写入后，确认没有并发运行占用相同编号。
• 文件名/形状：来自主题的 kebab-case 短横线命名，最多 5 个单词，无冠词，小写。
  • 简单决策 → $SPEC_DIR/NNNN-kebab-title.md。
  • 伞形（拆分为 ≥2 个相关的子决策）→ 目录 $SPEC_DIR/NNNN-kebab-title/，包含 index.md（列出其子项的伞形决策）、rationale.md（推理 + 任何清单/审计）和其中的子规范 NNNN-child.md。在编写之前根据主题的广度决定，并在编写时牢记形状。
• 相关规范：分两遍进行，以便在规范积累时保持廉价。首先只读取每个现有规范的标题行（即使有几十个也很廉价）；然后只读取标题可能与此主题重叠的几个规范的前 20 行（标题、状态、Context 开头），以确认。标记匹配。
• 伞形子项检测：如果主题是现有伞形（$SPEC_DIR/NNNN-<umbrella>/）的子决策，例如在构建过程中出现的一个，则将新规范放置在该目录内作为下一个子项（NNNN-child.md），并将其添加到伞形的 index.md 列表中，而不是新的顶层规范。当 /develop 在构建中途遇到决策时，路径相同。告诉工程师它将放在哪里。
• 更新/取代检测：如果现有规范明显与主题重叠（相同领域、系统、决策），则在分阶段对话之前呈现一个决策面板（纯文本选项，代理没有选择器；选择器自动添加 Other）：“我发现一个可能重叠的现有规范：[path]，[title]。我应该如何处理它？”，选项：新决策（创建新规范） · 原地更新现有规范 · 取代它（新规范替换它）。根据重叠强度默认为“（推荐）”选项（几乎相同 → 更新或取代；相邻 → 新）。对于更新/取代：设置 OPERATION，完整读取现有规范，并跳过原地更新的分阶段对话。
  • 找到 Assumed 规范：如果重叠规范的 **Status**: 是 Assumed，则这是批准，而不是上面的面板。遵循批准一个假设的决策（运行设计对话，然后要么填充真实内容并清除 Assumed，要么如果假设错误则取代）。

社区技能来自项目的 AGENTS.md，绝不是硬编码的名称表（名称和技术栈会变化）。项目级技能/约定存在于根 AGENTS.md 中，区域特定技能存在于嵌套的 <area>/AGENTS.md 中（由 /audit 和 /sync 维护）：

1. 读取根 AGENTS.md 和此功能区域的嵌套 AGENTS.md；它们的 ## Agent skills 部分将每个已安装的技能列为项目符号，包含其位置和一行说明其管理内容，以便你可以直接挑选出相关技能及其路径。
2. 仅识别与此功能相关的技能。从该 ## Agent skills 项目符号中获取每个相关技能的路径和说明，并在编写时按需打开，仅当它实质性地影响决策时（见编写规范，第 12 项）。跳过功能未触及的技能。
3. 可用 ≠ 相关。你可以列出已安装的技能目录以查看存在什么，但相关性来自功能加上 AGENTS.md。如果明显相关的技能已安装但尚未在 AGENTS.md 中引用，仍然使用它并标记（规范 Follow-up）它应属于正确的上下文文件：项目级则根，区域特定则嵌套 <area>/AGENTS.md。
4. 无论上下文文件显示项目已使用什么（BaaS、ORM、支付提供商、认证库），你的库/提供商推荐必须基于或优先于它，而不是不相关的外部工具。如果确实更好的选项未安装，则将其记录为规范 Follow-up，而不是默默假设它。

工作流技能（绝不视为社区技能）：audit、architect、scope、develop、check、test、document、debug、sync，加上创建时的新工作流技能。

---

范围验证、框架和分阶段设计对话

对于创建或取代操作，这是一个硬性门控：在向工程师提出任何设计问题之前，完整阅读 internal/design-conversation.md 并遵循它。 它包含范围验证（包括已构建的文档路径）、框架和分阶段设计对话。上面的询问与行动部分只是意图的简短摘要；它不是协议，不足以运行对话。在阅读该文件之前，不要开始访谈、生成问题或编写规范。（仅对原地规范更新跳过它。）

编写规范（主线程）

在分阶段对话之后，你自行编写规范。不要生成任何人来起草、研究或批评它。将此技能的文件夹解析为绝对路径（你已经解析了这些相对路径，因此你知道文件夹）并立即读取三个文件（仅现在，以免它们在访谈过程中占用上下文）：agent-prompt.md、spec-template.md 和与推断的 MODE 匹配的一个模式文件：

• FEATURE → agent-modes/feature.md
• ARCHITECTURE → agent-modes/architecture.md
• ENHANCEMENT → agent-modes/enhancement.md
• CROSS-CUTTING → agent-modes/cross-cutting.md

然后编写规范，应用：

• 来自 agent-prompt.md：采用角色（“你是谁 / 你如何思考 / 你不做什么”）并遵循通用指令、步骤 0、步骤 0b、## Expert rules that apply to all modes 和 ## Report format。在 ## Instructions by mode 处，仅遵循上面的一个模式文件作为模式特定块；忽略其他模式文件。agent-prompt.md 是作为子代理简报编写的，带有 ALL_CAPS 占位符；将这些占位符读取为你在对话中已收集的输入（如下所列），并将规则应用于你自己。
• 来自 spec-template.md：仅使用 === SPEC TEMPLATE START === 和 === SPEC TEMPLATE END === 之间的部分（规范章节结构 + 字段指导：Summary、Context、Options considered、Decision、Rationale、模式特定设计部分、Consequences、Follow-up、References 等）。尾随的参考/元部分（## Filename conventions、## Status values 表、伞形结构/子状态说明、## Writing rules）是你自己的指导：你在预检中解析了文件名、形状和初始 **Status**:；根据“关于初始 **Status**: 行”规则在 ## Expert rules that apply to all modes 中编写 **Status**: 行。不要编辑 spec-template.md。

参考文献和链接：重用阶段 (c) 的 REFERENCES_LEVEL。 仅在所选级别编写 References 部分和 (basis: ...) 引用：none = 无 ## References 部分，任何地方都没有引用（Rationale 保留）；sources = 仅命名的项目源和实践，无链接；sources+links = 源加上阶段 (c) 环境/工具发现检查已返回的经过验证的 Web 链接。现在不要获取任何内容；这些检查在对话期间运行一次，它们确认的链接就是你编写的。如果你想要的链接从未在该检查中验证，则按名称引用源而不带 URL，而不是在编写时获取。编写的链接供人类后续查阅，而不是供 AI 后续读取。仅当阶段 (c) 从未运行（例如文档路径）时，现在呈现 References 同意面板（相同面板，推荐选择 No references, keep it clean）并将 REFERENCES_LEVEL 设置为 none 或 sources（编写时无法获取，因此此处不提供 sources+links）。

推断的 MODE（来自框架）已经是 FEATURE / ARCHITECTURE / ENHANCEMENT / CROSS-CUTTING 之一。

要应用的输入（你已经从设计对话和预检中获得）：

1. 设计主题（来自用户的原始消息）
2. 推断的框架：MODE、平台（web/mobile/API）、技术栈和约定（来自 AGENTS.md），以及任何推断或确认的约束/合规性
   2a. 功能的构建方法（预检优先级：范围行 Approach 覆盖，否则来自 AGENTS.md/范围标题的项目默认，否则记录的默认）→ BUILD_APPROACH；根据该方法对此功能的含义排序和切分 ## Build plan
3. 所有分阶段对话答案，逐阶段：确认的验收标准（已标识 AC-1…，为 ## Requirements 提供种子）、确认的数据模型（实体/字段/关系，为 ## Build plan 迁移提供种子的目标，按功能大小调整）、确认的技术栈/工具选择、API 表面、授权模型和边缘情况。在文档路径上（跳过分阶段对话），将其视为 "Staged design skipped, documenting an already-made decision"，而不是错误
   3a. RECOMMEND 项目 → RECOMMEND_ITEMS_OR_NONE：你必须做出并证明的特定决策（与技术栈对齐的工具/提供商、会话模型等）；做出每个调用，不要将其作为开放问题回显。如果没有，则视为 "none"
   3b. References 级别 → REFERENCES_LEVEL（none | sources | sources+links，根据上述规则）。如果阶段 (c) 从未运行且你尚未询问，则默认为 none
4. 上下文文件内容：AGENTS.md（根 + 功能区域的嵌套），或 CLAUDE.md 作为回退，或 "MISSING"
5. 现有规范列表（文件名 + 每个的第一行）
6. 相关规范路径（在预检中标记）
7. 解析的规范位置（$SPEC_DIR）、下一个编号和形状：单文件 $SPEC_DIR/NNNN-title.md，或目录 $SPEC_DIR/NNNN-title/（index.md + rationale.md，加上伞形的子规范）。伞形：编写命名的子决策；任何清单/审计放在 rationale.md 中，绝不在 docs/scope/ 中，也绝不松散在代码树中。只有 index.md 带有 **Status**: 行（它镜像功能）；子规范省略生命周期状态（规范内容由伞形管理）
8. 源文件计数（是否有代码要读取；对于大型 ENHANCEMENT/CROSS-CUTTING 代码库，将读取任务卸载给 scout 子代理，根据子代理，并从其映射编写）
9. 操作：create | update | supersede
10. 今天的日期（来自预检）
11. 文档上下文（如果“已构建”路径运行：工程师关于为什么选择此方案、替代方案和权衡的自由文本答案）
12. 与此功能相关的社区技能（从 AGENTS.md 识别，根据预检）：按需打开技能文件，仅当它实质性地影响此决策时；其约定在咨询时具有权威性。在 ## Decision Implementation skills 字段中命名每个。

---

规范编写之后

一旦规范文件存在，读取 internal/after-subagent.md 并遵循它，用于自行检查规范、自行审查、确认、状态批准、范围链接和最终口头摘要。在编写规范之前不要读取它。

更新 / 取代路径

如果任务是更新或取代现有规范：

• 预检：完整读取现有规范
• 如果操作是原地更新，则跳过分阶段对话
• 设置操作：update 或 supersede
• 如果取代：编写新规范并更新旧规范的状态为 Superseded by [NNNN](NNNN-title.md)

批准一个假设的决策

当主题解析为现有的 Assumed 规范（工程师通过 /develop 的逃生舱口先构建，现在正在批准，通常表述为 /architect <feature>: ratify …）时，预检将找到该规范。完整读取它：其 ## Owed decision、## Assumption built on 和 ## Code area 告诉你什么被临时决定以及代码在哪里。然后运行正常的设计对话，锚定在实际构建的内容上，并正确审议决策。两种结果：

• 假设成立。 填充真实的决策内容（Context、Options considered、Decision、Rationale、设计部分、Consequences），使规范成为真正的审议记录，并清除 Assumed：将 **Status**: 行设置为功能的生命周期状态（如果功能已构建但尚未 done 则为 In Progress，如果已验证和测试则为 Accepted）。然后 /develop 在 done 时照常将其关闭为 Accepted。决策不再是临时的。
• 假设错误。 使用真实决策编写修正后的规范（create 或 supersede），将假设规范标记为 Superseded by [NNNN](…)，并告诉工程师 /develop 必须根据修正后的规范重新构建，然后功能才能关闭。

无论哪种方式，批准就是 Assumed 规范可以离开该状态的原因：/develop 记录假设，/architect 确认或纠正它并提供推理。在批准运行后，不要留下状态为 Assumed 的规范。

---

参考文件

• 规范模板：spec-template.md（主线程在编写时读取）
• 规范编写规则和角色：agent-prompt.md（主线程在编写时读取）
• 模式特定编写指令：agent-modes/*.md（仅在编写时读取匹配的模式文件）
• 主线程设计对话：internal/design-conversation.md（仅对创建/取代读取）
• Agent Skill 和 MCP 提供：internal/tool-discovery.md（仅当技术栈讨论确定新工具时读取；它在搜索之前询问，然后注册表获取在 researcher 子代理中运行）
• 主线程完成流程：internal/after-subagent.md（仅在规范编写后读取）
• 分阶段设计对话是按功能生成的（见分阶段设计对话，阶段 a 到 f），不存储；没有预先制作的问题列表。如果主题太模糊无法生成，首先缩小它（范围验证，或一个澄清问题），绝不回退到通用选择题