cmd-speckit-specify

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/speckit.specify

Agent skill wrapper for the Claude command

/speckit.specify

When the original command text references

{{INPUT}}

$1

, or named arguments, map them from the user's current request.

Claude命令

/speckit.specify

的Agent技能封装。

当原始命令文本引用

{{INPUT}}

、

$1

或命名参数时，从用户当前请求中映射对应内容。

Command Instructions

命令说明

Create a structured feature specification from the description. Focus strictly on WHAT and WHY — never HOW.

根据描述创建结构化的功能规格文档。严格聚焦于是什么（WHAT）和为什么（WHY）——绝不涉及如何实现（HOW）。

Steps

步骤

Validate input: If no description was provided, ask: "What feature would you like to specify?" and wait for the response.
Determine feature location:
- If
```
.specify/specs/
```
  exists: derive a 2-4 word kebab-case name from the description (action-noun format, e.g.
```
oauth-api-integration
```
  ). Write to
```
.specify/specs/<feature-name>/spec.md
```
  .
- If
```
.specify/
```
  does not exist: write to
```
spec.md
```
  in the project root and remind the user that
```
/speckit.init
```
  has not been run.
Load context: If
```
.specify/memory/constitution.md
```
exists, read it for governing principles and project constraints.

Write the spec to the determined path. Omit any section that does not apply:

markdown

# Feature Specification: <Feature Name>

**Status**: Draft
**Created**: <YYYY-MM-DD>

## Overview
One paragraph: what this feature is and why it exists. Written for business stakeholders.

## User Scenarios
1. As a [role], I want to [action] so that [outcome].

## Functional Requirements
Numbered list. Each requirement must be testable, technology-agnostic, and behavior-focused.

## Success Criteria
Measurable outcomes with specific metrics or verifiable conditions.

## Key Entities
(Include only if the feature involves persistent data)
Name and description of core domain objects.

## Out of Scope
Explicit list of what this feature does NOT include.

## Open Questions
<!-- [NEEDS CLARIFICATION] items — max 3 -->

Self-validate: Check — no implementation details, measurable success criteria, at most 3
```
[NEEDS CLARIFICATION]
```
markers, scope is bounded.
Resolve open questions interactively: Present each
```
[NEEDS CLARIFICATION]
```
item as a multiple-choice question (2-5 options, recommended answer marked). Update the spec based on user selections.
Report: State the file path and confirm readiness for the next step.

Next step: Run

/speckit.clarify

if ambiguities remain, or

/speckit.plan

when the spec is complete.

验证输入：如果未提供功能描述，请询问：“你想要指定什么功能？”并等待用户回复。
确定功能存放位置：
- 若
```
.specify/specs/
```
  目录存在：从描述中提取一个2-4词的短横线分隔命名（动名词格式，例如
```
oauth-api-integration
```
  ）。将文档写入
```
.specify/specs/<feature-name>/spec.md
```
  。
- 若
```
.specify/
```
  目录不存在：将文档写入项目根目录下的
```
spec.md
```
  ，并提醒用户尚未运行
```
/speckit.init
```
  命令。
加载上下文：若
```
.specify/memory/constitution.md
```
文件存在，读取其中的指导原则和项目约束条件。

编写规格文档到指定路径。省略不适用的章节：

markdown

# Feature Specification: <Feature Name>

**Status**: Draft
**Created**: <YYYY-MM-DD>

## Overview
One paragraph: what this feature is and why it exists. Written for business stakeholders.

## User Scenarios
1. As a [role], I want to [action] so that [outcome].

## Functional Requirements
Numbered list. Each requirement must be testable, technology-agnostic, and behavior-focused.

## Success Criteria
Measurable outcomes with specific metrics or verifiable conditions.

## Key Entities
(Include only if the feature involves persistent data)
Name and description of core domain objects.

## Out of Scope
Explicit list of what this feature does NOT include.

## Open Questions
<!-- [NEEDS CLARIFICATION] items — max 3 -->

自我验证：检查是否存在以下问题——无实现细节、成功标准可衡量、最多3个
```
[NEEDS CLARIFICATION]
```
标记、范围明确。
交互式解决未决问题：将每个
```
[NEEDS CLARIFICATION]
```
项以选择题形式呈现（2-5个选项，标注推荐答案）。根据用户选择更新规格文档。
反馈结果：告知用户文件路径，并确认已准备好进入下一步。

下一步：若仍存在歧义，运行

/speckit.clarify

；若规格文档已完成，运行

/speckit.plan

。