Skip to main content

create-specification

Create a new specification as a GitHub Issue, optimized for Generative AI consumption.

Informações da origem

Repositório
runceel/ai-dev-template
Última atividade na origem
24 de abril de 2026 às 02:50
Idioma detectado do SKILL.md
inglês
Estrelas
11
Forks
0

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Exibindo SKILL.md

SKILL.md
Instruções da origem · Visualização somente leitura
name
create-specification
description
Create a new specification as a GitHub Issue, optimized for Generative AI consumption.
# Create Specification Your goal is to create a new specification for `${input:SpecPurpose}` as a **GitHub Issue** in the current repository. The specification 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. ## Issue の作成方法 `gh` CLI を使用して GitHub Issue を作成する。 ```bash gh issue create --title "<タイトル>" --body "<Markdown 本文>" ``` - **タイトル規約**: `[SPEC] <目的カテゴリ>: <仕様の簡潔な説明>` - 目的カテゴリは `schema`, `tool`, `data`, `infrastructure`, `process`, `architecture`, `design` のいずれか - 例: `[SPEC] design: Web UI 画面設計仕様`、`[SPEC] architecture: 認証基盤設計` - Issue 作成後、作成された Issue 番号をユーザーに報告すること ## 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. ## Issue Body Template Issue の body は以下のテンプレートに従い、すべてのセクションを適切に記述すること。 ```md # 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 Issue or external documentation] ```
Ver no GitHub