update-specification

name	update-specification
description	Update an existing specification GitHub Issue based on new requirements or updates to any existing code.

Update Specification

Your goal is to update an existing specification that is managed as a GitHub Issue based on new requirements or updates to any existing code.

対象 Issue の特定

ユーザーが Issue 番号またはタイトルで対象を指定する。

• Issue 番号が指定された場合: gh issue view <番号> で内容を取得する
• タイトルが指定された場合: gh issue list --search "<タイトル>" で検索し、該当 Issue を特定する
• 対象が見つからない場合はユーザーに確認を取ること

Issue の更新方法

gh CLI を使用して Issue の body を更新する。

gh issue edit <番号> --body "<更新後の Markdown 本文>"

• 既存の内容を取得し、差分を反映する形で更新すること
• 変更箇所が明確になるよう、更新後にユーザーへ変更サマリを報告すること

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 も以下のテンプレート構造を維持すること。

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