Create Specification

创建规范文档

Your goal is to create a new specification file for

${input:SpecPurpose}

.

The specification file must define the requirements, constraints, and interfaces for the solution components in a manner that is clear, unambiguous, and structured for effective use by Generative AIs. Follow established documentation standards and ensure the content is machine-readable and self-contained.

你的目标是为

${input:SpecPurpose}

创建一个新的规范文件。

该规范文件必须以清晰、无歧义且结构化的方式定义解决方案组件的需求、约束和接口，以便生成式AI能够有效使用它。遵循既定的文档标准，确保内容可被机器读取且自包含。

Best Practices for AI-Ready Specifications

AI可读规范的最佳实践

Use precise, explicit, and unambiguous language.
Clearly distinguish between requirements, constraints, and recommendations.
Use structured formatting (headings, lists, tables) for easy parsing.
Avoid idioms, metaphors, or context-dependent references.
Define all acronyms and domain-specific terms.
Include examples and edge cases where applicable.
Ensure the document is self-contained and does not rely on external context.

The specification should be saved in the /spec/ directory and named according to the following convention:

spec-[a-z0-9-]+.md

, where the name should be descriptive of the specification's content and starting with the highlevel purpose, which is one of [schema, tool, data, infrastructure, process, architecture, or design].

The specification file must be formatted in well formed Markdown.

Specification files must follow the template below, ensuring that all sections are filled out appropriately. The front matter for the markdown should be structured correctly as per the example following:

md

---
title: [Concise Title Describing the Specification's Focus]
version: [Optional: e.g., 1.0, Date]
date_created: [YYYY-MM-DD]
last_updated: [Optional: YYYY-MM-DD]
owner: [Optional: Team/Individual responsible for this spec]
tags: [Optional: List of relevant tags or categories, e.g., `infrastructure`, `process`, `design`, `app` etc]
---

使用精确、明确且无歧义的语言。
清晰区分需求、约束和建议。
使用结构化格式（标题、列表、表格）以便于解析。
避免习语、隐喻或依赖上下文的引用。
定义所有缩写和领域特定术语。
适当时包含示例和边缘情况。
确保文档自包含，不依赖外部上下文。

规范文件应保存至/spec/目录，并遵循以下命名约定：

spec-[a-z0-9-]+.md

，文件名应能描述规范内容，且以高级用途开头，可选的高级用途包括[schema, tool, data, infrastructure, process, architecture, or design]。

规范文件必须采用格式规范的Markdown编写。

规范文件必须遵循以下模板，确保所有部分都已适当填写。Markdown的前置元数据应按照以下示例正确结构化：

md

---
title: [Concise Title Describing the Specification's Focus]
version: [Optional: e.g., 1.0, Date]
date_created: [YYYY-MM-DD]
last_updated: [Optional: YYYY-MM-DD]
owner: [Optional: Team/Individual responsible for this spec]
tags: [Optional: List of relevant tags or categories, e.g., `infrastructure`, `process`, `design`, `app` etc]
---

Introduction

[A short concise introduction to the specification and the goal it is intended to achieve.]

1. Purpose & Scope

[Provide a clear, concise description of the specification's purpose and the scope of its application. State the intended audience and any assumptions.]

2. Definitions

[List and define all acronyms, abbreviations, and domain-specific terms used in this specification.]

3. Requirements, Constraints & Guidelines

[Explicitly list all requirements, constraints, rules, and guidelines. Use bullet points or tables for clarity.]

REQ-001: Requirement 1
SEC-001: Security Requirement 1
[3 LETTERS]-001: Other Requirement 1
CON-001: Constraint 1
GUD-001: Guideline 1
PAT-001: Pattern to follow 1

[Explicitly list all requirements, constraints, rules, and guidelines. Use bullet points or tables for clarity.]

REQ-001: Requirement 1
SEC-001: Security Requirement 1
[3 LETTERS]-001: Other Requirement 1
CON-001: Constraint 1
GUD-001: Guideline 1
PAT-001: Pattern to follow 1

4. Interfaces & Data Contracts

[Describe the interfaces, APIs, data contracts, or integration points. Use tables or code blocks for schemas and examples.]

5. Acceptance Criteria

[Define clear, testable acceptance criteria for each requirement using Given-When-Then format where appropriate.]

AC-001: Given [context], When [action], Then [expected outcome]
AC-002: The system shall [specific behavior] when [condition]
AC-003: [Additional acceptance criteria as needed]

[Define clear, testable acceptance criteria for each requirement using Given-When-Then format where appropriate.]

AC-001: Given [context], When [action], Then [expected outcome]
AC-002: The system shall [specific behavior] when [condition]
AC-003: [Additional acceptance criteria as needed]

6. Test Automation Strategy

[Define the testing approach, frameworks, and automation requirements.]

Test Levels: Unit, Integration, End-to-End
Frameworks: MSTest, FluentAssertions, Moq (for .NET applications)
Test Data Management: [approach for test data creation and cleanup]
CI/CD Integration: [automated testing in GitHub Actions pipelines]
Coverage Requirements: [minimum code coverage thresholds]
Performance Testing: [approach for load and performance testing]

[Define the testing approach, frameworks, and automation requirements.]

Test Levels: Unit, Integration, End-to-End
Frameworks: MSTest, FluentAssertions, Moq (for .NET applications)
Test Data Management: [approach for test data creation and cleanup]
CI/CD Integration: [automated testing in GitHub Actions pipelines]
Coverage Requirements: [minimum code coverage thresholds]
Performance Testing: [approach for load and performance testing]

7. Rationale & Context

[Explain the reasoning behind the requirements, constraints, and guidelines. Provide context for design decisions.]

8. Dependencies & External Integrations

[Define the external systems, services, and architectural dependencies required for this specification. Focus on what is needed rather than how it's implemented. Avoid specific package or library versions unless they represent architectural constraints.]

External Systems

EXT-001: [External system name] - [Purpose and integration type]

EXT-001: [External system name] - [Purpose and integration type]

Third-Party Services

SVC-001: [Service name] - [Required capabilities and SLA requirements]

SVC-001: [Service name] - [Required capabilities and SLA requirements]

Infrastructure Dependencies

INF-001: [Infrastructure component] - [Requirements and constraints]

INF-001: [Infrastructure component] - [Requirements and constraints]

Data Dependencies

DAT-001: [External data source] - [Format, frequency, and access requirements]

DAT-001: [External data source] - [Format, frequency, and access requirements]

Technology Platform Dependencies

PLT-001: [Platform/runtime requirement] - [Version constraints and rationale]

PLT-001: [Platform/runtime requirement] - [Version constraints and rationale]

Compliance Dependencies

COM-001: [Regulatory or compliance requirement] - [Impact on implementation]

Note: This section should focus on architectural and business dependencies, not specific package implementations. For example, specify "OAuth 2.0 authentication library" rather than "Microsoft.AspNetCore.Authentication.JwtBearer v6.0.1".

COM-001: [Regulatory or compliance requirement] - [Impact on implementation]

Note: This section should focus on architectural and business dependencies, not specific package implementations. For example, specify "OAuth 2.0 authentication library" rather than "Microsoft.AspNetCore.Authentication.JwtBearer v6.0.1".

9. Examples & Edge Cases

code

    // Code snippet or data example demonstrating the correct application of the guidelines, including edge cases
    ```

code

    // Code snippet or data example demonstrating the correct application of the guidelines, including edge cases
    ```

10. Validation Criteria

[List the criteria or tests that must be satisfied for compliance with this specification.]

11. Related Specifications / Further Reading

[Link to related spec 1] [Link to relevant external documentation]

undefined

[Link to related spec 1] [Link to relevant external documentation]

undefined

create-specification

Original

Translation

Create Specification

创建规范文档

Best Practices for AI-Ready Specifications

AI可读规范的最佳实践

Introduction

Introduction

1. Purpose & Scope

1. Purpose & Scope

2. Definitions

2. Definitions

3. Requirements, Constraints & Guidelines

3. Requirements, Constraints & Guidelines

4. Interfaces & Data Contracts

4. Interfaces & Data Contracts

5. Acceptance Criteria

5. Acceptance Criteria

6. Test Automation Strategy

6. Test Automation Strategy

7. Rationale & Context

7. Rationale & Context

8. Dependencies & External Integrations

8. Dependencies & External Integrations

External Systems

External Systems

Third-Party Services

Third-Party Services

Infrastructure Dependencies

Infrastructure Dependencies

Data Dependencies

Data Dependencies

Technology Platform Dependencies

Technology Platform Dependencies

Compliance Dependencies

Compliance Dependencies

9. Examples & Edge Cases

9. Examples & Edge Cases

10. Validation Criteria

10. Validation Criteria

11. Related Specifications / Further Reading

11. Related Specifications / Further Reading