Back to Details

create-specification

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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}
创建一个新的规范文件。
规范文件必须以清晰、无歧义且结构化的方式定义解决方案组件的需求、约束和接口，以便 Generative 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 或 design。
规范文件必须采用格式正确的 Markdown 格式。
规范文件必须遵循以下模板，并确保所有章节均已适当填写。Markdown 的 front matter 应按照后续示例正确组织：
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

Introduction

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

1. Purpose & Scope

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.]
[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

2. Definitions

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

3. Requirements, Constraints & Guidelines

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

4. Interfaces & Data Contracts

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

5. Acceptance Criteria

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

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

7. Rationale & Context

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

8. Dependencies & External Integrations

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.]
[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

External Systems

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

Third-Party Services

Third-Party Services

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

Infrastructure Dependencies

Infrastructure Dependencies

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

Data Dependencies

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

Technology Platform Dependencies

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

Compliance Dependencies

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

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

10. Validation Criteria

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

11. Related Specifications / Further Reading

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