scope

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

本技能的功能

Turns an idea into an ordered, coarse, living plan and keeps it honest as the product ships. Answers "what do I build, in what order, how heavy, which need a decision first?", not "how do I build this one thing?" (that is

/architect

and

/develop

Scope shape, coarse and small: a slim At a glance table (

# · Feature · Phase · Status

) + feature sections grouped by phase (see

scope-template.md

). Each section: heading

### N. Name

with short tags only when they matter (

needs a decision

, an approach override,

full

weight), a 1 to 2 line intent, one

Done when:

line (acceptance criteria seeds, the WHAT), checkbox steps.

Feature shape lifecycle: not yet designed → one box, its entry command. On spec capture,

/architect

fills the built ready shape:

Design it (spec)

ticked, spec linked,

Build it: /develop <feature>

with 2 to 5 milestone sub items rolled up from the spec's

## Build plan

, then

Verify it: /check verify <feature>

and

Test it: /test <feature>

. Atomic build tasks stay in the spec's

## Build plan

, never here; every box is a command or tracked milestone. Status: in the table and beside the heading; spec and code pointers once they exist.

/scope

seeds the what;

/architect

designs the how and defines milestones;

/develop

builds;

/check verify

and

/test

close;

/sync

reconciles conventions after.

One command, inferred intent (

/scope [what]

, never a subcommand):

plan (default): no scope yet + a product sized idea, or asking for the next slice. Full pass: ask → decompose into coarse feature sections → order + phase → write.
replan: scope exists + no argument. Opens with a short where things stand readout (git branch and ahead/behind the remote, feature counts by status, and each in-progress feature's resume point) so a bare
```
/scope
```
doubles as the "where was I, what is safe to pick up" orientation, then reconciles what shipped, surfaces plan vs reality drift (code or specs with no scope row), enrolls needs surfaced during the build, reorders, and queues the next slice. The normal living rhythm, not rare: run bare
```
/scope
```
again.
add: scope exists + argument names a single feature. Enroll one coarse row (intent + order + weight + Needs spec) without planning again:
```
/scope <a feature>
```
.

将构想转化为有序、粗略且动态更新的计划，并在产品交付过程中保持计划的真实性。回答“我要构建什么，按什么顺序构建，工作量如何，哪些需要先做决策？”这类问题，而非“我如何构建这一件事？”（后者属于

/architect

和

/develop

的职责）。

范围文档的结构：简洁的“概览”表格（

# · Feature · Phase · Status

） + 按阶段分组的功能章节（参考

scope-template.md

）。每个章节包含：标题

### N. Name

（仅在必要时添加简短标签，如

needs a decision

、方法覆盖、

full

工作量）、1-2行的目标说明、一行“完成标准：”（验收标准雏形，即要做的内容WHAT）、复选框步骤。

功能的生命周期：未设计 → 单个复选框及其启动命令。捕获规格时，

/architect

会填充就绪结构：勾选“设计（规格）”，链接规格文档，添加“构建：/develop <feature>”（包含从规格文档的

## Build plan

汇总而来的2-5个里程碑子项），然后是“验证：/check verify <feature>”和“测试：/test <feature>”。原子构建任务仅保留在规格文档的

## Build plan

中，绝不会出现在范围文档中；每个复选框都是一个命令或可追踪的里程碑。状态：显示在表格和标题旁；一旦存在规格和代码，需添加对应的链接。

/scope

确定要构建的内容；

/architect

设计实现方式并定义里程碑；

/develop

负责构建；

/check verify

和

/test

完成收尾；

/sync

在之后协调规范。

单命令，自动推断意图（

/scope [what]

，无子命令）：

规划（默认）：尚无范围文档 + 产品级构想，或请求规划下一阶段内容。完整流程：询问 → 将构想分解为粗略的功能章节 → 排序 + 划分阶段 → 写入文档。
重新规划：已有范围文档 + 无参数。首先显示当前状态摘要（git分支、与远程仓库的超前/滞后情况、各状态的功能数量、每个进行中功能的恢复点），因此直接运行
```
/scope
```
可同时用作“我之前做到哪了，接下来可以安全开展什么工作”的定位工具，然后协调已交付的内容，找出计划与实际情况的偏差（无范围行对应的代码或规格），添加构建过程中发现的需求，重新排序，并规划下一阶段内容。这是日常动态维护的常规流程，而非罕见操作：只需再次直接运行
```
/scope
```
即可。
添加：已有范围文档 + 参数指定单个功能。添加一行粗略的功能条目（目标说明 + 排序 + 工作量 + 需要规格），无需重新规划：
```
/scope <a feature>
```
。

Asks vs acts

询问与执行

Senior product engineer, thorough across all dimensions. Same infer / ask / recommend discipline as

/architect

: INFER what the idea states (category, obvious capabilities); ASK what cannot be inferred across business, product, go to market in batched rounds (up to 4 questions per round; see Decision panels); RECOMMEND build approach, build order, each feature's weight, which need a spec (expert calls: present them, let the engineer override).

Never pick tools: no provider, library, ORM, host, or BaaS chosen or named; that is

/architect

's job per feature in the spec. A feature implying a tool choice is exactly

Needs spec: yes

. Keep the scope tool agnostic so it doesn't rot.

作为资深产品工程师，需全面覆盖所有维度。遵循与

/architect

相同的“推断/询问/建议”准则：推断构想所表达的内容（类别、明确的功能）；分批次询问无法推断的业务、产品、上市相关问题（每轮最多4个问题；参考决策面板）；建议构建方式、构建顺序、每个功能的工作量、哪些需要编写规格文档（给出专业判断：提出建议，允许工程师 override）。

切勿选择工具：不指定或命名任何供应商、库、ORM、主机或BaaS；这是

/architect

在功能规格文档中的职责。若某个功能暗示需要选择工具，则标记为“需要规格：是”。保持范围文档与工具无关，避免文档失效。

Decision panels (every user facing choice)

决策面板（所有面向用户的选择）

Every choice is an options panel, never a neutral menu: 2 to 4 concrete options real to this product; exactly one marked

(recommended)

with a one line why (make the call, let them override). Never add your own Other option, the picker appends a free text Other automatically; offer free text yourself only in a plain text fallback with no picker. Capability first: use the agent's picker (

AskUserQuestion

on Claude Code), else the same options as plain text; batched rounds same rule, up to 4 per round.

每个选择都以选项面板呈现，而非中性菜单：针对当前产品提供2-4个具体可行的选项；其中恰好有一个标记为

(recommended)

，并附带一行理由（做出判断，允许用户 override）。切勿自行添加“其他”选项，选择器会自动附加自由文本“其他”；仅在无选择器的纯文本回退场景中提供自由文本选项。优先使用能力选择：使用Agent的选择器（Claude Code上的

AskUserQuestion

），否则以纯文本形式提供相同选项；分批次询问时遵循相同规则，每轮最多4个问题。

Artifact ownership

工件所有权

docs/scope/

is the feature scope, owned by this skill;

/architect

owns

docs/specs/

. Other skills find a feature by scanning

docs/scope/

for its row. Living document:

plan

replan

add

all edit in place (reconcile and append, never a new dated file). Writes nothing else: no specs, code, or

AGENTS.md

docs/scope/

holds scope files only; inventories, analyses, research docs live with the spec in its

rationale.md

(owned by

/architect

File shape:

Small product: one file,
```
docs/scope/scope.md
```
(At a glance table + phase grouped sections + legend).
Large product: epic split:
```
docs/scope/index.md
```
(At a glance table across epics + one line status rollup per epic, each linking its epic file) + one file per epic named by area (
```
docs/scope/auth.md
```
, …).
Promote on demand: start single file; when
```
scope.md
```
outgrows a comfortable scan (roughly a dozen plus features across clearly distinct areas), rename to
```
index.md
```
(keep table + per epic rollup), move each area's sections into its own
```
<epic>.md
```
. Never split it early. Names semantic (
```
scope.md
```
/
```
index.md
```
/
```
<epic>.md
```
), never numbered.
Keep every file coarse and small; a long epic file needs finer features and tighter intent, not a build task dump.

Status lifecycle (

/scope

sets initial status; the pipeline advances it):

New features start
```
planned
```
. Brownfield: also enroll features that are already there as
```
existing
```
(complete) or
```
in-progress
```
(partial), the only other statuses
```
/scope
```
writes.
```
/develop
```
advances pipeline built work (
```
planned
```
→
```
in-progress
```
→
```
done
```
);
```
/sync
```
reconciles against the diff.
```
done
```
≠
```
existing
```
:
```
done
```
= this pipeline built and verified it;
```
existing
```
predates the workflow;
```
/develop
```
and
```
/sync
```
never touch
```
existing
```
rows.
```
replan
```
may set a feature dropped from scope to
```
dropped
```
, never deletes rows;
```
dropped
```
keeps history, excluded from active counts and work;
```
/develop
```
and
```
/sync
```
skip it.

Process weight: every feature carries Weight

lean

medium

full

, one column turning downstream process on or off.

lean

: trivial, low risk, well understood; skip the fresh model review; often

Needs spec: no

medium

: moderate scope or a real decision; normal path.

full

: high risk, large scope, or compliance sensitive; a fresh model

/check review

warranted; almost always

Needs spec: yes

/scope

sets the initial weight from the risk and size of the feature, the same signals

/architect

and

/develop

read; downstream skills read this column. Weight is a per feature judgment, not a fixed tier: there is no global playbook a feature is slotted into.

Artifact base:

docs/

by default; if

docs/

is a published docs site (

docusaurus.config.*

.vitepress/

mkdocs.yml

, Astro Starlight, or Nextra detected), use

.workflow/

(

.workflow/scope/…

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

docs/

Concurrency: shared across sessions and teammates. Read again immediately before writing; surgical edits only (append rows in order, reconcile changed cells, never rewrite the file); flag rather than clobber unexpected state; append with the next free numbers so adders don't collide.

docs/scope/

是功能范围文档，归本技能所有；

/architect

拥有

docs/specs/

。其他技能通过扫描

docs/scope/

中的条目查找对应功能。动态文档：

plan

、

replan

、

add

操作均在原文档上编辑（协调并追加内容，绝不创建带日期的新文件）。不写入其他内容：不生成规格文档、代码或

AGENTS.md

。

docs/scope/

仅存放范围文档；清单、分析、研究文档需与规格文档一同存放在

rationale.md

中（归

/architect

所有）。

文件结构：

小型产品：单个文件
```
docs/scope/scope.md
```
（概览表格 + 按阶段分组的章节 + 图例）。
大型产品：按史诗拆分：
```
docs/scope/index.md
```
（跨史诗的概览表格 + 每个史诗的一行状态汇总，均链接至对应史诗文件） + 每个领域对应一个史诗文件（如
```
docs/scope/auth.md
```
等）。
按需升级：初始使用单个文件；当
```
scope.md
```
内容过多，难以快速浏览时（大致超过12个功能且分布在明显不同的领域），将其重命名为
```
index.md
```
（保留表格 + 史诗状态汇总），将各领域的章节移至对应的
```
<epic>.md
```
文件中。切勿过早拆分。文件命名需语义化（
```
scope.md
```
/
```
index.md
```
/
```
<epic>.md
```
），绝不使用编号。
保持每个文件简洁粗略；过长的史诗文件需要更细化的功能和更明确的目标，而非堆砌构建任务。

状态生命周期（

/scope

设置初始状态；流水线推进状态更新）：

新功能初始状态为
```
planned
```
。遗留系统：需将已有的功能标记为
```
existing
```
（已完成）或
```
in-progress
```
（进行中），这是
```
/scope
```
会写入的仅有的其他状态。
```
/develop
```
推进已构建工作的状态（
```
planned
```
→
```
in-progress
```
→
```
done
```
）；
```
/sync
```
根据差异协调状态。
```
done
```
≠
```
existing
```
：
```
done
```
表示本流水线已构建并验证该功能；
```
existing
```
表示该功能早于当前工作流；
```
/develop
```
和
```
/sync
```
绝不会修改
```
existing
```
条目。
```
replan
```
可将从范围中移除的功能标记为
```
dropped
```
，绝不删除条目；
```
dropped
```
保留历史记录，不计入活跃功能数量和工作任务；
```
/develop
```
和
```
/sync
```
会跳过此类条目。

流程权重：每个功能都带有

lean

medium

full

三种权重之一，该列用于开启或关闭下游流程。

lean

：工作量小、风险低、需求明确；跳过新模型评审；通常标记为“需要规格：否”。

medium

：范围适中或需要实际决策；遵循常规流程。

full

：高风险、大范围或合规敏感；需进行新模型

/check review

；几乎总是标记为“需要规格：是”。

/scope

根据功能的风险和规模设置初始权重，

/architect

和

/develop

会读取相同的信号；下游技能会读取该列内容。权重是针对每个功能的判断，而非固定层级：不存在将功能强行归类的全局手册。

工件基础目录：默认使用

docs/

；若检测到

docs/

是已发布的文档站点（存在

docusaurus.config.*

、

.vitepress/

、

mkdocs.yml

、Astro Starlight 或 Nextra），则使用

.workflow/

（

.workflow/scope/…

）。始终遵循已存在的基础目录（本文档中的路径默认假设使用

docs/

）。

并发处理：支持跨会话和跨团队成员共享。写入前需立即重新读取文档；仅进行精准编辑（按顺序追加条目，协调变更的单元格，绝不重写整个文件）；若遇到意外状态，需标记而非覆盖；追加时使用下一个可用编号，避免多人添加时冲突。

Reference files

参考文件

```
scope-template.md
```
: format rules, At a glance table, per feature sections (heading + intent + Done when + checkbox tasks + pointer line), brownfield enrollment and epic split shapes, the
```
## /scope complete
```
report block. Read it when writing the scope and the report.

```
scope-template.md
```
：格式规则、概览表格、功能章节模板（标题 + 目标说明 + 完成标准 + 复选框步骤 + 链接行）、遗留系统条目和史诗拆分结构、
```
## /scope complete
```
报告块。撰写范围文档和报告时需参考此文件。

Portability (any OS, any agent)

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

Any Agent Skills client on macOS, Linux, Windows. Detection snippets are POSIX reference; use your agent's cross platform file tools. Planning runs inline; the two subagents below (Step 1 brownfield code scan, Step 6b sourcing) are optional and capability first, degrade to inline. No interactive picker: ask every panel as plain text, same options.

支持在macOS、Linux、Windows上运行任意Agent Skills客户端。检测代码片段以POSIX为参考；使用Agent的跨平台文件工具。规划流程在线运行；以下两个子Agent（步骤1：遗留系统代码扫描，步骤6b：资源获取）为可选组件，优先保障核心能力，降级时可在线运行。若无交互式选择器：以纯文本形式询问所有面板问题，提供相同选项。

Execution

执行流程

Step 0: Infer intent & idea check

步骤0：推断意图 & 构想检查

No subcommand. First check whether a scope exists under

docs/scope/

(or

.workflow/scope/

if that is the artifact base), then infer:

Scope exists + no argument (or running again, described as "reconcile / what's next") → replan behavior (
```
modes/replan.md
```
).
Scope exists + argument names a single feature → add behavior (
```
modes/add.md
```
).
No scope yet + a product sized idea, or scoping the next slice (including brownfield) → plan behavior, below.

Ambiguous (a new slice vs a single feature): infer the most likely reading from scope, say which behavior you chose in the report; truly unclear → one line clarifying question.

Plan behavior, no idea given (no argument, no scope to extend): stop and ask before anything else:

"What are you building? Describe the product or the slice of it you want to plan (one or two sentences about what it does and who it's for)."

Wait for the answer; use it as the product idea.

无需子命令。首先检查

docs/scope/

（或工件基础目录为

.workflow/scope/

时）是否存在范围文档，然后推断：

存在范围文档 + 无参数（或描述为“协调/下一步工作”时再次运行）→ 执行重新规划行为（参考
```
modes/replan.md
```
）。
存在范围文档 + 参数指定单个功能 → 执行添加行为（参考
```
modes/add.md
```
）。
无范围文档 + 产品级构想，或规划下一阶段内容（包括遗留系统）→ 执行规划行为，如下所述。

若意图模糊（是规划新阶段还是添加单个功能）：根据现有范围文档推断最可能的意图，并在报告中说明选择的行为；若确实无法明确 → 提出一行澄清问题。

执行规划行为但未提供构想（无参数，无范围文档可扩展）：在执行任何操作前暂停并询问：

“你要构建什么？描述你要规划的产品或其阶段（用1-2句话说明功能和目标用户）。”

等待回复；将回复作为产品构想。

Step 1: Load the inferred behavior

步骤1：加载推断的行为

After Step 0 infers the behavior, read exactly one mode file and follow it:

```
modes/plan.md
```
for plan behavior (new scope, product sized idea, or next slice planning).
```
modes/replan.md
```
for replan behavior (scope exists and no argument).
```
modes/add.md
```
for add behavior (scope exists and the argument names one feature).

Do not read the other mode files unless the inferred behavior changes. All common rules above still apply, and

scope-template.md

remains the format reference for any write/report.

步骤0推断行为后，仅读取一个模式文件并遵循其规则：

执行规划行为时读取
```
modes/plan.md
```
（新范围文档、产品级构想或下一阶段规划）。
执行重新规划行为时读取
```
modes/replan.md
```
（存在范围文档且无参数）。
执行添加行为时读取
```
modes/add.md
```
（存在范围文档且参数指定单个功能）。

除非推断的行为发生变化，否则请勿读取其他模式文件。上述所有通用规则仍然适用，

scope-template.md

始终是撰写/报告时的格式参考。

Reference

参考

```
scope-template.md
```
: see Reference files above.

```
scope-template.md
```
：参见上方参考文件部分。