create-specification

Name: create-specification
Author: github

13kinstalls4.6kforks

How to install create-specification?

github/awesome-copilot/create-specification

$npx -y skills add github/awesome-copilot --skill create-specification

Installs into the current project.

Summary

Create a new specification file for the solution, optimized for Generative AI consumption.

Files · 1

View on GitHub

SKILL.md

1	# Create Specification
2
3	Your goal is to create a new specification file for `${input:SpecPurpose}`.
4
5	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.
6
7	## Best Practices for AI-Ready Specifications
8
9	- Use precise, explicit, and unambiguous language.
10	- Clearly distinguish between requirements, constraints, and recommendations.
11	- Use structured formatting (headings, lists, tables) for easy parsing.
12	- Avoid idioms, metaphors, or context-dependent references.
13	- Define all acronyms and domain-specific terms.
14	- Include examples and edge cases where applicable.
15	- Ensure the document is self-contained and does not rely on external context.
16
17	The specification should be saved in the [/spec/](/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].
18
19	The specification file must be formatted in well formed Markdown.
20
21	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:
22
23	```md
24	---
25	title: [Concise Title Describing the Specification's Focus]
26	version: [Optional: e.g., 1.0, Date]
27	date_created: [YYYY-MM-DD]
28	last_updated: [Optional: YYYY-MM-DD]
29	owner: [Optional: Team/Individual responsible for this spec]
30	tags: [Optional: List of relevant tags or categories, e.g., `infrastructure`, `process`, `design`, `app` etc]
31	---
32
33	# Introduction
34
35	[A short concise introduction to the specification and the goal it is intended to achieve.]
36
37	## 1. Purpose & Scope
38
39	[Provide a clear, concise description of the specification's purpose and the scope of its application. State the intended audience and any assumptions.]
40
41	## 2. Definitions
42
43	[List and define all acronyms, abbreviations, and domain-specific terms used in this specification.]
44
45	## 3. Requirements, Constraints & Guidelines
46
47	[Explicitly list all requirements, constraints, rules, and guidelines. Use bullet points or tables for clarity.]
48
49	- REQ-001: Requirement 1
50	- SEC-001: Security Requirement 1
51	- [3 LETTERS]-001: Other Requirement 1
52	- CON-001: Constraint 1
53	- GUD-001: Guideline 1
54	- PAT-001: Pattern to follow 1
55
56	## 4. Interfaces & Data Contracts
57
58	[Describe the interfaces, APIs, data contracts, or integration points. Use tables or code blocks for schemas and examples.]
59
60	## 5. Acceptance Criteria
61
62	[Define clear, testable acceptance criteria for each requirement using Given-When-Then format where appropriate.]
63
64	- AC-001: Given [context], When [action], Then [expected outcome]
65	- AC-002: The system shall [specific behavior] when [condition]
66	- AC-003: [Additional acceptance criteria as needed]
67
68	## 6. Test Automation Strategy
69
70	[Define the testing approach, frameworks, and automation requirements.]
71
72	- Test Levels: Unit, Integration, End-to-End
73	- Frameworks: MSTest, FluentAssertions, Moq (for .NET applications)
74	- Test Data Management: [approach for test data creation and cleanup]
75	- CI/CD Integration: [automated testing in GitHub Actions pipelines]
76	- Coverage Requirements: [minimum code coverage thresholds]
77	- Performance Testing: [approach for load and performance testing]
78
79	## 7. Rationale & Context
80
81	[Explain the reasoning behind the requirements, constraints, and guidelines. Provide context for design decisions.]
82
83	## 8. Dependencies & External Integrations
84
85	[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.]
86
87	### External Systems
88	- EXT-001: [External system name] - [Purpose and integration type]
89
90	### Third-Party Services
91	- SVC-001: [Service name] - [Required capabilities and SLA requirements]
92
93	### Infrastructure Dependencies
94	- INF-001: [Infrastructure component] - [Requirements and constraints]
95
96	### Data Dependencies
97	- DAT-001: [External data source] - [Format, frequency, and access requirements]
98
99	### Technology Platform Dependencies
100	- PLT-001: [Platform/runtime requirement] - [Version constraints and rationale]
101
102	### Compliance Dependencies
103	- COM-001: [Regulatory or compliance requirement] - [Impact on implementation]
104
105	Note: This section should focus on architectural and business dependencies, not specific package implementations. For example,

People who liked this also viewed

6 picks

Type

grill-with-docsA relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.SkillsJul 2026537k182k
lark-minutes飞书妙记：搜索妙记、查看妙记基础信息、下载/上传音视频、读取或编辑妙记的产物内容、改标题、替换说话人/关键词、申请妙记查看/编辑权限。当给出minute_token、本地音视频文件，要查/改/转妙记产物，或用户明确要主动申请妙记权限时使用；本地音视频转纪要/逐字稿优先走本 skill，不要用 ffmpeg/whisper 本地转写。不负责：获取会议关联妙记，或仅按自然语言标题定位纪要SkillsJul 2026379k16k
lark-markdown飞书 Markdown：查看、创建、上传、编辑和比较 Markdown 文件。当用户需要创建或编辑 Markdown 文件、读取、修改、局部 patch 或比较差异时使用。不负责将 Markdown 导入为飞书在线文档，也不负责文件搜索、权限、评论、移动、删除等云空间管理操作。SkillsJul 2026295k16k
docxUse this skill whenever the user wants to create, read, edit, or manipulate Word documents (.docx files) or Word templates (.dotx files). Triggers include: any mention of 'Word doc', 'word document', SkillsJul 2026157k163k
edit-articleSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026154k181k
lark-note飞书会议纪要（Note）直查：已知 note_id 时查询纪要详情、展示类型、关联文档 token，并读取 unified 原始逐字记录。当用户已持有 note_id，或从文档显式 vc-node-id 获得 note_id 时使用。不负责会议/日程/妙记定位、文档标题搜索或 Docx 正文读取。SkillsJul 2026154k16k

create-specification

13kinstalls4.6kforks

View on GitHub

How to install create-specification?

github/awesome-copilot/create-specification

$npx -y skills add github/awesome-copilot --skill create-specification

Installs into the current project.

Summary

Create a new specification file for the solution, optimized for Generative AI consumption.

Files · 1

View on GitHub

SKILL.md

1	# Create Specification
2
3	Your goal is to create a new specification file for `${input:SpecPurpose}`.
4
5	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.
6
7	## Best Practices for AI-Ready Specifications
8
9	- Use precise, explicit, and unambiguous language.
10	- Clearly distinguish between requirements, constraints, and recommendations.
11	- Use structured formatting (headings, lists, tables) for easy parsing.
12	- Avoid idioms, metaphors, or context-dependent references.
13	- Define all acronyms and domain-specific terms.
14	- Include examples and edge cases where applicable.
15	- Ensure the document is self-contained and does not rely on external context.
16
17	The specification should be saved in the [/spec/](/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].
18
19	The specification file must be formatted in well formed Markdown.
20
21	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:
22
23	```md
24	---
25	title: [Concise Title Describing the Specification's Focus]
26	version: [Optional: e.g., 1.0, Date]
27	date_created: [YYYY-MM-DD]
28	last_updated: [Optional: YYYY-MM-DD]
29	owner: [Optional: Team/Individual responsible for this spec]
30	tags: [Optional: List of relevant tags or categories, e.g., `infrastructure`, `process`, `design`, `app` etc]
31	---
32
33	# Introduction
34
35	[A short concise introduction to the specification and the goal it is intended to achieve.]
36
37	## 1. Purpose & Scope
38
39	[Provide a clear, concise description of the specification's purpose and the scope of its application. State the intended audience and any assumptions.]
40
41	## 2. Definitions
42
43	[List and define all acronyms, abbreviations, and domain-specific terms used in this specification.]
44
45	## 3. Requirements, Constraints & Guidelines
46
47	[Explicitly list all requirements, constraints, rules, and guidelines. Use bullet points or tables for clarity.]
48
49	- REQ-001: Requirement 1
50	- SEC-001: Security Requirement 1
51	- [3 LETTERS]-001: Other Requirement 1
52	- CON-001: Constraint 1
53	- GUD-001: Guideline 1
54	- PAT-001: Pattern to follow 1
55
56	## 4. Interfaces & Data Contracts
57
58	[Describe the interfaces, APIs, data contracts, or integration points. Use tables or code blocks for schemas and examples.]
59
60	## 5. Acceptance Criteria
61
62	[Define clear, testable acceptance criteria for each requirement using Given-When-Then format where appropriate.]
63
64	- AC-001: Given [context], When [action], Then [expected outcome]
65	- AC-002: The system shall [specific behavior] when [condition]
66	- AC-003: [Additional acceptance criteria as needed]
67
68	## 6. Test Automation Strategy
69
70	[Define the testing approach, frameworks, and automation requirements.]
71
72	- Test Levels: Unit, Integration, End-to-End
73	- Frameworks: MSTest, FluentAssertions, Moq (for .NET applications)
74	- Test Data Management: [approach for test data creation and cleanup]
75	- CI/CD Integration: [automated testing in GitHub Actions pipelines]
76	- Coverage Requirements: [minimum code coverage thresholds]
77	- Performance Testing: [approach for load and performance testing]
78
79	## 7. Rationale & Context
80
81	[Explain the reasoning behind the requirements, constraints, and guidelines. Provide context for design decisions.]
82
83	## 8. Dependencies & External Integrations
84
85	[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.]
86
87	### External Systems
88	- EXT-001: [External system name] - [Purpose and integration type]
89
90	### Third-Party Services
91	- SVC-001: [Service name] - [Required capabilities and SLA requirements]
92
93	### Infrastructure Dependencies
94	- INF-001: [Infrastructure component] - [Requirements and constraints]
95
96	### Data Dependencies
97	- DAT-001: [External data source] - [Format, frequency, and access requirements]
98
99	### Technology Platform Dependencies
100	- PLT-001: [Platform/runtime requirement] - [Version constraints and rationale]
101
102	### Compliance Dependencies
103	- COM-001: [Regulatory or compliance requirement] - [Impact on implementation]
104
105	Note: This section should focus on architectural and business dependencies, not specific package implementations. For example,

People who liked this also viewed

6 picks

Type