关于 create-specification
用于根据指定目的创建结构化 Markdown 规范文档的技能。它规定保存位置、文件命名规则、文档编写要求和模板,旨在让生成式 AI 清晰理解规范。
主要功能
- 01在 /spec/ 中创建规范文档
- 02使用 spec-[a-z0-9-]+.md 命名格式
- 03组织需求、约束和接口
- 04遵循面向 AI 的写作检查项
- 05使用提供的 Markdown 模板
适用场景
- 01记录新解决方案的需求
- 02创建供 AI 使用的自包含规范
- 03统一项目中的规范文件格式
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ github/ awesome-copilot --skill create-specification安装后在 Claude Code 中输入/create-specification确认已加载。
详细介绍
创建规范
你的目标是为 ${input:SpecPurpose} 创建一个新的规范文件。
规范文件必须定义解决方案组件的需求、约束和接口,方式应清晰、无歧义,并结构化以便生成式 AI 有效使用。遵循已建立的文档标准,并确保内容可机器读取且自包含。
AI 可用规范的最佳实践
- 使用精确、明确且无歧义的语言。
- 清楚区分需求、约束和建议。
- 使用结构化格式(标题、列表、表格)以便轻松解析。
- 避免习语、隐喻或依赖上下文的引用。
- 定义所有缩写词和领域特定术语。
- 在适用的情况下包含示例和边缘情况。
- 确保文档自包含,不依赖外部上下文。
规范应保存在 /spec/ 目录中,并按照以下约定命名:spec-[a-z0-9-]+.md,其中名称应描述规范内容,并以高层级目的开头,该目的为以下之一:[schema, tool, data, infrastructure, process, architecture, or design]。
规范文件必须格式化为结构良好的 Markdown。
规范文件必须遵循以下模板,确保所有部分都适当填写。Markdown 的 front matter 应按照以下示例正确结构化:
---
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
## 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]
## 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]
## 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]
### Third-Party Services
- **SVC-001**: [Service name] - [Required capabilities and SLA requirements]
### Infrastructure Dependencies
- **INF-001**: [Infrastructure component] - [Requirements and constraints]
### Data Dependencies
- **DAT-001**: [External data source] - [Format, frequency, and access requirements]
### Technology Platform Dependencies
- **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".
## 9. Examples & 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]
评论
支持 Markdown