mcpField
U
update-specification

update-specification

github.com/github开发40.5k9.2k 次安装今天更新
代码仓库

关于 update-specification

这项技能根据新需求或代码变更更新现有规格说明,规定文档结构、命名和 Markdown 格式,并强调保存在 /spec/ 的内容应清晰且适合 AI 使用。

主要功能

  1. 01更新指定的现有规格说明
  2. 02区分需求、约束和建议
  3. 03要求结构化且自包含的 Markdown
  4. 04规定 /spec/ 路径与文件命名格式
  5. 05提供 front matter 和章节模板

适用场景

  1. 01使规格说明与变更后的需求保持一致
  2. 02在代码变更后更新接口文档
  3. 03创建格式一致且机器可读的规格说明文件

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/github/awesome-copilot --skill update-specification

安装后在 Claude Code 中输入/update-specification确认已加载。

详细介绍

更新规范

你的目标是根据新需求或对任何现有代码的更新,更新现有的规范文件 ${file}。

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

AI 就绪规范的最佳实践

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

规范应保存在 /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. 验证标准

[列出必须满足才能符合本规范的标准或测试。]

11. 相关规范 / 进一步阅读

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

评论

支持 Markdown