create-spec

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Write BDD-style test scenarios in Gherkin before implementation.

在功能实现前编写Gherkin格式的BDD风格测试场景。

Steps

步骤

Determine the feature — the argument can be:
- A GitHub issue number or URL → fetch with
```
gh issue view
```
  for context (do NOT embed the issue number in the spec)
- A feature description → use as the feature name
- Nothing → ask the user what feature to specify
Explore the codebase for related context:
- Read
```
CLAUDE.md
```
  for project conventions
- Check existing code and tests related to the feature
- Check
```
doc/adr/
```
  and
```
doc/
```
  for relevant decisions and documentation
Check
```
doc/spec/
```
for an existing spec that covers this feature:
- If found → add new scenarios to the existing file
- If not found → create a new file:
```
doc/spec/<kebab-case-feature-name>.feature
```
Write scenarios using this template:

gherkin

Feature: <Feature Title>
  <Brief description of the feature>

  Scenario: <scenario name>
    Given <precondition>
    When <action>
    Then <expected result>

Tell the user what was created or updated and its path

确定功能——传入的参数可以是：
- GitHub议题编号或URL → 使用
```
gh issue view
```
  获取上下文信息（请勿在规范中嵌入议题编号）
- 功能描述 → 用作功能名称
- 无参数 → 询问用户要指定的功能
探索代码库以获取相关上下文：
- 阅读
```
CLAUDE.md
```
  了解项目约定
- 查看与该功能相关的现有代码和测试
- 查看
```
doc/adr/
```
  和
```
doc/
```
  目录下的相关决策文档和说明文档
检查
```
doc/spec/
```
目录下是否已有覆盖该功能的规范文件：
- 若存在 → 向现有文件中添加新的测试场景
- 若不存在 → 创建新文件：
```
doc/spec/<kebab-case-feature-name>.feature
```
使用以下模板编写测试场景：

gherkin

Feature: <Feature Title>
  <Brief description of the feature>

  Scenario: <scenario name>
    Given <precondition>
    When <action>
    Then <expected result>

告知用户已创建或更新的内容及其路径

Guidelines

指南

Based on el-feo/ai-context/cucumber-gherkin conventions.

Declarative over imperative — focus on what not how (say "the user is logged in", not "the user enters credentials and clicks login")
Keep scenarios concise — 3-5 steps
Use domain language stakeholders understand
One behavior per scenario
Use
```
Background
```
for shared preconditions (4 lines max)
Use
```
Rule
```
to group related scenarios under a business rule
Use
```
Scenario Outline
```
with
```
Examples
```
for data-driven scenarios
Move implementation complexity into step definitions, not scenario text
Do NOT reference issue numbers in the spec — specs are standing documentation

基于el-feo/ai-context/cucumber-gherkin约定。

优先使用声明式而非命令式——关注结果而非实现过程（例如说"用户已登录"，而非"用户输入凭证并点击登录"）
测试场景保持简洁——3-5个步骤
使用利益相关者能理解的领域语言
每个场景对应一种行为
使用
```
Background
```
定义共享前置条件（最多4行）
使用
```
Rule
```
将相关场景按业务规则分组
使用
```
Scenario Outline
```
结合
```
Examples
```
实现数据驱动场景
将实现复杂度转移到步骤定义中，而非场景文本
请勿在规范中引用议题编号——规范是独立的文档

Rules

规则

Specs live in
```
doc/spec/
```
as
```
.feature
```
files
Filenames are kebab-case:
```
doc/spec/user-export.feature
```
Prefer extending an existing spec over creating a new one when the feature overlaps

规范文件以
```
.feature
```
格式存放在
```
doc/spec/
```
目录下
文件名采用kebab-case格式：
```
doc/spec/user-export.feature
```
当功能存在重叠时，优先扩展现有规范文件而非创建新文件