create-specification — GitHub Copilot skill: install and use
This skill creates a structured Markdown specification with requirements, constraints, and interfaces. Use it when an AI agent needs a clear project contract.
npx skills add github/awesome-copilot --skill create-specificationWhat create-specification does
The skill asks the agent to create a specification for a chosen purpose and save it under /spec/ with a name matching spec-[a-z0-9-]+.md. The filename starts with a high-level purpose such as schema, tool, data, infrastructure, process, architecture, or design. The file uses well-formed Markdown and front matter.
Its template covers scope, definitions, requirements, constraints, interfaces, and data contracts. It also includes acceptance criteria, a test automation strategy, rationale, dependencies, examples, validation criteria, and related specifications. The requested writing style is explicit, structured, machine-readable, and self-contained for generative AI use.
Install it when your project needs repeatable specification files that an agent can parse and follow. It is a poor fit for a short note with no requirements or interfaces.
What it helps with
- create a Markdown specification for a solution
- separate requirements, constraints, and guidelines
- document interfaces and data contracts
- define acceptance criteria and test automation
- save the file under the required path and naming pattern
Example prompts for the agent
- Create a specification for the new data schema and save it in `/spec/`.
- Write the requirements, constraints, and interfaces for this tool in `spec-tool-api.md`.
- Add acceptance criteria, examples, and edge cases to the specification template.
How to install create-specification
1Skills CLI (Vercel)
npx skills add github/awesome-copilot --skill create-specification2GitHub CLI
gh skill install github/awesome-copilot create-specification3Manually: put the files in place
.github/skills/create-specification/SKILL.md1Skills CLI (Vercel)
npx skills add github/awesome-copilot --skill create-specification -a claude-code2Manually: put the files in place
~/.claude/skills/create-specification/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/create-specification/
Manually: put the files in place
.agents/skills/create-specification/SKILL.mdFor all projects use ~/.agents/skills/
Manually: put the files in place
.cursor/skills/create-specification/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
Platform CLI
gemini skills install https://github.com/github/awesome-copilot --path skills/create-specificationManually: put the files in place
.devin/skills/create-specification/SKILL.mdThe legacy .windsurf/skills/ path still works
Claude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
From the same set554
The whole set →Similar
Questions about create-specification
How do I install create-specification in GitHub Copilot?
Run npx skills add github/awesome-copilot --skill create-specification. The skill file is then available at .github/skills/create-specification/SKILL.md.
What does create-specification do?
It creates a Markdown specification for a selected purpose. The document records requirements, constraints, interfaces, acceptance criteria, dependencies, and examples.
Where does create-specification save the specification?
It saves the file in /spec/ using the spec-[a-z0-9-]+.md naming pattern. The filename starts with a purpose such as schema or architecture.
Source text
SKILL.md · MIT
---
name: create-specification
description: 'Create a new specification file for the solution, optimized for Generative AI consumption.'
---
# 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.
## Best Practices for AI-Ready Specifications
- 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]
---
# 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]
```
© github · MIT · github/awesome-copilot