develop

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. 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.

本技能生成的所有内容（文件和消息）都使用简单平实的语言撰写。保留具有实际意义的技术术语，并以平实语言解释每个术语。切勿使用破折号或连字符作为标点：不要使用长破折号、短破折号，也不要使用连字符构成的复合词。写

read only

，不要写

read-only

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

What this skill does

本技能的功能

The builder: turns a spec plus project conventions into working code. Tracks: UI (components, pages, layouts;

ui-guide.md

), Logical (APIs, services, data layers, business logic, integrations;

logical-guide.md

), or both (e.g. "auth" = sign in pages plus session logic → run both). Step 0 gates on the spec so load bearing choices (an auth approach, a payment provider) are decided in

/architect

, not silently invented partway through the build.

构建器：将规范和项目约定转换为可运行的代码。涵盖两类内容：UI（组件、页面、布局；参考

ui-guide.md

）、逻辑层（API、服务、数据层、业务逻辑、集成；参考

logical-guide.md

），或两者兼具（例如“认证”= 登录页面 + 会话逻辑 → 同时运行两类构建）。第0步会检查规范，确保关键决策（如认证方案、支付提供商）已在

/architect

中确定，不会在构建过程中凭空生成。

Asks vs acts

请求与执行

Gates, then acts: no upfront question rounds like

/architect

. Read the decision, build, ask only what the design left open (the visual direction when no reference was given; a business rule the spec didn't settle). Infer from the spec,

AGENTS.md

, and codebase; ask only what can't be inferred; recommend local implementation choices.

先检查，再执行：不会像

/architect

那样提前进行多轮提问。读取已有的决策，开始构建，仅询问设计中未明确的内容（无参考时的视觉方向；规范未确定的业务规则）。从规范、

AGENTS.md

和代码库中推断信息；仅询问无法推断的内容；推荐本地化实现方案。

Artifact ownership

产物所有权

Writes app code (plus CSS/tokens for UI).
Scope (
```
docs/scope/
```
): only the Step 4 touches (feature status →
```
in-progress
```
, milestone sub boxes,
```
Build it
```
box, code pointer). Never marks a feature
```
done
```
(waits for
```
/check verify
```
and
```
/test
```
), never ticks
```
Verify it
```
or
```
Test it
```
, never creates files in
```
docs/scope/
```
(scopes only; analysis/research is
```
/architect
```
's, in the spec's
```
rationale.md
```
).
Never writes specs (flags the need, defers to
```
/architect
```
); never restructures root
```
AGENTS.md
```
(that's
```
/audit
```
); new area conventions go via
```
/sync
```
afterwards.
One spec touch: the
```
**Status**:
```
line (umbrella decision → the
```
index.md
```
's, never a child's), plus filling the feature's spec pointer line. Build start:
```
Proposed
```
→
```
In Progress
```
; build lands (feature →
```
done
```
):
```
In Progress
```
→
```
Accepted
```
(a spec is not
```
Accepted
```
until its feature ships). Never edit spec content, only that line, surgically: read it again right before writing; unexpected state (already
```
Accepted
```
,
```
Superseded
```
) → flag, don't clobber.
Artifact base:
```
docs/
```
by default,
```
.workflow/
```
if
```
docs/
```
is a published docs site. Read from whichever exists (paths here assume
```
docs/
```
).
Shared scope: read it again right before ticking, edit only the specific checkbox, status, or pointer line (never rewrite the file); feature not as expected (already
```
done
```
, reworked) → flag, don't overwrite. The freshness check guards against rebuilding what a teammate shipped.

编写应用代码（以及UI相关的CSS/令牌）。
范围文档（
```
docs/scope/
```
）：仅第4步会修改（功能状态→
```
in-progress
```
、里程碑子项、
```
Build it
```
框、代码指针）。切勿将功能标记为
```
done
```
（需等待
```
/check verify
```
和
```
/test
```
完成），切勿勾选
```
Verify it
```
或
```
Test it
```
，切勿在
```
docs/scope/
```
中创建文件（仅处理范围内容；分析/研究属于
```
/architect
```
的工作，需放在规范的
```
rationale.md
```
中）。
切勿编写规范（标记需求，交由
```
/architect
```
处理）；切勿重构根目录下的
```
AGENTS.md
```
（这是
```
/audit
```
的职责）；新领域的约定需后续通过
```
/sync
```
处理。
仅修改规范中的一处内容：
```
**Status**:
```
行（仅修改总览决策的
```
index.md
```
，不修改子规范），以及填写功能的规范指针行。构建开始时：
```
Proposed
```
→
```
In Progress
```
；构建完成（功能上线）时：
```
In Progress
```
→
```
Accepted
```
（规范需等到功能上线后才会标记为
```
Accepted
```
）。切勿编辑规范内容，仅精准修改该行；若遇到意外状态（已标记为
```
Accepted
```
、
```
Superseded
```
）→ 标记问题，不要覆盖。
产物基础目录：默认是
```
docs/
```
，若
```
docs/
```
是已发布的文档站点则使用
```
.workflow/
```
。读取存在的目录（本文中的路径默认假设使用
```
docs/
```
）。
共享范围：修改前重新读取内容，仅编辑特定复选框、状态或指针行（切勿重写文件）；若功能状态不符合预期（已标记为
```
done
```
、已重写）→ 标记问题，不要覆盖。新鲜度检查可避免重复构建队友已完成的内容。

Portability (any OS, any agent)

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

Any Agent Skills client, macOS/Linux/Windows. Detection snippets are POSIX reference; use your agent's own cross platform file tools. Builds inline on the main thread (Step 3); the only subagents are a read only

scout

that explores code (Step 2.5) and a read only

researcher

for a doc check (Step 2.6, degrading to building from knowledge without web capability), both on the cheapest model. Bundled guides (

ui-guide.md

logical-guide.md

checklist.md

) and the build flow after the gate (

flow/build.md

) are paths relative to this skill's folder; the main thread reads them. No interactive question picker → ask the prompts as plain text with the same options.

支持任意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

）是相对于本技能文件夹的路径；主线程会读取这些文件。不使用交互式问题选择器→以纯文本形式提出包含相同选项的提示。

Execution

执行流程

Before you build: the project must already exist (except the scaffold task)

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

Exception: if this IS the scaffold sub task of the Stack and architecture foundation feature (prompt says

scaffold

, or the step initializes the project from the stack spec), creating the project IS the job. Read the ARCHITECTURE spec's

## Proposed stack

; run the framework's own init (

create-next-app

cargo new

, etc. per that stack); install base dependencies (framework, core runtime, only what the first slice needs); lay out directories; confirm a dev server or build runs. Scaffold steps derive from the stack decision (a decision spec has no build plan). Install just in time: NOT every library the spec names (email, monitoring, and so on); each later feature installs its own when built; only cross cutting tooling (lint, format, type strictness) comes early, via

/audit

+ the tooling task. Then proceed.

Otherwise

/develop

builds into an existing project. No skeleton (no

package.json

pyproject.toml

go.mod

/manifest, no source tree) and not the scaffold task → stop:

No project found to build into. Run the scaffold step first (the Stack and architecture feature's scaffold sub task, per your architecture spec), then run
/develop
again.

A project exists (even a bare scaffold) → proceed.

例外情况：如果这是Stack和架构基础功能的脚手架子任务（提示包含

scaffold

，或步骤从栈规范初始化项目），则创建项目是核心工作。读取ARCHITECTURE规范的

## Proposed stack

部分；运行框架自带的初始化命令（如

create-next-app

、

cargo new

等，取决于所选栈）；安装基础依赖（框架、核心运行时，仅安装首次切片所需的内容）；规划目录结构；确认开发服务器或构建命令可正常运行。脚手架步骤源自栈决策（决策规范无构建计划）。按需安装：不要安装规范中提到的所有库（如邮件、监控等）；后续每个功能在构建时自行安装所需库；仅提前安装跨领域工具（代码检查、格式化、类型严格性工具），通过

/audit

+ 工具任务完成。之后继续执行流程。

否则

/develop

会在已存在的项目中构建。若不存在项目骨架（无

package.json

pyproject.toml

go.mod

/清单文件，无源码树）且不是脚手架任务→停止执行：

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

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

Before you build: freshness & collaboration (don't build on stale state or over a teammate)

构建前：新鲜度与协作（不要基于过时状态构建，不要覆盖队友的工作）

Before mutating anything (skip silently if solo, offline, or not using git):

git fetch

quietly; base =

main

, else

master

; behind count (

git rev-list --count HEAD..origin/<base>

); uncommitted work (

git status --short

Behind (count > 0) → stop and warn: "You're N commits behind
```
origin/$BASE
```
. A teammate may have already changed or shipped this. Pull first, then run again."
Uncommitted work in the area you'll touch → warn: "You have uncommitted changes here. Commit or stash first so this build doesn't tangle with them." Let them proceed if they insist.
Feature
```
in-progress
```
in the scope AND its code area (pointer line's path) has recent commits by another author (
```
git log --format='%an' -- <area>
```
) → warn: "<feature> looks like it's partway through the build by someone else. Coordinate before continuing it." Confirm before proceeding.

Warnings, not hard blocks, but surface them.

在修改任何内容之前（单人、离线或不使用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>
```
）→警告："<feature> 看起来正在由其他人构建中。请先协作沟通，再继续。"继续前需确认。

以上为警告，而非强制阻止，但需明确提示。

Step 0: The spec gate (always first)

第0步：规范检查门（始终优先执行）

Is a decision owed and unrecorded? The test:

To build this, would you have to invent something the engineer hasn't decided?

If yes, stop and route to

/architect

(its spec is the build spec;

/develop

implements decisions, it doesn't make them). You'd have to invent:

A provider, library, integration, data model, or cross cutting pattern (e.g. auth provider, DB/ORM, caching strategy).
A whole UI page or screen: its design system (
```
design.md
```
there? if not, which direction?), sections/composition, component inventory, asset strategy (no screenshot, no repo images → e.g. an online source). Owed unless a
```
design.md
```
AND a page level spec pin these down.
A feature's behavior (search, a wizard: "what exactly should it do?" is open;
```
/architect
```
asks those questions). Owed unless a spec defines it.

NOT owed for pure implementation already specified: a small bug fix, a component matching an existing

design.md

, wiring already decided pieces, a copy tweak, anything an existing spec/

design.md

AGENTS.md

governs.

Don't hardcode to page names; apply the invent test to whatever was asked (a "home page" or "search filter" fails on a fresh project, passes once a spec/

design.md

exists). False negatives are the failure mode, building a real decision without noticing (what "just build the home page" looks like): when unsure, treat as owed and ask (panel below).

Read only what this feature needs, never the whole

docs/

tree: its one scope file and its one governing spec (single file, or umbrella

index.md

plus the one child speccing this sub task). No other features' rows, scope files, workspaces, or unrelated specs.

Check, in order:

Locate this feature's scope file (only that one). Monorepo →
```
docs/scope/<workspace>/
```
for the task's package. Pick the file (
```
scope.md
```
, or the matching
```
<epic>.md
```
in a split) from the At a glance table alone; read just this feature's section.
```
needs a decision
```
with no spec pointer yet → decision owed and missing. Malformed → flag and ask, don't guess.
Open the governing spec via the feature's
spec
pointer, reading only its build spec sections as defined in the build flow (
```
flow/build.md
```
), Step 2 item 1. Found → it's the spec; proceed. No pointer and no linked spec → targeted look in
```
docs/specs/<workspace>/
```
for one matching this feature's scope, never a blanket read.
The nearest
```
AGENTS.md
```
(workspace/area) may already capture the decision, synced from an earlier feature (e.g. "the auth provider is already chosen") → proceed without a new spec.

Decision owed and unrecorded → don't guess, don't silently stop. Ask (single select;

AskUserQuestion

on Claude Code):

question: "This looks like it needs an architecture decision first:
```
<name the specific load-bearing choice, e.g. 'which auth provider + session model'>
```
. How do you want to handle it?"
header: "spec first?"
options:
1. ```
Architect it first
```
  : "Recommended. Capture the decision in a spec before building, so the build has a spec." → end here with the handoff below. Do not build.
2. ```
No, not needed
```
  : "I've judged there's no real decision here; build directly." → proceed to the build flow (
```
flow/build.md
```
  ).
3. ```
Skip for now
```
  : "Build it without a spec; I'll backfill the decision later." → proceed to the build flow (
```
flow/build.md
```
  ), leaving the feature's
```
Needs spec?
```
  =
```
yes
```
  with a
```
⚠ spec pending
```
  note in the scope (
```
docs/scope/
```
  ).

The tool appends "Other" as a free text option automatically.

Architect it first

, end with:

Run this next, then come back to
/develop
:
/architect <feature>: <the specific decision to settle>
Once the spec exists, run
/develop <task>
again and I'll build to it.

No decision owed (pure implementation) → skip the question, proceed.

是否存在未确定且未记录的关键决策？测试标准：

要构建此项内容，你是否需要凭空创造工程师尚未确定的事项？

如果是，停止执行并引导至

/architect

（其规范为构建规范；

/develop

仅实现决策，不制定决策）。需要凭空创造的情况包括：

提供商、库、集成、数据模型或跨领域模式（如认证提供商、数据库/ORM、缓存策略）。
完整的UI页面或屏幕：其设计系统（是否有
```
design.md
```
？若无，采用何种方向？）、章节/布局、组件清单、资源策略（无截图、无仓库图片→例如使用在线资源）。除非
```
design.md
```
和页面级规范明确锁定这些内容，否则属于未确定事项。
功能的行为逻辑（搜索、向导：“具体应实现什么功能？”未明确；
```
/architect
```
会处理这些问题）。除非规范已定义，否则属于未确定事项。

以下情况不属于未确定事项，可直接实现：小bug修复、匹配现有

design.md

的组件、连接已确定的模块、文案调整、任何已有规范/

design.md

AGENTS.md

覆盖的内容。

不要硬编码页面名称；对所有请求应用“创造测试”（新项目中的“首页”或“搜索过滤器”会不通过测试，一旦有规范/

design.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

）：

问题：“此项内容似乎需要先确定架构决策：<明确关键选择，例如‘选择哪个认证提供商+会话模型’>。你希望如何处理？”
标题：“是否先制定规范？”
选项:
1. ```
先进行架构设计
```
  ：“推荐方案。在构建前将决策记录到规范中，确保构建有明确依据。”→到此为止，下方给出交接提示。不要进行构建。
2. ```
不需要
```
  ：“我判断此处无需实际决策；直接构建。”→进入构建流程（
```
flow/build.md
```
  ）。
3. ```
暂时跳过
```
  ：“不基于规范构建；我稍后补充决策。”→进入构建流程（
```
flow/build.md
```
  ），在范围文档（
```
docs/scope/
```
  ）中保留该功能的
```
Needs spec?
```
  =
```
yes
```
  ，并添加
```
⚠ spec pending
```
  注释。

工具会自动添加“其他”作为自由文本选项。

若选择

先进行架构设计

，结束时提示：

请先运行以下命令，再返回
/develop
：
/architect <feature>: <需确定的具体决策>
规范创建完成后，重新运行
/develop <task>
，我会基于规范进行构建。

若无未确定决策（仅需纯实现）→跳过提问，继续执行。

Build flow (Steps 1-4)

构建流程（第1-4步）

Once the gate clears (no decision owed, or the engineer chose

No, not needed

Skip for now

), read

flow/build.md

and follow its Steps 1-4: classify the track, load the decision and conventions, explore, optional doc check, build, then update the scope and report. Do not read

flow/build.md

when the gate ends the run (

Architect it first

, no build).

检查门通过后（无未确定决策，或工程师选择

不需要

暂时跳过

），读取

flow/build.md

并遵循其第1-4步：分类构建轨道、加载决策和约定、探索代码、可选文档检查、执行构建，然后更新范围文档并报告。若检查门终止运行（选择

先进行架构设计

，无需构建），则不要读取

flow/build.md

。

Reference files

参考文件

Build flow after the gate (Steps 1-4):
```
flow/build.md
```
UI build track:
```
ui-guide.md
```
Logical build track:
```
logical-guide.md
```
Accessibility checklist (UI track, Phase 5):
```
checklist.md
```
Project design system (UI track):
```
./design.md
```

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