
Create Specification
Author a machine-readable spec in `/spec/` with the copilot naming template so agents implement `${input:SpecPurpose}` without ambiguous requirements.
Overview
create-specification is an agent skill most often used in Validate (also Build) that writes Gen-AI-ready Markdown specs in `/spec/` for a stated solution purpose.
Install
npx skills add https://github.com/github/awesome-copilot --skill create-specificationWhat is this skill?
- Creates AI-ready specs with explicit requirements vs constraints vs recommendations
- Saves under `/spec/` as `spec-[a-z0-9-]+.md` with purpose prefix (schema, tool, data, etc.)
- Enforces well-formed Markdown and self-contained definitions of terms
- Parameterized goal via `${input:SpecPurpose}` for targeted solution components
- Structured headings, lists, and tables for reliable Gen AI parsing
- Spec path convention: `/spec/spec-[a-z0-9-]+.md`
- Purpose prefixes include schema, tool, data, infrastructure, process, architecture, design
Adoption & trust: 11.5k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You know what you want to build but lack a single, unambiguous spec file that coding agents can parse without hidden context.
Who is it for?
Indie developers using Copilot-class agents who want repository-local specs before multi-file implementation.
Skip if: Teams that only need ad-hoc comments, or projects where formal specs are already signed off in an external PM tool with no repo sync.
When should I use this skill?
You need a new specification file for `${input:SpecPurpose}` optimized for Generative AI consumption.
What do I get? / Deliverables
You get a self-contained `spec-*.md` in `/spec/` defining requirements, constraints, and interfaces for `${input:SpecPurpose}`, ready for implementation agents.
- Markdown specification file under `/spec/`
- Defined requirements, constraints, interfaces, and glossary
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Validate/scope is the first hard gate where requirements must be frozen before Build; this skill creates that artifact. Scope fits specification work that bounds interfaces, constraints, and acceptance before implementation.
Where it fits
Define API and data constraints before approving an MVP slice.
Split a multi-service change into spec-per-component files agents can load.
Compare implementation PRs against the written requirements and interface tables in spec.
How it compares
Structured spec generator for `/spec/`, not a one-shot chat plan or an OpenAPI-only stub.
Common Questions / FAQ
Who is create-specification for?
Builders and agent users who want explicit, machine-readable requirements documents inside the repo before coding.
When should I use create-specification?
In Validate when scoping a feature or integration, in Build when splitting a monolith into documented components, before any large agent-driven refactor.
Is create-specification safe to install?
It is documentation-focused; review the Security Audits panel on this page and avoid putting secrets into spec files.
SKILL.md
READMESKILL.md - Create Specification
# 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/](/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, a