update-specification

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