devskill 2.0.6 → 2.0.8

package/skills/update-implementation-plan/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: update-implementation-plan
+description: 'Update an existing implementation plan file with new or update requirements to provide new features, refactoring existing code or upgrading packages, design, architecture or infrastructure.'
+---
+
+# Update Implementation Plan
+
+## Primary Directive
+
+You are an AI agent tasked with updating the implementation plan file `${file}` based on new or updated requirements. Your output must be machine-readable, deterministic, and structured for autonomous execution by other AI systems or humans.
+
+## Execution Context
+
+This prompt is designed for AI-to-AI communication and automated processing. All instructions must be interpreted literally and executed systematically without human interpretation or clarification.
+
+## Core Requirements
+
+- Generate implementation plans that are fully executable by AI agents or humans
+- Use deterministic language with zero ambiguity
+- Structure all content for automated parsing and execution
+- Ensure complete self-containment with no external dependencies for understanding
+
+## Plan Structure Requirements
+
+Plans must consist of discrete, atomic phases containing executable tasks. Each phase must be independently processable by AI agents or humans without cross-phase dependencies unless explicitly declared.
+
+## Phase Architecture
+
+- Each phase must have measurable completion criteria
+- Tasks within phases must be executable in parallel unless dependencies are specified
+- All task descriptions must include specific file paths, function names, and exact implementation details
+- No task should require human interpretation or decision-making
+
+## AI-Optimized Implementation Standards
+
+- Use explicit, unambiguous language with zero interpretation required
+- Structure all content as machine-parseable formats (tables, lists, structured data)
+- Include specific file paths, line numbers, and exact code references where applicable
+- Define all variables, constants, and configuration values explicitly
+- Provide complete context within each task description
+- Use standardized prefixes for all identifiers (REQ-, TASK-, etc.)
+- Include validation criteria that can be automatically verified
+
+## Output File Specifications
+
+- Save implementation plan files in `/plan/` directory
+- Use naming convention: `[purpose]-[component]-[version].md`
+- Purpose prefixes: `upgrade|refactor|feature|data|infrastructure|process|architecture|design`
+- Example: `upgrade-system-command-4.md`, `feature-auth-module-1.md`
+- File must be valid Markdown with proper front matter structure
+
+## Mandatory Template Structure
+
+All implementation plans must strictly adhere to the following template. Each section is required and must be populated with specific, actionable content. AI agents must validate template compliance before execution.
+
+## Template Validation Rules
+
+- All front matter fields must be present and properly formatted
+- All section headers must match exactly (case-sensitive)
+- All identifier prefixes must follow the specified format
+- Tables must include all required columns
+- No placeholder text may remain in the final output
+
+## Status
+
+The status of the implementation plan must be clearly defined in the front matter and must reflect the current state of the plan. The status can be one of the following (status_color in brackets): `Completed` (bright green badge), `In progress` (yellow badge), `Planned` (blue badge), `Deprecated` (red badge), or `On Hold` (orange badge). It should also be displayed as a badge in the introduction section.
+
+```md
+---
+goal: [Concise Title Describing the Package Implementation Plan's Goal]
+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]
+status: 'Completed'|'In progress'|'Planned'|'Deprecated'|'On Hold'
+tags: [Optional: List of relevant tags or categories, e.g., `feature`, `upgrade`, `chore`, `architecture`, `migration`, `bug` etc]
+---
+
+# Introduction
+
+![Status: <status>](https://img.shields.io/badge/status-<status>-<status_color>)
+
+[A short concise introduction to the plan and the goal it is intended to achieve.]
+
+## 1. Requirements & Constraints
+
+[Explicitly list all requirements & constraints that affect the plan and constrain how it is implemented. 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
+
+## 2. Implementation Steps
+
+### Implementation Phase 1
+
+- GOAL-001: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
+
+| Task | Description | Completed | Date |
+|------|-------------|-----------|------|
+| TASK-001 | Description of task 1 | ✅ | 2025-04-25 |
+| TASK-002 | Description of task 2 | |  |
+| TASK-003 | Description of task 3 | |  |
+
+### Implementation Phase 2
+
+- GOAL-002: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
+
+| Task | Description | Completed | Date |
+|------|-------------|-----------|------|
+| TASK-004 | Description of task 4 | |  |
+| TASK-005 | Description of task 5 | |  |
+| TASK-006 | Description of task 6 | |  |
+
+## 3. Alternatives
+
+[A bullet point list of any alternative approaches that were considered and why they were not chosen. This helps to provide context and rationale for the chosen approach.]
+
+- **ALT-001**: Alternative approach 1
+- **ALT-002**: Alternative approach 2
+
+## 4. Dependencies
+
+[List any dependencies that need to be addressed, such as libraries, frameworks, or other components that the plan relies on.]
+
+- **DEP-001**: Dependency 1
+- **DEP-002**: Dependency 2
+
+## 5. Files
+
+[List the files that will be affected by the feature or refactoring task.]
+
+- **FILE-001**: Description of file 1
+- **FILE-002**: Description of file 2
+
+## 6. Testing
+
+[List the tests that need to be implemented to verify the feature or refactoring task.]
+
+- **TEST-001**: Description of test 1
+- **TEST-002**: Description of test 2
+
+## 7. Risks & Assumptions
+
+[List any risks or assumptions related to the implementation of the plan.]
+
+- **RISK-001**: Risk 1
+- **ASSUMPTION-001**: Assumption 1
+
+## 8. Related Specifications / Further Reading
+
+[Link to related spec 1]
+[Link to relevant external documentation]
+```

package/skills/update-implementation-plan/SYNC.md

@@ -0,0 +1,5 @@
+# Sync Info
+
+- **Source:** `vendor/awesome-copilot/skills/update-implementation-plan`
+- **Git SHA:** `23fb7006c132a0bba75b0e5af7a35cab11272812`
+- **Synced:** 2026-03-24

package/skills/update-llms/LICENSE.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright GitHub, Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/update-llms/SKILL.md

@@ -0,0 +1,216 @@
+---
+name: update-llms
+description: 'Update the llms.txt file in the root folder to reflect changes in documentation or specifications following the llms.txt specification at https://llmstxt.org/'
+---
+
+# Update LLMs.txt File
+
+Update the existing `llms.txt` file in the root of the repository to reflect changes in documentation, specifications, or repository structure. This file provides high-level guidance to large language models (LLMs) on where to find relevant content for understanding the repository's purpose and specifications.
+
+## Primary Directive
+
+Update the existing `llms.txt` file to maintain accuracy and compliance with the llms.txt specification while reflecting current repository structure and content. The file must remain optimized for LLM consumption while staying human-readable.
+
+## Analysis and Planning Phase
+
+Before updating the `llms.txt` file, you must complete a thorough analysis:
+
+### Step 1: Review Current File and Specification
+- Read the existing `llms.txt` file to understand current structure
+- Review the official specification at https://llmstxt.org/ to ensure continued compliance
+- Identify areas that may need updates based on repository changes
+
+### Step 2: Repository Structure Analysis
+- Examine the current repository structure using appropriate tools
+- Compare current structure with what's documented in existing `llms.txt`
+- Identify new directories, files, or documentation that should be included
+- Note any removed or relocated files that need to be updated
+
+### Step 3: Content Discovery and Change Detection
+- Identify new README files and their locations
+- Find new documentation files (`.md` files in `/docs/`, `/spec/`, etc.)
+- Locate new specification files and their purposes
+- Discover new configuration files and their relevance
+- Find new example files and code samples
+- Identify any changes to existing documentation structure
+
+### Step 4: Create Update Plan
+Based on your analysis, create a structured plan that includes:
+- Changes needed to maintain accuracy
+- New files to be added to the llms.txt
+- Outdated references to be removed or updated
+- Organizational improvements to maintain clarity
+
+## Implementation Requirements
+
+### Format Compliance
+The updated `llms.txt` file must maintain this exact structure per the specification:
+
+1. **H1 Header**: Single line with repository/project name (required)
+2. **Blockquote Summary**: Brief description in blockquote format (optional but recommended)
+3. **Additional Details**: Zero or more markdown sections without headings for context
+4. **File List Sections**: Zero or more H2 sections containing markdown lists of links
+
+### Content Requirements
+
+#### Required Elements
+- **Project Name**: Clear, descriptive title as H1
+- **Summary**: Concise blockquote explaining the repository's purpose
+- **Key Files**: Essential files organized by category (H2 sections)
+
+#### File Link Format
+Each file link must follow: `[descriptive-name](relative-url): optional description`
+
+#### Section Organization
+Organize files into logical H2 sections such as:
+- **Documentation**: Core documentation files
+- **Specifications**: Technical specifications and requirements
+- **Examples**: Sample code and usage examples
+- **Configuration**: Setup and configuration files
+- **Optional**: Secondary files (special meaning - can be skipped for shorter context)
+
+### Content Guidelines
+
+#### Language and Style
+- Use concise, clear, unambiguous language
+- Avoid jargon without explanation
+- Write for both human and LLM readers
+- Be specific and informative in descriptions
+
+#### File Selection Criteria
+Include files that:
+- Explain the repository's purpose and scope
+- Provide essential technical documentation
+- Show usage examples and patterns
+- Define interfaces and specifications
+- Contain configuration and setup instructions
+
+Exclude files that:
+- Are purely implementation details
+- Contain redundant information
+- Are build artifacts or generated content
+- Are not relevant to understanding the project
+
+## Execution Steps
+
+### Step 1: Current State Analysis
+1. Read the existing `llms.txt` file thoroughly
+2. Examine the current repository structure completely
+3. Compare existing file references with actual repository content
+4. Identify outdated, missing, or incorrect references
+5. Note any structural issues with the current file
+
+### Step 2: Content Planning
+1. Determine if the primary purpose statement needs updates
+2. Review and update the summary blockquote if needed
+3. Plan additions for new files and directories
+4. Plan removals for outdated or moved content
+5. Reorganize sections if needed for better clarity
+
+### Step 3: File Updates
+1. Update the existing `llms.txt` file in the repository root
+2. Maintain compliance with the exact format specification
+3. Add new file references with appropriate descriptions
+4. Remove or update outdated references
+5. Ensure all links are valid relative paths
+
+### Step 4: Validation
+1. Verify continued compliance with https://llmstxt.org/ specification
+2. Check that all links are valid and accessible
+3. Ensure the file still serves as an effective LLM navigation tool
+4. Confirm the file remains both human and machine readable
+
+## Quality Assurance
+
+### Format Validation
+- ✅ H1 header with project name
+- ✅ Blockquote summary (if included)
+- ✅ H2 sections for file lists
+- ✅ Proper markdown link format
+- ✅ No broken or invalid links
+- ✅ Consistent formatting throughout
+
+### Content Validation
+- ✅ Clear, unambiguous language
+- ✅ Comprehensive coverage of essential files
+- ✅ Logical organization of content
+- ✅ Appropriate file descriptions
+- ✅ Serves as effective LLM navigation tool
+
+### Specification Compliance
+- ✅ Follows https://llmstxt.org/ format exactly
+- ✅ Uses required markdown structure
+- ✅ Implements optional sections appropriately
+- ✅ File located at repository root (`/llms.txt`)
+
+## Update Strategy
+
+### Addition Process
+When adding new content:
+1. Identify the appropriate section for new files
+2. Create clear, descriptive names for links
+3. Write concise but informative descriptions
+4. Maintain alphabetical or logical ordering within sections
+5. Consider if new sections are needed for new content types
+
+### Removal Process
+When removing outdated content:
+1. Verify files are actually removed or relocated
+2. Check if relocated files should be updated rather than removed
+3. Remove entire sections if they become empty
+4. Update cross-references if needed
+
+### Reorganization Process
+When restructuring content:
+1. Maintain logical flow from general to specific
+2. Keep essential documentation in primary sections
+3. Move secondary content to "Optional" section if appropriate
+4. Ensure new organization improves LLM navigation
+
+Example structure for `llms.txt`:
+
+```txt
+# [Repository Name]
+
+> [Concise description of the repository's purpose and scope]
+
+[Optional additional context paragraphs without headings]
+
+## Documentation
+
+- [Main README](README.md): Primary project documentation and getting started guide
+- [Contributing Guide](CONTRIBUTING.md): Guidelines for contributing to the project
+- [Code of Conduct](CODE_OF_CONDUCT.md): Community guidelines and expectations
+
+## Specifications
+
+- [Technical Specification](spec/technical-spec.md): Detailed technical requirements and constraints
+- [API Specification](spec/api-spec.md): Interface definitions and data contracts
+
+## Examples
+
+- [Basic Example](examples/basic-usage.md): Simple usage demonstration
+- [Advanced Example](examples/advanced-usage.md): Complex implementation patterns
+
+## Configuration
+
+- [Setup Guide](docs/setup.md): Installation and configuration instructions
+- [Deployment Guide](docs/deployment.md): Production deployment guidelines
+
+## Optional
+
+- [Architecture Documentation](docs/architecture.md): Detailed system architecture
+- [Design Decisions](docs/decisions.md): Historical design decision records
+```
+
+## Success Criteria
+
+The updated `llms.txt` file should:
+1. Accurately reflect the current repository structure and content
+2. Maintain compliance with the llms.txt specification
+3. Provide clear navigation to essential documentation
+4. Remove outdated or incorrect references
+5. Include new important files and documentation
+6. Maintain logical organization for easy LLM consumption
+7. Use clear, unambiguous language throughout
+8. Continue to serve both human and machine readers effectively

package/skills/update-llms/SYNC.md

@@ -0,0 +1,5 @@
+# Sync Info
+
+- **Source:** `vendor/awesome-copilot/skills/update-llms`
+- **Git SHA:** `23fb7006c132a0bba75b0e5af7a35cab11272812`
+- **Synced:** 2026-03-24

package/skills/update-markdown-file-index/LICENSE.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright GitHub, Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/update-markdown-file-index/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: update-markdown-file-index
+description: 'Update a markdown file section with an index/table of files from a specified folder.'
+---
+
+# Update Markdown File Index
+
+Update markdown file `${file}` with an index/table of files from folder `${input:folder}`.
+
+## Process
+
+1. **Scan**: Read the target markdown file `${file}` to understand existing structure
+2. **Discover**: List all files in the specified folder `${input:folder}` matching pattern `${input:pattern}`
+3. **Analyze**: Identify if an existing table/index section exists to update, or create new structure
+4. **Structure**: Generate appropriate table/list format based on file types and existing content
+5. **Update**: Replace existing section or add new section with file index
+6. **Validate**: Ensure markdown syntax is valid and formatting is consistent
+
+## File Analysis
+
+For each discovered file, extract:
+
+- **Name**: Filename with or without extension based on context
+- **Type**: File extension and category (e.g., `.md`, `.js`, `.py`)
+- **Description**: First line comment, header, or inferred purpose
+- **Size**: File size for reference (optional)
+- **Modified**: Last modified date (optional)
+
+## Table Structure Options
+
+Choose format based on file types and existing content:
+
+### Option 1: Simple List
+
+```markdown
+## Files in ${folder}
+
+- [filename.ext](path/to/filename.ext) - Description
+- [filename2.ext](path/to/filename2.ext) - Description
+```
+
+### Option 2: Detailed Table
+
+| File | Type | Description |
+|------|------|-------------|
+| [filename.ext](path/to/filename.ext) | Extension | Description |
+| [filename2.ext](path/to/filename2.ext) | Extension | Description |
+
+### Option 3: Categorized Sections
+
+Group files by type/category with separate sections or sub-tables.
+
+## Update Strategy
+
+- 🔄 **Update existing**: If table/index section exists, replace content while preserving structure
+- ➕ **Add new**: If no existing section, create new section using best-fit format
+- 📋 **Preserve**: Maintain existing markdown formatting, heading levels, and document flow
+- 🔗 **Links**: Use relative paths for file links within the repository
+
+## Section Identification
+
+Look for existing sections with these patterns:
+
+- Headings containing: "index", "files", "contents", "directory", "list"
+- Tables with file-related columns
+- Lists with file links
+- HTML comments marking file index sections
+
+## Requirements
+
+- Preserve existing markdown structure and formatting
+- Use relative paths for file links
+- Include file descriptions when available
+- Sort files alphabetically by default
+- Handle special characters in filenames
+- Validate all generated markdown syntax

package/skills/update-markdown-file-index/SYNC.md

@@ -0,0 +1,5 @@
+# Sync Info
+
+- **Source:** `vendor/awesome-copilot/skills/update-markdown-file-index`
+- **Git SHA:** `23fb7006c132a0bba75b0e5af7a35cab11272812`
+- **Synced:** 2026-03-24

package/skills/update-specification/LICENSE.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright GitHub, Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/update-specification/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: update-specification
+description: 'Update an existing specification file for the solution, optimized for Generative AI consumption based on new requirements or updates to any existing code.'
+---
+
+# Update Specification
+
+Your goal is to update the existing specification file `${file}` based on new requirements or updates to any existing code.
+
+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: `[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, 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]
+
+```

package/skills/update-specification/SYNC.md

@@ -0,0 +1,5 @@
+# Sync Info
+
+- **Source:** `vendor/awesome-copilot/skills/update-specification`
+- **Git SHA:** `23fb7006c132a0bba75b0e5af7a35cab11272812`
+- **Synced:** 2026-03-24