architect

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Output style (plain words, no dashes, no hyphens)

输出风格（直白表述，不使用破折号、连字符）

Write everything this skill produces, files and messages alike, in plain simple language. Talk to the reader as

you

, warm and direct like a colleague, and present every step as a recommendation they may run or skip, never an order. Keep technical terms that carry real meaning; explain each in plain words. Never use a dash or a hyphen as punctuation: no em dash, no en dash, and no hyphenated compounds. Write

read only

, not

read-only

. Say it in simple words, or reword the sentence. Code, file paths, command flags, and values other skills match on keep their hyphens. Use short sentences, commas, or parentheses. Clear beats clever.

此技能生成的所有内容（包括文件和消息）都需使用简洁直白的语言撰写。以

you

称呼读者，语气像同事一样亲切直接，将每一步都呈现为读者可选择执行或跳过的建议，而非命令。保留具有实际意义的技术术语，并以直白语言解释每个术语。绝不使用破折号或连字符作为标点：包括长破折号、短破折号和连字符复合词。写成

read only

，而非

read-only

。用简单的语言表述，或改写句子。代码、文件路径、命令标志以及其他技能匹配的值保留其连字符。使用短句、逗号或括号表述。清晰胜过巧妙。

What this skill does

此技能的功能

Runs structured discovery, weighs options, and writes or updates a build spec in

docs/specs/

. The main thread writes; it offloads only reading the codebase or fetching the web to a cheap subagent (see Subagents). Four modes:

Mode	When	Design behaviour
`FEATURE`	Designing a new feature from scratch, with or without existing code	First principles design, best practices, minimal code reading
`ARCHITECTURE`	Choosing a tech stack or foundational architecture for a new project	Comprehensive stack evaluation, industry patterns, no code to read
`ENHANCEMENT`	Improving, replacing, or scaling something that already exists	Read existing code + specs, focused option comparison
`CROSS-CUTTING`	Standardising a pattern across the whole codebase (error handling, logging, auth, naming)	Sample current state, define the standard precisely, recommend enforcement

Create: new decision → new spec with status
```
Proposed
```
Update: evolving an existing decision → edit existing spec in place
Supersede: replacing a past decision → new spec + update old spec's status line
Ratify: deliberating an
```
Assumed
```
spec that
```
/develop
```
recorded when the engineer chose to build before deciding → see Ratify an assumed decision below

Spec status behaves one of two ways, decided by whether a buildable scope feature links the spec (a

docs/scope/

row whose

spec

cell points to it):

Feature linked spec (typical FEATURE/ENHANCEMENT, or an ARCHITECTURE foundation that has a scope row): status mirrors the feature lifecycle. /architect creates it as
```
Proposed
```
and owns its content but never advances the status; /develop advances it to
```
In Progress
```
when the feature goes in-progress, then
```
Accepted
```
when built and verified (scope
```
done
```
). Engineer confirmation ratifies content only;
```
Accepted
```
means shipped.
Standalone decision spec (foundational/stack or cross cutting standard, no scope row links it): decision status.
```
Proposed
```
when written,
```
Accepted
```
once the engineer ratifies it on confirmation (the decision is then in force). /develop does not advance it.

A spec documenting already shipped work (the "already built" path, or a linked feature already

existing

) is born

Accepted

The
Assumed
status.

/develop

may create a spec in status

Assumed

when the engineer chooses to build before a load bearing decision is deliberated. It records the assumption the build used, not a deliberated decision. The feature can still be marked

done

; the

Assumed

spec stays flagged as owing ratification and does not block it. Only

/architect

clears the

Assumed

status, by ratifying (below).

/architect

never creates an

Assumed

spec; it only deliberates one that already exists.

Writes no code. Never updates

AGENTS.md

CLAUDE.md

(/sync owns that).

执行结构化探索、权衡选项，并在

docs/specs/

目录下编写或更新构建规范。主线程负责编写，仅将读取代码库或获取网络信息的任务委托给轻量subagent（参见Subagents）。包含四种模式：

模式	适用场景	设计行为
`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负责）。

Subagents (main thread writes; subagents only read, fetch, or cross check)

Subagents（主线程负责编写；subagents仅负责读取、获取或交叉检查）

The main thread runs the conversation and writes the spec; it never hands the writing or any fix to a subagent. Every subagent it spawns is read only and never inherits the session model:

Read the codebase (cheapest model, Claude Code
```
haiku
```
): a read only scan of existing code when the repo is large (ENHANCEMENT/CROSS-CUTTING). Claude Code: the
```
scout
```
type. Returns a compact map, never file dumps.
Fetch from the web (cheapest model, Claude Code
```
haiku
```
): the current tool landscape check and the Agent Skill / MCP discovery, both during the design conversation (Stage c), when a decision needs current facts. Claude Code: the
```
researcher
```
type. Returns a compact summary, never raw pages.
Cross check the drafted spec (its primary job is decision completeness: finding values an action must produce whose source the spec never names, and decisions the builder would otherwise invent): a read only pass that reads the finished spec and returns a critique, writing nothing.
```
/architect
```
always asks whether to run it (never runs or skips it on the engineer's behalf), recommending
```
Another model
```
strongly at
```
GA
```
/
```
Beta
```
(the tiers where these bugs live), offering it at
```
Alpha
```
, and recommending
```
Skip
```
at
```
Prototype
```
; any gap it finds is presented to the engineer with a recommended fix for them to decide, not auto resolved. See After the spec is written.

Web fetching happens once, when a decision needs it (the Stage (c) landscape and tool discovery checks). The links it returns go into the spec's References for a human to follow; the AI never fetches them again (not in the cross check,

/develop

, or

/audit

主线程负责对话和编写规范；绝不将编写或任何修正任务委托给subagent。它生成的所有subagent均为只读，且从不继承会话模型：

读取代码库（最轻量化模型，Claude Code
```
haiku
```
）：当代码库较大时（ENHANCEMENT/CROSS-CUTTING模式），对现有代码进行只读扫描。Claude Code类型：
```
scout
```
。返回简洁的代码映射，从不返回文件转储内容。
获取网络信息（最轻量化模型，Claude Code
```
haiku
```
）：在设计对话（Stage c）期间，当决策需要当前事实时，检查当前工具生态以及Agent Skill / MCP信息。Claude Code类型：
```
researcher
```
。返回简洁摘要，从不返回原始页面。
交叉检查草拟规范（核心任务是确保决策完整性：找出操作必须生成但规范未指明来源的值，以及构建者可能自行决定的决策）：只读检查，读取已完成的规范并返回评审意见，不进行任何编写。/architect总是询问是否运行此检查（绝不会自行决定运行或跳过），在
```
GA
```
/
```
Beta
```
阶段强烈推荐使用
```
Another model
```
（这些阶段易出现此类问题），在
```
Alpha
```
阶段提供该选项，在
```
Prototype
```
阶段推荐
```
Skip
```
；检查发现的任何漏洞都会呈现给工程师，并提供推荐修复方案供其决策，不会自动解决。参见规范编写完成后。

网络信息获取仅在决策需要时执行一次（Stage (c)的生态和工具发现检查）。返回的链接会放入规范的参考部分供人类查看；AI不会再次获取这些链接（交叉检查、/develop或/audit阶段都不会）。

Asks vs acts

询问与执行

Ask targeted questions before you write the spec (and before spawning any read/fetch helper); spend the budget on substance. Sort every question:

INFER: anything the prompt or codebase reveals (feature vs architecture, the stack, UI in scope, an already chosen provider). Derive, never ask.
ASK: only what the engineer alone knows (requirements, preferences, business rules, compliance scope).
RECOMMEND: anything expertise settles (which provider/library/pattern fits). State the pick, a one line why, and the runner up; they may override. Never a neutral menu, never a silent decision.

Never bundle a complete data model, full stack, or ready made acceptance criteria set into one accept or change panel, and never silently decide a tool, provider, or setup choice for them.

Recommendations align with the stack in use (on a BaaS, prefer its auth/storage over new external tools; reuse beats sprawl). Web or mobile alike: infer the platform, never assume web.

That is the intent, not the procedure. How to run the questioning lives in

internal/design-conversation.md

, which Execution below makes you read in full before you ask a single design question.

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

推断：提示或代码库中已揭示的任何信息（功能 vs 架构、技术栈、涉及的UI、已选择的供应商）。自行推导，绝不询问。
询问：仅询问只有工程师知晓的信息（需求、偏好、业务规则、合规范围）。
推荐：专业知识可确定的任何内容（哪个供应商/库/模式适用）。说明选择理由（一句话），并列出备选方案；工程师可覆盖推荐。绝不提供中立选项菜单，绝不静默做出决策。

绝不将完整的数据模型、全栈或现成的验收标准打包成一个"接受或修改"的面板，绝不静默为工程师决定工具、供应商或配置选项。

推荐内容需与当前使用的技术栈保持一致（在BaaS平台上，优先使用其自带的认证/存储服务，而非新的外部工具；复用优于扩展）。无论是Web还是移动平台：推断当前平台，绝不默认假设为Web。

以上是设计意图，而非具体流程。提问流程详见

internal/design-conversation.md

，在执行下方步骤之前，需完整阅读该文件，之后才能提出任何设计问题。

Artifact ownership

工件所有权

Spec files in

docs/specs/

, created or updated by this skill only, plus any supporting evidence it produces (inventories, audits), which lives in the spec's

rationale.md

(directory spec) or inline (single file spec), never in the scope folder (

docs/scope/

is owned by

/scope

, not a spec).

Two independent choices, location (repo shape) and shape (decision size):

Location = repo shape. Single repo →
```
docs/specs/
```
. Monorepo →
```
docs/specs/<workspace>/
```
for a workspace decision,
```
docs/specs/_root/
```
for a repo wide one (mirrors the scope). Numbering is per location (scan that dir for the next
```
NNNN
```
). Call the resolved location
```
$SPEC_DIR
```
.
Shape = decision size, the same in any repo shape. Simple decision: one file
```
$SPEC_DIR/NNNN-title.md
```
(everything inline, written tight). An umbrella (related sub decisions), a heavy or foundational decision, or one that warrants a
```
verify.md
```
uses the directory shape:
```
$SPEC_DIR/NNNN-title/
```
with
```
index.md
```
as its top file plus a
```
rationale.md
```
beside it (and child specs
```
NNNN-<child>.md
```
for an umbrella). Never double the name (
```
NNNN-title/NNNN-title.md
```
); the directory carries the number, the top file is
```
index.md
```
. Default to a single file.
A directory spec always has exactly two core files (plus optional
```
verify.md
```
and child specs):
- index.md
  : the build spec
```
/develop
```
  reads:
```
## Summary
```
  ,
```
## Requirements
```
  ,
```
## Decision
```
  , the design/spec section,
```
## Build plan
```
  ,
```
## Consequences
```
  ,
```
## Follow-up
```
  , and a one line
```
## Rationale
```
  pointer to
```
rationale.md
```
  . For an umbrella it also opens with a
```
## Structure
```
  manifest listing and linking every child spec (one line each: what it is plus which decision it supports), and holds any cross child contract.
- rationale.md
  : the decision record
```
/develop
```
  skips:
```
## Context
```
  ,
```
## Options considered
```
  ,
```
## Rationale
```
  , the
```
## References
```
  section, and any bulky evidence (inventories, audits) under its own subheading. There is no
```
research/
```
  folder; all evidence lives here.
- Child specs (umbrella only) are flat
```
NNNN-<child>.md
```
  files, each complete enough to build from on its own with a short inline rationale (not its own
```
rationale.md
```
  ); promote a child to its own directory only when it grows heavy. Cross child contracts live in the umbrella
```
index.md
```
  .
One narrow exception into the scope: after the spec is confirmed, update the matching feature to the ready to build shape (exact edits in After the spec is written, step 3). Never dump the atomic task list into the scope. No matching feature: offer to enroll one (see the derive tasks step).

Artifact base. specs live under

docs/

by default. If

docs/

is a published docs site (

docusaurus.config.*

.vitepress/

mkdocs.yml

, Astro Starlight, or Nextra detected), use

.workflow/

instead (

.workflow/specs/

). Always follow whichever base already exists (paths here assume

docs/

docs/specs/

目录下的规范文件，仅由此技能创建或更新，以及它生成的任何支持证据（清单、审计报告），这些证据存储在规范的

rationale.md

（目录型规范）中或内联（单文件规范），绝不会存储在范围文件夹中（

docs/scope/

由/scope负责，不属于规范）。

包含两个独立选项：位置（仓库结构）和形态（决策规模）：

位置 = 仓库结构：单仓库 →
```
docs/specs/
```
。单体仓库 → 工作区决策存储在
```
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读取的构建规范：
```
## 摘要
```
  、
```
## 需求
```
  、
```
## 决策
```
  、设计/规范部分、
```
## 构建计划
```
  、
```
## 影响
```
  、
```
## 后续工作
```
  ，以及指向
```
rationale.md
```
  的单行
```
## 理由
```
  指针。对于总括性规范，还会以
```
## 结构
```
  清单开头，列出并链接每个子规范（每行一句话：子规范内容及其支持的决策），并包含子规范间的交叉契约。
- rationale.md
  ：/develop会跳过的决策记录：
```
## 背景
```
  、
```
## 考虑的选项
```
  、
```
## 理由
```
  、
```
## 参考
```
  部分，以及任何 bulky 证据（清单、审计报告）放在独立子标题下。不存在
```
research/
```
  文件夹；所有证据都存储在此处。
- 子规范（仅总括性规范有）为扁平的
```
NNNN-<child>.md
```
  文件，每个文件足够完整，可独立基于其进行构建，并包含简短的内联理由（无独立
```
rationale.md
```
  ）；仅当子规范内容变得复杂时，才将其升级为独立目录。子规范间的交叉契约存储在总括性规范的
```
index.md
```
  中。
针对范围的一个特殊例外：规范确认后，将匹配的功能更新为可构建形态（具体编辑操作见规范编写完成后第3步）。绝不要将原子任务列表转储到范围中。无匹配功能时：提供注册选项（参见派生任务步骤）。

工件基础目录：规范默认存储在

docs/

下。如果

docs/

是已发布的文档站点（检测到

docusaurus.config.*

、

.vitepress/

、

mkdocs.yml

、Astro Starlight或Nextra），则使用

.workflow/

替代（

.workflow/specs/

）。始终遵循已存在的基础目录（此处路径假设为

docs/

）。

Portability (any OS, any agent)

可移植性（支持任意操作系统、任意Agent）

Commands:
```
git
```
is the only required CLI, same on every OS. Other shell snippets (
```
mkdir -p
```
,
```
date
```
,
```
find
```
,
```
ls
```
,
```
cat
```
,
```
wc
```
) are POSIX reference, not literal scripts; use your agent's cross platform file tools (read, search/glob, write, create dir) and your knowledge of today's date. Create
```
docs/specs/
```
with your write tool, not
```
mkdir
```
.
Bundled files:
```
agent-prompt.md
```
,
```
agent-modes/*.md
```
, and
```
spec-template.md
```
live at paths relative to this skill's folder. The main thread reads these itself right before it writes the spec (see Write the spec):
```
agent-prompt.md
```
(the persona, rules, and report format), the one matching
```
agent-modes/<mode>.md
```
, and
```
spec-template.md
```
(the section structure). Read them only at write time, not during pre-flight, so they don't sit in context through the whole interview.
No interactive question support? Use whatever your agent provides (an options picker) and fall back only where missing: ask the question rounds as plain text with the same options.

命令：
```
git
```
是唯一必需的CLI工具，所有操作系统通用。其他Shell代码片段（
```
mkdir -p
```
、
```
date
```
、
```
find
```
、
```
ls
```
、
```
cat
```
、
```
wc
```
）是POSIX参考，而非字面脚本；使用Agent的跨平台文件工具（读取、搜索/通配符、写入、创建目录）以及当前日期信息。使用写入工具创建
```
docs/specs/
```
，而非
```
mkdir
```
命令。
捆绑文件：
```
agent-prompt.md
```
、
```
agent-modes/*.md
```
和
```
spec-template.md
```
存储在此技能文件夹的相对路径下。主线程仅在编写规范之前读取这些文件（参见编写规范）：
```
agent-prompt.md
```
（角色、规则和报告格式）、与当前模式匹配的
```
agent-modes/<mode>.md
```
文件，以及
```
spec-template.md
```
（章节结构）。仅在编写时读取，而非预检查阶段，避免整个访谈过程中占用上下文。
不支持交互式提问？ 使用Agent提供的任何功能（选项选择器），仅在缺失时回退：以纯文本形式提出多轮问题，并提供相同选项。

Execution

执行流程

Step 0: Topic check (before pre-flight)

步骤0：主题检查（预检查之前）

If no design topic was provided (

/architect

with no argument or an empty description), stop and ask before doing anything else:

"What design decision do you want to work through? Describe the feature, system, or choice you need to design in one or two sentences."

Wait for the answer; use it as the design topic before pre-flight.

如果未提供设计主题（运行/architect时无参数或描述为空），停止操作并先询问：

"你想解决什么设计决策问题？用一两句话描述你需要设计的功能、系统或选择。"

等待回答；将回答作为设计主题，再进行预检查。

Pre-flight (main model)

预检查（主模型）

Run these steps (the

git

commands are literal; everything else uses your agent's file tools):

Freshness (teams):
```
git fetch
```
quietly, pick the base branch (
```
main
```
if
```
git rev-parse --verify main
```
succeeds, else
```
master
```
), count commits behind with
```
git rev-list --count HEAD..origin/<base>
```
. If >0, warn "pull first" before deciding (a teammate may have added specs or changed this feature).
Resolve the spec location (
```
SPEC_DIR
```
) = the scope workspace mirrored into
```
docs/specs/
```
: single repo →
```
docs/specs/
```
; monorepo workspace →
```
docs/specs/<workspace>/
```
; repo wide →
```
docs/specs/_root/
```
. Determine
```
<workspace>
```
as the scope does (topic/path/scope row). Create the directory if missing.
Today's date: use today's date (inject it into the spec).
List existing specs in this location: files named
```
NNNN-*.md
```
plus any
```
index.md
```
in
```
$SPEC_DIR
```
, for numbering (per location) and related decision detection.
Count source files (e.g.
```
.ts
```
,
```
.tsx
```
,
```
.js
```
,
```
.py
```
,
```
.go
```
,
```
.rs
```
,
```
.java
```
), excluding
```
node_modules/
```
,
```
.git/
```
,
```
dist/
```
. Informs how much code there is to read, and whether to offload that reading to a
```
scout
```
subagent.
Read project context, the source of truth for the stack and community skills: root
```
AGENTS.md
```
(fall back to
```
CLAUDE.md
```
, else MISSING), plus the nested
```
<area>/AGENTS.md
```
for this feature's area if one exists (e.g.
```
src/auth/AGENTS.md
```
for an auth feature).
Read the build approach for THIS feature: the delivery strategy that governs how the spec's
```
## Build plan
```
is ordered and sliced. Precedence: this feature's scope row
```
Approach
```
override if declared, else the project default (root
```
AGENTS.md
```
first, else the scope header in
```
docs/scope/
```
). A feature with its own approach is built by ITS approach; others use the project default. The four imply materially different
```
## Build plan
```
orderings, not the same order relabeled: Tracer Bullet stands up a thin end to end thread through every layer first, then thickens; Skateboard builds the thinnest usable whole first, then grows; Facade leads with the UI shell on placeholder data and defers the migration (a prototype path); Journey completes one user path's tasks fully before the next. A project specific variant is possible. If neither records one, note the assumption and set the default by Staff/Principal judgment (prefer end to end Tracer Bullet slices for production work). Let the recorded approach visibly shape the ordering.
Locate the linked scope feature (if any): cheaply scan
```
docs/scope/
```
filenames/headings (including per workspace subdirs) for a feature matching this topic; open only the single scope file containing it (
```
scope.md
```
, or the matching
```
<epic>.md
```
in a split). If found, read that row's intent plus any acceptance criteria seeds (they seed Stage (a)) and remember the file/row for the derive tasks and linking steps; this also settles feature linked vs standalone status. If no row matches, note the standalone decision path and don't create one now.
(Optional) list installed skills dirs for availability only (
```
.claude/skills/
```
,
```
.agents/skills/
```
,
```
skills/
```
). Relevance is decided by AGENTS.md plus the feature, not name matching.

From the spec list (paths relative to

$SPEC_DIR

Next number: highest existing + 1, zero padded to 4 digits;
```
0001
```
if none (an umbrella directory counts as one number). Collision guard (teams): list again
```
$SPEC_DIR
```
immediately before you write; if the chosen
```
NNNN
```
exists, bump to the next free number. Never overwrite an existing spec; after writing, confirm no concurrent run took the same number.
Filename / shape:
```
kebab-case
```
slug from the topic, max 5 words, no articles, lowercase.
- Simple decision →
```
$SPEC_DIR/NNNN-kebab-title.md
```
  .
- Umbrella (splits into ≥2 related sub decisions) → directory
```
$SPEC_DIR/NNNN-kebab-title/
```
  with
```
index.md
```
  (the umbrella decision listing its children),
```
rationale.md
```
  (the reasoning + any inventories/audits), and child specs
```
NNNN-child.md
```
  inside it. Decide from the topic's breadth before you write, and hold the shape in mind as you write.
Related specs: go in two passes so this stays cheap as specs accumulate. First read only the title line of each existing spec (cheap even at dozens of them); then read the first 20 lines (title, status, opening of Context) of just the few whose title plausibly overlaps this topic, to confirm. Flag matches.
Child of umbrella detection: if the topic is a sub decision of an existing umbrella (
```
$SPEC_DIR/NNNN-<umbrella>/
```
), e.g. one that surfaced while building under it, place the new spec inside that directory as the next child (
```
NNNN-child.md
```
) and add it to the umbrella's
```
index.md
```
list, not a new top level spec. Same path when
```
/develop
```
hits a decision partway through a build. Tell the engineer where it's going.
Update/supersede detection: if an existing spec clearly overlaps the topic (same domain, system, decision), before the staged conversation present a decision panel (plain text options where the agent has no picker; the picker adds Other automatically): "I found an existing spec that may overlap:
```
[path]
```
, [title]. How should I treat this?", options: New decision (create a new spec) · Update the existing spec in place · Supersede it (a new spec replaces it). Default to the "(recommended)" option by overlap strength (nearly identical → Update or Supersede; adjacent → New). On update/supersede: set OPERATION, read the existing spec in full, and skip the staged conversation for in place updates.
- Assumed spec found: if the overlapping spec's
```
**Status**:
```
  is
```
Assumed
```
  , this is a ratify, not the panel above. Follow Ratify an assumed decision (run the design conversation, then either fill in the real content and clear
```
Assumed
```
  , or supersede if the assumption was wrong).

Community skills come from the project's

AGENTS.md

, never a hardcoded name table (names and stacks change). Project wide skills/conventions live in root

AGENTS.md

, area specific ones in the nested

<area>/AGENTS.md

(maintained by

/audit

and

/sync

Read root
```
AGENTS.md
```
and the nested
```
AGENTS.md
```
for this feature's area; their
```
## Agent skills
```
section lists each installed skill as a bullet with its location and a one line note on what it governs, so you can pick out the relevant ones and their paths directly.
Identify only the skills relevant to this feature. Take each relevant skill's path and note from that
```
## Agent skills
```
bullet, and open it on demand while writing, only if it materially shapes the decision (see Write the spec, item 12). Skip skills the feature doesn't touch.
Available ≠ relevant. You may list the installed skills dirs to see what exists, but relevance comes from the feature plus
```
AGENTS.md
```
. If a clearly relevant skill is installed but not yet referenced in
```
AGENTS.md
```
, use it anyway and flag (spec Follow-up) that it belongs in the right context file: root if project wide, nested
```
<area>/AGENTS.md
```
if area specific.
Whatever the context files show the project already uses (a BaaS, an ORM, a payment provider, an auth library) is what your library/provider recommendation must build on or prefer, not an unrelated external tool. If a genuinely better option isn't installed, note it as a spec Follow-up rather than silently assuming it.

Workflow skills (never treat as community skills):

audit

architect

scope

develop

check

test

document

debug

sync

, plus new workflow skills as they're created.

执行以下步骤（

git

命令为字面命令；其他操作使用Agent的文件工具）：

新鲜度（团队场景）：静默执行
```
git fetch
```
，选择基础分支（如果
```
git rev-parse --verify main
```
成功则为
```
main
```
，否则为
```
master
```
），使用
```
git rev-list --count HEAD..origin/<base>
```
计算落后的提交数。如果大于0，在决策前提醒"先拉取最新代码"（队友可能已添加规范或修改此功能）。
解析规范位置 (
```
SPEC_DIR
```
) = 范围工作区映射到
```
docs/specs/
```
：单仓库 →
```
docs/specs/
```
；单体仓库工作区 →
```
docs/specs/<workspace>/
```
；仓库级 →
```
docs/specs/_root/
```
。根据范围（主题/路径/范围行）确定
```
<workspace>
```
。如果目录不存在则创建。
当前日期：使用当前日期（注入到规范中）。
列出此位置的现有规范：
```
$SPEC_DIR
```
下名为
```
NNNN-*.md
```
的文件以及任何
```
index.md
```
文件，用于编号（按位置）和检测相关决策。
统计源文件数量（例如
```
.ts
```
、
```
.tsx
```
、
```
.js
```
、
```
.py
```
、
```
.go
```
、
```
.rs
```
、
```
.java
```
），排除
```
node_modules/
```
、
```
.git/
```
、
```
dist/
```
。用于了解需要读取的代码量，以及是否将读取任务委托给
```
scout
```
subagent。
读取项目上下文，技术栈和社区技能的权威来源：根目录的
```
AGENTS.md
```
（如果不存在则回退到
```
CLAUDE.md
```
，否则标记为MISSING），以及此功能所属区域的嵌套
```
<area>/AGENTS.md
```
（例如，认证功能对应
```
src/auth/AGENTS.md
```
）。
读取此功能的构建方式：规范的
```
## 构建计划
```
的排序和拆分遵循的交付策略。优先级：此功能的范围行
```
Approach
```
覆盖值（如果已声明），否则为项目默认值（优先根目录
```
AGENTS.md
```
，否则为
```
docs/scope/
```
中的范围标题）。有独立构建方式的功能按自身方式构建；其他功能使用项目默认值。四种方式意味着
```
## 构建计划
```
的排序有本质区别，而非相同顺序的重命名：Tracer Bullet先搭建贯穿所有层级的端到端基础框架，再逐步完善；Skateboard先构建最精简的可用完整版本，再逐步扩展；Facade先基于占位数据构建UI外壳，延迟迁移（原型路径）；Journey先完整完成一个用户路径的所有任务，再进行下一个。可能存在项目特定变体。如果两者都未记录，注明假设并根据资深/首席工程师的判断设置默认值（生产环境优先选择端到端的Tracer Bullet拆分）。让记录的构建方式明显影响排序。
定位关联的范围功能（如果有）：快速扫描
```
docs/scope/
```
的文件名/标题（包括工作区子目录），查找与当前主题匹配的功能；仅打开包含该功能的单个范围文件（
```
scope.md
```
，或拆分后的匹配
```
<epic>.md
```
）。如果找到，读取该行的意图以及任何验收标准种子（用于Stage (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行（标题、状态、背景开头），确认是否相关。标记匹配项。
总括性规范的子决策检测：如果当前主题是现有总括性规范（
```
$SPEC_DIR/NNNN-<umbrella>/
```
）的子决策，例如在构建总括性规范过程中出现的决策，将新规范放在该目录下作为下一个子规范（
```
NNNN-child.md
```
），并添加到总括性规范的
```
index.md
```
列表中，而非作为新的顶级规范。当/develop在构建过程中遇到决策时，也遵循此路径。告知工程师规范的存储位置。
更新/替代检测：如果现有规范明显与当前主题重叠（相同领域、系统、决策），在分阶段对话前呈现决策面板（如果Agent无选择器则使用纯文本选项；选择器自动添加Other选项）："我发现一个可能重叠的现有规范：
```
[路径]
```
，[标题]。应如何处理？"，选项：新决策（创建新规范） · 直接更新现有规范 · 替代现有规范（创建新规范替换它）。根据重叠程度设置默认的"（推荐）"选项（几乎完全相同 → 更新或替代；相关 → 新规范）。如果选择更新/替代：设置OPERATION，完整读取现有规范，直接更新时跳过分阶段对话。
- 发现Assumed规范：如果重叠规范的
```
**Status**:
```
  为
```
Assumed
```
  ，则执行批准流程，而非上述面板。遵循批准假定决策（运行设计对话，然后要么填充真实内容并清除
```
Assumed
```
  状态，要么如果假设错误则替代）。

社区技能来自项目的

AGENTS.md

，而非硬编码名称表（名称和技术栈会变化）。项目级技能/约定存储在根目录

AGENTS.md

，区域特定技能存储在嵌套的

<area>/AGENTS.md

（由/audit和/sync维护）：

读取根目录
```
AGENTS.md
```
和此功能所属区域的嵌套
```
AGENTS.md
```
；它们的
```
## Agent skills
```
部分以项目符号列出每个已安装的技能，包含其位置和功能说明，因此可直接挑选相关技能及其路径。
仅识别与当前功能相关的技能。记录每个相关技能的路径和说明，在编写时按需打开，仅当它对决策有实质性影响时（参见编写规范第12项）。跳过与当前功能无关的技能。
可用≠相关。可列出已安装的技能目录查看现有技能，但相关性由功能和
```
AGENTS.md
```
决定。如果明显相关的技能已安装但未在
```
AGENTS.md
```
中引用，仍可使用，并在规范的后续工作部分标记它应添加到正确的上下文文件中：项目级添加到根目录，区域特定添加到嵌套
```
<area>/AGENTS.md
```
。
无论上下文文件显示项目已使用什么（BaaS、ORM、支付提供商、认证库），推荐的库/提供商都必须基于或优先使用这些现有工具，而非无关的外部工具。如果确实有更好的选项未安装，在规范的后续工作部分注明，而非静默假设使用该选项。

工作流技能（绝不视为社区技能）：

audit

、

architect

、

scope

、

develop

、

check

、

test

、

document

、

debug

、

sync

，以及新增的工作流技能。

Scope validation, framing, and staged design conversation

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

For create or supersede operations, this is a hard gate: read
internal/design-conversation.md
in full before you ask the engineer a single design question, and follow it. It holds Scope validation (including the already built documentation path), Framing, and the staged design conversation. Asks vs acts above is only the intent, not the protocol; do not open the interview, generate questions, or write the spec until you have read that file. (Skip only for in place spec updates.)

对于创建或替代操作，这是硬性要求：在向工程师提出任何设计问题之前，完整阅读
internal/design-conversation.md
并遵循其要求。该文件包含范围验证（包括已构建文档路径）、框架构建和分阶段设计对话。上述询问与执行仅为设计意图，而非协议；在未读取该文件之前，不得开启访谈、生成问题或编写规范。（直接更新规范时可跳过。）

Write the spec (main thread)

编写规范（主线程）

After the staged conversation, you write the spec yourself. Do not spawn anyone to draft, research, or critique it. Resolve this skill's folder to an absolute path (you already resolve these relative paths, so you know the folder) and Read three files now (only now, so they don't sit in context through the interview):

agent-prompt.md

spec-template.md

, and the one mode file matching the inferred MODE:

```
FEATURE
```
→
```
agent-modes/feature.md
```
```
ARCHITECTURE
```
→
```
agent-modes/architecture.md
```
```
ENHANCEMENT
```
→
```
agent-modes/enhancement.md
```

CROSS-CUTTING

→

agent-modes/cross-cutting.md

Then write the spec, applying:

From
agent-prompt.md
: adopt the persona ("Who you are / How you think / What you do NOT do") and follow the common instructions, Step 0, Step 0b,
```
## Expert rules that apply to all modes
```
, and
```
## Report format
```
. At
```
## Instructions by mode
```
, follow the one mode file above as the only mode specific block; ignore the other mode files.
```
agent-prompt.md
```
is written as a subagent brief with ALL_CAPS placeholders; read those placeholders as the inputs you already gathered in the conversation (listed below), and apply the rules to yourself.
From
spec-template.md
: use only the part between
```
=== SPEC TEMPLATE START ===
```
and
```
=== SPEC TEMPLATE END ===
```
(the spec section structure and field guidance). The trailing reference/meta sections (
```
## Filename conventions
```
, the
```
## Status values
```
table, the umbrella structure / child status notes,
```
## Writing rules
```
) are your own guidance: you resolved the filename, shape, and initial
```
**Status**:
```
in pre-flight; write the
```
**Status**:
```
line per the "On the initial
```
**Status**:
```
line" rule in
```
## Expert rules that apply to all modes
```
. Do not edit
```
spec-template.md
```
.

References and links: reuse the Stage (c)
REFERENCES_LEVEL
; do not fetch now. Write the

## References

section and

(basis: ...)

citations at that level, per On sourcing & citations in

agent-prompt.md

. The Stage (c) checks ran once; reuse only the links they confirmed, and cite any unverified source by name with no URL. Only if Stage (c) never ran (e.g. the documentation path), present the References consent panel now (recommended pick

No references, keep it clean

) and set

REFERENCES_LEVEL

none

sources

(

sources+links

is not offered, no fetch is available at write time).

The inferred MODE (from Framing) is already one of

FEATURE

ARCHITECTURE

ENHANCEMENT

CROSS-CUTTING

The inputs to apply (you already have them from the design conversation and pre-flight):

Design topic (from the user's original message)
The inferred framing: MODE, platform (web/mobile/API), stack & conventions (from
```
AGENTS.md
```
), and any constraints/compliance inferred or confirmed 2a. The feature's build approach (pre-flight precedence: scope row
```
Approach
```
override, else the project default from
```
AGENTS.md
```
/scope header, else the noted default) →
```
BUILD_APPROACH
```
; order and slice
```
## Build plan
```
by what the approach implies for this feature
All staged conversation answers, stage by stage: the confirmed acceptance criteria (already IDed AC-1…, to seed
```
## Requirements
```
), the confirmed data model (entities/fields/relationships, the target that seeds the
```
## Build plan
```
migration, sized to the feature), the confirmed stack/tool picks, API surface, authz model, and edge cases. On the documentation path (staged conversation skipped) treat it as
```
"Staged design skipped, documenting an already-made decision"
```
, not an error 3a. The RECOMMEND items →
```
RECOMMEND_ITEMS_OR_NONE
```
: the specific decisions you must make and justify (tool/provider aligned to the stack, session model, etc.); make each call, don't echo it back as an open question. If none, treat as
```
"none"
```
3b. The References level →
```
REFERENCES_LEVEL
```
(
```
none
```
|
```
sources
```
|
```
sources+links
```
, per the rule above). If Stage (c) never ran and you have not asked, default to
```
none
```
Context file contents:
```
AGENTS.md
```
(root + the feature area's nested), or
```
CLAUDE.md
```
as fallback, or "MISSING"
Existing spec list (filenames + first line of each)
Related spec paths (flagged in pre-flight)
The resolved spec location (
```
$SPEC_DIR
```
), next number, and shape: a single file
```
$SPEC_DIR/NNNN-title.md
```
, or a directory
```
$SPEC_DIR/NNNN-title/
```
(
```
index.md
```
+
```
rationale.md
```
, plus child specs for an umbrella). Umbrella: write the named child decisions; any inventory/audit goes in
```
rationale.md
```
, never in
```
docs/scope/
```
, never loose in the code tree. Only the
```
index.md
```
carries a
```
**Status**:
```
line (it mirrors the feature); child specs omit the lifecycle Status (spec content governed by the umbrella)
Source file count (whether there's code to read; for a large ENHANCEMENT/CROSS-CUTTING codebase, offload the reading to a
```
scout
```
subagent per Subagents and write from its map)
Operation:
```
create
```
|
```
update
```
|
```
supersede
```
Today's date (from pre-flight)
Documentation context (if the "already built" path ran: the engineer's free text answers about why this was chosen, alternatives, and tradeoffs)
Community skills relevant to this feature (identified from
```
AGENTS.md
```
, per pre-flight): open a skill file on demand, only if it materially shapes this decision; its conventions are authoritative when consulted. Name each in the
```
## Decision
```
Implementation skills field.

分阶段对话完成后，自行编写规范。绝不生成任何subagent来草拟、研究或评审规范。将此技能的文件夹解析为绝对路径（已解析这些相对路径，因此已知文件夹位置），并立即读取三个文件（仅此时读取，避免整个访谈过程中占用上下文）：

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
：采用角色设定（"你的身份 / 你的思考方式 / 你绝不做的事"）并遵循通用说明、Step 0、Step 0b、
```
## 适用于所有模式的专家规则
```
和
```
## 报告格式
```
。在
```
## 按模式分类的说明
```
部分，仅遵循上述匹配的模式文件；忽略其他模式文件。
```
agent-prompt.md
```
以subagent brief形式编写，包含全大写占位符；将这些占位符视为对话中已收集的输入（如下所列），并将规则应用于自身。
来自
spec-template.md
：仅使用
```
=== SPEC TEMPLATE START ===
```
和
```
=== SPEC TEMPLATE END ===
```
之间的部分（规范章节结构和字段指南）。末尾的参考/元数据部分（
```
## 文件名约定
```
、
```
## 状态值
```
表格、总括性结构/子规范状态说明、
```
## 编写规则
```
）是供你参考的内容：已在预检查阶段解析了文件名、形态和初始
```
**Status**:
```
；根据
```
## 适用于所有模式的专家规则
```
中的"关于初始
```
**Status**:
```
行"规则编写
```
**Status**:
```
行。不得编辑
```
spec-template.md
```
。

参考和链接：复用Stage (c)的
REFERENCES_LEVEL
；此时不进行网络获取。根据

agent-prompt.md

中的关于来源与引用规则，编写

## 参考

部分和

(basis: ...)

引用，遵循该级别要求。Stage (c)检查仅执行一次；仅复用已确认的链接，未验证的来源仅按名称引用，不提供URL。如果Stage (c)从未执行（例如文档路径），此时呈现参考同意面板（推荐选择

无参考，保持简洁

）并将

REFERENCES_LEVEL

设置为

none

或

sources

（不提供

sources+links

选项，编写时无法进行网络获取）。

推断的MODE（来自框架构建）已为

FEATURE

ARCHITECTURE

ENHANCEMENT

CROSS-CUTTING

之一。

需应用的输入（已从设计对话和预检查阶段收集）：

设计主题（来自用户原始消息）
推断的框架：MODE、平台（web/mobile/API）、技术栈与约定（来自
```
AGENTS.md
```
），以及任何推断或确认的约束/合规要求 2a. 功能的构建方式（预检查优先级：范围行
```
Approach
```
覆盖值，否则为
```
AGENTS.md
```
/范围标题中的项目默认值，否则为注明的默认值）→
```
BUILD_APPROACH
```
；根据该方式对
```
## 构建计划
```
进行排序和拆分
分阶段对话的所有答案，按阶段整理：确认的验收标准（已标记为AC-1…，用于填充
```
## 需求
```
）、确认的数据模型（实体/字段/关系，用于填充
```
## 构建计划
```
中的迁移目标，与功能规模匹配）、确认的技术栈/工具选择、API接口、授权模型和边缘情况。对于文档路径（跳过分阶段对话），视为
```
"跳过分阶段设计，记录已做出的决策"
```
，而非错误 3a. 推荐项 →
```
RECOMMEND_ITEMS_OR_NONE
```
：必须做出并证明合理性的具体决策（与技术栈对齐的工具/提供商、会话模型等）；做出每个决策，不要将其作为开放问题反馈。如果无推荐项，视为
```
"none"
```
3b. 参考级别 →
```
REFERENCES_LEVEL
```
（
```
none
```
|
```
sources
```
|
```
sources+links
```
，遵循上述规则）。如果Stage (c)从未执行且未询问，默认设置为
```
none
```
上下文文件内容：
```
AGENTS.md
```
（根目录+功能区域的嵌套文件），或回退到
```
CLAUDE.md
```
，或"MISSING"
现有规范列表（文件名+每个文件的第一行）
相关规范路径（预检查阶段标记）
解析后的规范位置（
```
$SPEC_DIR
```
）、下一个编号和形态：单文件
```
$SPEC_DIR/NNNN-title.md
```
，或目录
```
$SPEC_DIR/NNNN-title/
```
（
```
index.md
```
+
```
rationale.md
```
，总括性规范还有子规范）。总括性规范：编写指定的子决策；任何清单/审计报告存储在
```
rationale.md
```
中，绝不存储在
```
docs/scope/
```
或代码树的其他位置。仅
```
index.md
```
包含
```
**Status**:
```
行（与功能状态同步）；子规范省略生命周期状态（规范内容由总括性规范管理）
源文件数量（是否有代码需要读取；对于大型ENHANCEMENT/CROSS-CUTTING代码库，根据Subagents将读取任务委托给
```
scout
```
subagent，并基于其返回的映射编写规范）
操作类型：
```
create
```
|
```
update
```
|
```
supersede
```
当前日期（来自预检查阶段）
文档上下文（如果走"已构建"路径：工程师关于决策原因、替代方案和权衡的自由文本回答）
与当前功能相关的社区技能（来自预检查阶段的
```
AGENTS.md
```
识别）：仅当对决策有实质性影响时，按需打开技能文件；其约定在参考时具有权威性。在
```
## 决策
```
的实施技能字段中列出每个相关技能。

After the spec is written

规范编写完成后

Once the spec file exists, read

internal/after-subagent.md

and follow it for checking the spec yourself, reviewing it yourself, confirmation, status ratification, scope linking, and the final spoken summary. Do not read it before you write the spec.

规范文件生成后，读取

internal/after-subagent.md

并遵循其要求，自行检查规范、评审规范、确认、状态批准、范围关联和最终口头总结。编写规范前不得读取该文件。

Update / Supersede path

更新 / 替代路径

If the task is to update or supersede an existing spec:

Pre-flight: read the existing spec in full
Skip the staged conversation if operation is in place update
Set the operation:
```
update
```
or
```
supersede
```
If supersede: write the new spec AND update the old spec's status to
```
Superseded by [NNNN](NNNN-title.md)
```

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

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

Ratify an assumed decision

批准假定决策

When the topic resolves to an existing

Assumed

spec (the engineer built first via

/develop

's escape hatch and is now ratifying, often phrased

/architect <feature>: ratify …

), pre-flight will find that spec. Read it in full: its

## Owed decision

## Assumption built on

, and

## Code area

tell you what was decided provisionally and where the code lives. Then run the normal design conversation, anchored to what was actually built, and deliberate the decision properly. Two outcomes:

The assumption holds. Fill in the real decision content (Context, Options considered, Decision, Rationale, the design section, Consequences) so the spec becomes a genuine deliberated record, and clear
```
Assumed
```
: set the
```
**Status**:
```
line to the feature's lifecycle state (
```
In Progress
```
if the feature is built but not yet
```
done
```
,
```
Accepted
```
if it is already verified and tested).
```
/develop
```
then closes it to
```
Accepted
```
at
```
done
```
as usual. The decision is no longer ephemeral.
The assumption was wrong. Write a corrected spec (
```
create
```
or
```
supersede
```
) with the real decision, mark the assumed spec
```
Superseded by [NNNN](…)
```
, and tell the engineer the build rests on a wrong assumption and should be redone against the corrected spec.

Either way, ratification is why an

Assumed

spec can leave that state:

/develop

records the assumption,

/architect

confirms or corrects it and supplies the reasoning. Do not leave a spec

Assumed

after a ratify run.

当主题对应现有

Assumed

规范（工程师通过/develop的应急通道先构建，现在进行批准，通常表述为

/architect <feature>: ratify …

），预检查阶段会找到该规范。完整读取该规范：其

## 待做决策

、

## 构建基于的假设

和

## 代码区域

会告知你临时做出的决策以及代码位置。然后运行正常的设计对话，基于实际构建内容进行锚定，正式审议决策。有两种结果：

假设成立：填充真实的决策内容（背景、考虑的选项、决策、理由、设计部分、影响），使规范成为真正经过审议的记录，并清除
```
Assumed
```
状态：将
```
**Status**:
```
行设置为功能的生命周期状态（如果功能已构建但未标记为
```
done
```
则为
```
In Progress
```
，如果已验证和测试则为
```
Accepted
```
）。/develop会在功能标记为
```
done
```
时将其状态关闭为
```
Accepted
```
。决策不再是临时的。
假设错误：编写修正后的规范（
```
create
```
或
```
supersede
```
），记录真实决策，将假定规范标记为
```
Superseded by [NNNN](…)
```
，并告知工程师构建基于错误假设，应根据修正后的规范重新构建。

无论哪种情况，批准流程都是

Assumed

规范脱离该状态的唯一方式：/develop记录假设，/architect确认或修正假设并提供理由。批准运行完成后，不得保留

Assumed

状态的规范。

Reference files

参考文件

Spec template:
```
spec-template.md
```
(the main thread reads it at write time)
Spec writing rules & persona:
```
agent-prompt.md
```
(the main thread reads it at write time)
Mode specific writing instructions:
```
agent-modes/*.md
```
(read only the matching mode file, at write time)
Main thread design conversation:
```
internal/design-conversation.md
```
(read only for create/supersede)
Agent Skill & MCP offer:
```
internal/tool-discovery.md
```
(read only when the stack walk settles a new tool; it asks before it searches, and the registry fetch then runs in a
```
researcher
```
subagent)
Main thread completion flow:
```
internal/after-subagent.md
```
(read only after the spec is written)
The staged design conversation is generated per feature (see Staged design conversation, stages a to f), not stored; there are no canned question lists. If a topic is too vague to generate from, narrow it first (scope validation, or one clarifying question), never fall back to generic MCQs

规范模板：
```
spec-template.md
```
（主线程在编写时读取）
规范编写规则与角色：
```
agent-prompt.md
```
（主线程在编写时读取）
模式特定编写说明：
```
agent-modes/*.md
```
（仅读取匹配的模式文件，编写时读取）
主线程设计对话：
```
internal/design-conversation.md
```
（仅创建/替代操作时读取）
Agent Skill & MCP指南：
```
internal/tool-discovery.md
```
（仅当技术栈分析确定需要新工具时读取；搜索前会询问，然后由
```
researcher
```
subagent执行注册表获取）
主线程完成流程：
```
internal/after-subagent.md
```
（仅规范编写完成后读取）
分阶段设计对话根据功能生成（参见分阶段设计对话，阶段a至f），不存储；无固定问题列表。如果主题过于模糊无法生成问题，先缩小范围（范围验证，或一个澄清问题），绝不回退到通用多项选择题