🚀 快速安装

复制以下命令并运行,立即安装此 Skill:

npx @anthropic-ai/skills install github/awesome-copilot/create-specification

💡 提示:需要 Node.js 和 NPM

创建规范

您的目标是创建一个关于 ${input:SpecPurpose} 的新规范文件。

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

面向 AI 的规范最佳实践

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

规范应保存在 /spec/ 目录中,并根据以下约定命名:spec-[a-z0-9-]+.md,其中名称应描述规范的内容,并以高层次目的开头,目的可以是 [schema, tool, data, infrastructure, process, architecture, or design] 之一。

规范文件必须采用格式良好的 Markdown 格式。

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

---
title: [简洁标题,描述规范的焦点]
version: [可选:例如, 1.0, 日期]
date_created: [YYYY-MM-DD]
last_updated: [可选:YYYY-MM-DD]
owner: [可选:负责此规范的团队/个人]
tags: [可选:相关标签或类别列表,例如 `infrastructure`、`process`、`design`、`app` 等]
---

# 引言

[对规范及其旨在实现的目标的简短介绍。]

## 1. 目的与范围

[清晰、简洁地描述规范的目的及其应用范围。说明目标受众和任何假设。]

## 2. 定义

[列出并定义本规范中使用的所有首字母缩写、缩写和特定领域术语。]

## 3. 需求、约束与指南

[明确列出所有需求、约束、规则和指南。使用项目符号或表格以提高清晰度。]

- **REQ-001**: 需求 1
- **SEC-001**: 安全需求 1
- **[3 LETTERS]-001**: 其他需求 1
- **CON-001**: 约束 1
- **GUD-001**: 指南 1
- **PAT-001**: 要遵循的模式 1

## 4. 接口与数据契约

[描述接口、API、数据契约或集成点。对于模式和示例,使用表格或代码块。]

## 5. 验收标准

[为每个需求定义清晰、可测试的验收标准,适当时使用 Given-When-Then 格式。]

- **AC-001**: 给定 [上下文],当 [操作],则 [预期结果]
- **AC-002**: 系统在 [条件] 下应 [特定行为]
- **AC-003**: [根据需要添加其他验收标准]

## 6. 测试自动化策略

[定义测试方法、框架和自动化要求。]

- **测试级别**: 单元、集成、端到端
- **框架**: MSTest、FluentAssertions、Moq(对于 .NET 应用程序)
- **测试数据管理**: [测试数据创建和清理的方法]
- **CI/CD 集成**: [GitHub Actions 流水线中的自动化测试]
- **覆盖率要求**: [最低代码覆盖率阈值]
- **性能测试**: [负载和性能测试的方法]

## 7. 原理与上下文

[解释需求、约束和指南背后的理由。提供设计决策的上下文。]

## 8. 依赖项与外部集成

[定义此规范所需的外部系统、服务和架构依赖项。重点关注需要什么,而不是如何实现。除非特定包或库版本代表架构约束,否则避免指定具体版本。]

### 外部系统
- **EXT-001**: [外部系统名称] - [用途和集成类型]

### 第三方服务
- **SVC-001**: [服务名称] - [所需能力和服务水平协议要求]

### 基础设施依赖项
- **INF-001**: [基础设施组件] - [要求和约束]

### 数据依赖项
- **DAT-001**: [外部数据源] - [格式、频率和访问要求]

### 技术平台依赖项
- **PLT-001**: [平台/运行时要求] - [版本约束和理由]

### 合规性依赖项
- **COM-001**: [法规或合规性要求] - [对实现的影响]

**注意**: 本节应侧重于架构和业务依赖项,而不是特定的包实现。例如,应指定“OAuth 2.0 身份验证库”,而不是“Microsoft.AspNetCore.Authentication.JwtBearer v6.0.1”。

## 9. 示例与边缘情况

    ```code
    // 代码片段或数据示例,演示指南的正确应用,包括边缘情况
    ```

## 10. 验证标准

[列出必须满足的标准或测试,以符合此规范。]

## 11. 相关规范 / 延伸阅读

[链接到相关规范 1]
[链接到相关外部文档]

📄 原始文档

完整文档(英文):

https://skills.sh/github/awesome-copilot/create-specification

💡 提示:点击上方链接查看 skills.sh 原始英文文档,方便对照翻译。

声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。