spec-driven-spec-content

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

You are helping the user place spec content into the correct delta spec file for an existing spec-driven change.

您正在协助用户将规范内容放置到正确的delta spec文件中，以完成现有的spec-driven变更。

Prerequisites

前提条件

The

.spec-driven/

directory must exist at the project root. Before proceeding, verify:

ls .spec-driven/

If this fails, the project is not initialized. Run

/spec-driven-init

first.

.spec-driven/

目录必须存在于项目根目录下。开始操作前，请验证：

ls .spec-driven/

如果验证失败，说明项目未初始化，请先运行

/spec-driven-init

。

Steps

操作步骤

Select the change — run
```
node {{SKILL_DIR}}/scripts/spec-driven.js modify
```
to list active changes. Ask which change to edit if the user did not specify one.
Understand the request — identify whether the user wants to:
- add new spec content
- extend an existing spec
- modify an existing requirement
- remove one or more existing requirements
Read index-first context — before deciding any path, read:
- ```
.spec-driven/config.yaml
```
- ```
.spec-driven/specs/INDEX.md
```
- any existing files under
```
.spec-driven/changes/<name>/specs/
```
  that already look related
Choose candidate targets from
INDEX.md
— use the index to determine which existing categories and spec files might already cover the requested behavior.
- If one or more candidates exist, read the full main spec files before making any routing decision
- Only create a new category if no existing category fits the behavior
- Only create a new spec file inside an existing category if the behavior does not fit any existing file in that category
Decide the delta spec path — classify the request into exactly one of:
- update an existing delta file that mirrors an existing main spec file
- create a new delta file under an existing category
- create a new delta file under a new category
- revise existing requirements in a delta file that already exists
Keep the delta path aligned with the main spec path that should exist after archive.
- If the chosen delta spec file already exists under
```
.spec-driven/changes/<name>/specs/
```
  , read that exact file before appending or revising content
Edit the delta spec content — preserve the standard delta format:
- Use
```
## ADDED Requirements
```
  for new requirements
- Use
```
## MODIFIED Requirements
```
  for changed requirements, including a
```
Previously:
```
  note
- Use
```
## REMOVED Requirements
```
  for deletions, including the reason
- Keep
```
### Requirement:
```
  headings intact
- Describe observable behavior, not implementation details
Handle removals explicitly — if the request removes spec content:
- identify the exact
```
### Requirement:
```
  heading or headings being removed
- write those removals explicitly in the delta file
- do not use vague phrasing like "remove old spec" or "delete obsolete content"
- if the target requirement is ambiguous after reading the relevant specs, stop and ask the user which requirement should be removed
Run the final spec format check — after any spec edit, run:
```
node {{SKILL_DIR}}/scripts/spec-driven.js verify <name>
```
- Treat missing artifacts, malformed delta section markers/headings, and other spec structure problems as the format issues to repair
- Fix any safe format issues immediately and rerun
```
verify
```
- If
```
verify
```
  reports only non-format workflow blockers such as open questions in
```
questions.md
```
  , surface those separately instead of misreporting them as spec-format failures
- Do not finish without this check
- If unresolved format or structure errors remain, report them clearly to the user
Summarize the routing decision — tell the user:
- which category/file was chosen
- whether it was an existing file, new file, or new category
- whether the change added, modified, or removed requirements
- whether the final format check passed

选择变更 — 运行
```
node {{SKILL_DIR}}/scripts/spec-driven.js modify
```
列出当前活跃的变更。如果用户未指定，询问要编辑哪一项变更。
理解需求 — 明确用户的需求类型：
- 添加新的规范内容
- 扩展现有规范
- 修改现有需求
- 移除一个或多个现有需求
读取索引优先上下文 — 在确定任何操作路径前，读取以下内容：
- ```
.spec-driven/config.yaml
```
- ```
.spec-driven/specs/INDEX.md
```
- ```
.spec-driven/changes/<name>/specs/
```
  下所有看起来相关的现有文件
从INDEX.md中选择候选目标 — 借助索引确定哪些现有分类和规范文件可能已经覆盖了所需的行为。
- 如果存在一个或多个候选文件，在做出路由决定前先完整读取主规范文件
- 只有当现有分类完全不匹配该行为时，才创建新分类
- 只有当该行为与分类下的所有现有文件都不匹配时，才在现有分类下创建新规范文件
确定delta spec路径 — 将请求严格归类为以下其中一种：
- 更新与现有主规范文件对应的delta文件
- 在现有分类下创建新的delta文件
- 在新分类下创建新的delta文件
- 修改现有delta文件中的需求
确保delta路径与归档后应存在的主规范路径保持一致。
- 如果所选delta spec文件已存在于
```
.spec-driven/changes/<name>/specs/
```
  下，在追加或修改内容前先读取该文件
编辑delta spec内容 — 保留标准delta格式：
- 使用
```
## ADDED Requirements
```
  标记新增需求
- 使用
```
## MODIFIED Requirements
```
  标记修改后的需求，同时添加
```
Previously:
```
  注释说明修改前内容
- 使用
```
## REMOVED Requirements
```
  标记删除的需求，同时说明删除原因
- 保持
```
### Requirement:
```
  标题不变
- 描述可观察的行为，而非实现细节
明确处理移除操作 — 如果请求是移除规范内容：
- 确定要移除的具体
```
### Requirement:
```
  标题
- 在delta文件中明确记录这些移除内容
- 避免使用“移除旧规范”或“删除过时内容”这类模糊表述
- 如果读取相关规范后仍无法明确目标需求，请停止操作并询问用户具体要移除哪项需求
运行最终规范格式检查 — 完成任何规范编辑后，运行：
```
node {{SKILL_DIR}}/scripts/spec-driven.js verify <name>
```
- 将缺失的工件、格式错误的delta章节标记/标题以及其他规范结构问题视为需要修复的格式问题
- 立即修复所有安全的格式问题并重新运行
```
verify
```
- 如果
```
verify
```
  仅报告非格式类的工作流阻塞问题（如
```
questions.md
```
  中的未解决问题），请单独列出这些问题，不要误报为规范格式错误
- 必须完成此检查才能结束操作
- 如果仍存在未解决的格式或结构错误，请清晰地向用户报告
总结路由决策 — 告知用户：
- 选择的分类/文件
- 该文件是现有文件、新文件还是新分类
- 此次变更属于新增、修改还是移除需求
- 最终格式检查是否通过

Rules

规则

Read
```
.spec-driven/specs/INDEX.md
```
before choosing a category or file name
Prefer existing categories and files unless the content clearly requires a new path
Read the relevant main specs before editing delta specs
If the chosen delta file already exists, read that exact file before editing it
Do not implement code — this skill edits planning artifacts only
Always finish with a spec format check

在选择分类或文件名前，必须先读取
```
.spec-driven/specs/INDEX.md
```
优先使用现有分类和文件，除非内容明确需要新路径
在编辑delta规范前，先读取相关的主规范
如果所选delta文件已存在，在编辑前先读取该文件
不要实现代码 — 此技能仅编辑规划工件
操作结束前必须运行规范格式检查