Generated banner for Create Specification
Generated logo for Create Specification

Create Specification

GitHubOfficialFirst committed by stbenjamDistributed by GitHub

  • Skill
  • Content generator
  • Software development
  • MIT
  • No issues found

From the author

Create a new specification file for the solution, optimized for Generative AI consumption.
— the description by stbenjam

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The create-specification skill provides a standardized framework for authoring technical documentation designed specifically for Generative AI consumption. By enforcing a rigid, machine-readable Markdown structure, it ensures that requirements, constraints, interfaces, and acceptance criteria are clearly defined and unambiguous. This approach minimizes context-dependent language and promotes self-contained documentation that serves as a reliable source of truth for AI-driven development workflows.

What it does

  • Generates a structured Markdown specification file based on a provided purpose.
  • Enforces a standardized template including sections for requirements, interfaces, and test strategies.
  • Promotes the use of explicit, unambiguous language suitable for AI parsing.
  • Requires clear definition of acceptance criteria using Given-When-Then formatting.
  • Structures dependencies and architectural constraints to avoid implementation-specific bias.
  • Ensures all specifications are self-contained and free of external context dependencies.

When to use it

  • When you need to define clear requirements for a new software component or system.
  • When preparing documentation that will be used as context for AI-assisted coding or architecture tasks.
  • When you need to ensure consistency across technical documentation within a project.
  • When you need to define testable acceptance criteria for complex features.

Advantages

  • Improves AI performance by providing highly structured and predictable input data.
  • Reduces ambiguity in technical requirements through standardized formatting.
  • Ensures comprehensive coverage of architectural, security, and compliance dependencies.
  • Facilitates easier validation and testing by requiring explicit acceptance criteria.

Usage examples

“Create a specification for a new user authentication schema.”
Generates a file named spec-schema-user-auth.md in the /spec/ directory, populated with the required sections including definitions, data contracts, and validation criteria.
“Create a specification for the infrastructure requirements of our new microservice.”
Generates a file named spec-infrastructure-microservice.md, detailing infrastructure dependencies, platform requirements, and compliance constraints in the specified template.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/github/create-specification/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip create-specification.zip -d .agents/skills

Documentation by stbenjam

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:

---
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]

Files

Requirements and compatibility

Written for: GitHub Copilot

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

First committed by
GitHub avatar of stbenjamstbenjam
Publisher
GitHub (Official)
Distributed by
GitHub
Source
github/awesome-copilot · skills/create-specification · commit 797337f
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Contributors
stbenjam

AutoGineer is not affiliated with or endorsed by stbenjam or GitHub.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download create-specification.zip