@abarcenas/ai-workflow-template 1.1.0 → 1.2.0

package/.github/instructions/memory-bank.instructions.md

@@ -125,6 +125,20 @@ flowchart TD
     Complete -->|No| Execute
 ```
 
+### Audit Trail Requirement
+
+All planning, implementation, and execution work must be recorded in Markdown files.
+
+For every task:
+
+- Create or update a task file in `tasks/` with the request, plan, progress, and decisions.
+- Record implementation progress in the task progress log as work advances.
+- Keep `tasks/_index.md` current.
+- Use `progress.md` and `activeContext.md` for broader project status when relevant.
+- Do not rely on chat alone for durable tracking of plans or execution history.
+
+The Markdown record is the source of truth for auditing, traceability, and recovery after session resets.
+
 ## Documentation Updates
 
 Memory Bank updates occur when:

package/.github/instructions/task-implementation.instructions.md

@@ -11,6 +11,14 @@ Implementation progress MUST be tracked in a corresponding changes files located
 
 ## Core Implementation Process
 
+### Markdown Audit Trail
+
+All planning, implementation, and execution work must be recorded in Markdown files.
+
+- Keep the plan file, the changes file, and any task-specific notes current as work progresses.
+- Do not rely on chat alone for durable tracking of implementation decisions or progress.
+- Treat the Markdown record as the source of truth for auditability and session recovery.
+
 ### 1. Plan Analysis and Preparation
 
 **MUST complete before starting implementation:**

package/.github/skills/architecture-blueprint-generator/SKILL.md

@@ -0,0 +1,322 @@
+---
+name: architecture-blueprint-generator
+description: 'Comprehensive project architecture blueprint generator that analyzes codebases to create detailed architectural documentation. Automatically detects technology stacks and architectural patterns, generates visual diagrams, documents implementation patterns, and provides extensible blueprints for maintaining architectural consistency and guiding new development.'
+---
+
+# Comprehensive Project Architecture Blueprint Generator
+
+## Configuration Variables
+${PROJECT_TYPE="Auto-detect|.NET|Java|React|Angular|Python|Node.js|Flutter|Other"} <!-- Primary technology -->
+${ARCHITECTURE_PATTERN="Auto-detect|Clean Architecture|Microservices|Layered|MVVM|MVC|Hexagonal|Event-Driven|Serverless|Monolithic|Other"} <!-- Primary architectural pattern -->
+${DIAGRAM_TYPE="C4|UML|Flow|Component|None"} <!-- Architecture diagram type -->
+${DETAIL_LEVEL="High-level|Detailed|Comprehensive|Implementation-Ready"} <!-- Level of detail to include -->
+${INCLUDES_CODE_EXAMPLES=true|false} <!-- Include sample code to illustrate patterns -->
+${INCLUDES_IMPLEMENTATION_PATTERNS=true|false} <!-- Include detailed implementation patterns -->
+${INCLUDES_DECISION_RECORDS=true|false} <!-- Include architectural decision records -->
+${FOCUS_ON_EXTENSIBILITY=true|false} <!-- Emphasize extension points and patterns -->
+
+## Generated Prompt
+
+"Create a comprehensive 'Project_Architecture_Blueprint.md' document that thoroughly analyzes the architectural patterns in the codebase to serve as a definitive reference for maintaining architectural consistency. Use the following approach:
+
+### 1. Architecture Detection and Analysis
+- ${PROJECT_TYPE == "Auto-detect" ? "Analyze the project structure to identify all technology stacks and frameworks in use by examining:
+  - Project and configuration files
+  - Package dependencies and import statements
+  - Framework-specific patterns and conventions
+  - Build and deployment configurations" : "Focus on ${PROJECT_TYPE} specific patterns and practices"}
+  
+- ${ARCHITECTURE_PATTERN == "Auto-detect" ? "Determine the architectural pattern(s) by analyzing:
+  - Folder organization and namespacing
+  - Dependency flow and component boundaries
+  - Interface segregation and abstraction patterns
+  - Communication mechanisms between components" : "Document how the ${ARCHITECTURE_PATTERN} architecture is implemented"}
+
+### 2. Architectural Overview
+- Provide a clear, concise explanation of the overall architectural approach
+- Document the guiding principles evident in the architectural choices
+- Identify architectural boundaries and how they're enforced
+- Note any hybrid architectural patterns or adaptations of standard patterns
+
+### 3. Architecture Visualization
+${DIAGRAM_TYPE != "None" ? `Create ${DIAGRAM_TYPE} diagrams at multiple levels of abstraction:
+- High-level architectural overview showing major subsystems
+- Component interaction diagrams showing relationships and dependencies
+- Data flow diagrams showing how information moves through the system
+- Ensure diagrams accurately reflect the actual implementation, not theoretical patterns` : "Describe the component relationships based on actual code dependencies, providing clear textual explanations of:
+- Subsystem organization and boundaries
+- Dependency directions and component interactions
+- Data flow and process sequences"}
+
+### 4. Core Architectural Components
+For each architectural component discovered in the codebase:
+
+- **Purpose and Responsibility**:
+  - Primary function within the architecture
+  - Business domains or technical concerns addressed
+  - Boundaries and scope limitations
+
+- **Internal Structure**:
+  - Organization of classes/modules within the component
+  - Key abstractions and their implementations
+  - Design patterns utilized
+
+- **Interaction Patterns**:
+  - How the component communicates with others
+  - Interfaces exposed and consumed
+  - Dependency injection patterns
+  - Event publishing/subscription mechanisms
+
+- **Evolution Patterns**:
+  - How the component can be extended
+  - Variation points and plugin mechanisms
+  - Configuration and customization approaches
+
+### 5. Architectural Layers and Dependencies
+- Map the layer structure as implemented in the codebase
+- Document the dependency rules between layers
+- Identify abstraction mechanisms that enable layer separation
+- Note any circular dependencies or layer violations
+- Document dependency injection patterns used to maintain separation
+
+### 6. Data Architecture
+- Document domain model structure and organization
+- Map entity relationships and aggregation patterns
+- Identify data access patterns (repositories, data mappers, etc.)
+- Document data transformation and mapping approaches
+- Note caching strategies and implementations
+- Document data validation patterns
+
+### 7. Cross-Cutting Concerns Implementation
+Document implementation patterns for cross-cutting concerns:
+
+- **Authentication & Authorization**:
+  - Security model implementation
+  - Permission enforcement patterns
+  - Identity management approach
+  - Security boundary patterns
+
+- **Error Handling & Resilience**:
+  - Exception handling patterns
+  - Retry and circuit breaker implementations
+  - Fallback and graceful degradation strategies
+  - Error reporting and monitoring approaches
+
+- **Logging & Monitoring**:
+  - Instrumentation patterns
+  - Observability implementation
+  - Diagnostic information flow
+  - Performance monitoring approach
+
+- **Validation**:
+  - Input validation strategies
+  - Business rule validation implementation
+  - Validation responsibility distribution
+  - Error reporting patterns
+
+- **Configuration Management**:
+  - Configuration source patterns
+  - Environment-specific configuration strategies
+  - Secret management approach
+  - Feature flag implementation
+
+### 8. Service Communication Patterns
+- Document service boundary definitions
+- Identify communication protocols and formats
+- Map synchronous vs. asynchronous communication patterns
+- Document API versioning strategies
+- Identify service discovery mechanisms
+- Note resilience patterns in service communication
+
+### 9. Technology-Specific Architectural Patterns
+${PROJECT_TYPE == "Auto-detect" ? "For each detected technology stack, document specific architectural patterns:" : `Document ${PROJECT_TYPE}-specific architectural patterns:`}
+
+${(PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect") ? 
+"#### .NET Architectural Patterns (if detected)
+- Host and application model implementation
+- Middleware pipeline organization
+- Framework service integration patterns
+- ORM and data access approaches
+- API implementation patterns (controllers, minimal APIs, etc.)
+- Dependency injection container configuration" : ""}
+
+${(PROJECT_TYPE == "Java" || PROJECT_TYPE == "Auto-detect") ? 
+"#### Java Architectural Patterns (if detected)
+- Application container and bootstrap process
+- Dependency injection framework usage (Spring, CDI, etc.)
+- AOP implementation patterns
+- Transaction boundary management
+- ORM configuration and usage patterns
+- Service implementation patterns" : ""}
+
+${(PROJECT_TYPE == "React" || PROJECT_TYPE == "Auto-detect") ? 
+"#### React Architectural Patterns (if detected)
+- Component composition and reuse strategies
+- State management architecture
+- Side effect handling patterns
+- Routing and navigation approach
+- Data fetching and caching patterns
+- Rendering optimization strategies" : ""}
+
+${(PROJECT_TYPE == "Angular" || PROJECT_TYPE == "Auto-detect") ? 
+"#### Angular Architectural Patterns (if detected)
+- Module organization strategy
+- Component hierarchy design
+- Service and dependency injection patterns
+- State management approach
+- Reactive programming patterns
+- Route guard implementation" : ""}
+
+${(PROJECT_TYPE == "Python" || PROJECT_TYPE == "Auto-detect") ? 
+"#### Python Architectural Patterns (if detected)
+- Module organization approach
+- Dependency management strategy
+- OOP vs. functional implementation patterns
+- Framework integration patterns
+- Asynchronous programming approach" : ""}
+
+### 10. Implementation Patterns
+${INCLUDES_IMPLEMENTATION_PATTERNS ? 
+"Document concrete implementation patterns for key architectural components:
+
+- **Interface Design Patterns**:
+  - Interface segregation approaches
+  - Abstraction level decisions
+  - Generic vs. specific interface patterns
+  - Default implementation patterns
+
+- **Service Implementation Patterns**:
+  - Service lifetime management
+  - Service composition patterns
+  - Operation implementation templates
+  - Error handling within services
+
+- **Repository Implementation Patterns**:
+  - Query pattern implementations
+  - Transaction management
+  - Concurrency handling
+  - Bulk operation patterns
+
+- **Controller/API Implementation Patterns**:
+  - Request handling patterns
+  - Response formatting approaches
+  - Parameter validation
+  - API versioning implementation
+
+- **Domain Model Implementation**:
+  - Entity implementation patterns
+  - Value object patterns
+  - Domain event implementation
+  - Business rule enforcement" : "Mention that detailed implementation patterns vary across the codebase."}
+
+### 11. Testing Architecture
+- Document testing strategies aligned with the architecture
+- Identify test boundary patterns (unit, integration, system)
+- Map test doubles and mocking approaches
+- Document test data strategies
+- Note testing tools and frameworks integration
+
+### 12. Deployment Architecture
+- Document deployment topology derived from configuration
+- Identify environment-specific architectural adaptations
+- Map runtime dependency resolution patterns
+- Document configuration management across environments
+- Identify containerization and orchestration approaches
+- Note cloud service integration patterns
+
+### 13. Extension and Evolution Patterns
+${FOCUS_ON_EXTENSIBILITY ? 
+"Provide detailed guidance for extending the architecture:
+
+- **Feature Addition Patterns**:
+  - How to add new features while preserving architectural integrity
+  - Where to place new components by type
+  - Dependency introduction guidelines
+  - Configuration extension patterns
+
+- **Modification Patterns**:
+  - How to safely modify existing components
+  - Strategies for maintaining backward compatibility
+  - Deprecation patterns
+  - Migration approaches
+
+- **Integration Patterns**:
+  - How to integrate new external systems
+  - Adapter implementation patterns
+  - Anti-corruption layer patterns
+  - Service facade implementation" : "Document key extension points in the architecture."}
+
+${INCLUDES_CODE_EXAMPLES ? 
+"### 14. Architectural Pattern Examples
+Extract representative code examples that illustrate key architectural patterns:
+
+- **Layer Separation Examples**:
+  - Interface definition and implementation separation
+  - Cross-layer communication patterns
+  - Dependency injection examples
+
+- **Component Communication Examples**:
+  - Service invocation patterns
+  - Event publication and handling
+  - Message passing implementation
+
+- **Extension Point Examples**:
+  - Plugin registration and discovery
+  - Extension interface implementations
+  - Configuration-driven extension patterns
+
+Include enough context with each example to show the pattern clearly, but keep examples concise and focused on architectural concepts." : ""}
+
+${INCLUDES_DECISION_RECORDS ? 
+"### 15. Architectural Decision Records
+Document key architectural decisions evident in the codebase:
+
+- **Architectural Style Decisions**:
+  - Why the current architectural pattern was chosen
+  - Alternatives considered (based on code evolution)
+  - Constraints that influenced the decision
+
+- **Technology Selection Decisions**:
+  - Key technology choices and their architectural impact
+  - Framework selection rationales
+  - Custom vs. off-the-shelf component decisions
+
+- **Implementation Approach Decisions**:
+  - Specific implementation patterns chosen
+  - Standard pattern adaptations
+  - Performance vs. maintainability tradeoffs
+
+For each decision, note:
+- Context that made the decision necessary
+- Factors considered in making the decision
+- Resulting consequences (positive and negative)
+- Future flexibility or limitations introduced" : ""}
+
+### ${INCLUDES_DECISION_RECORDS ? "16" : INCLUDES_CODE_EXAMPLES ? "15" : "14"}. Architecture Governance
+- Document how architectural consistency is maintained
+- Identify automated checks for architectural compliance
+- Note architectural review processes evident in the codebase
+- Document architectural documentation practices
+
+### ${INCLUDES_DECISION_RECORDS ? "17" : INCLUDES_CODE_EXAMPLES ? "16" : "15"}. Blueprint for New Development
+Create a clear architectural guide for implementing new features:
+
+- **Development Workflow**:
+  - Starting points for different feature types
+  - Component creation sequence
+  - Integration steps with existing architecture
+  - Testing approach by architectural layer
+
+- **Implementation Templates**:
+  - Base class/interface templates for key architectural components
+  - Standard file organization for new components
+  - Dependency declaration patterns
+  - Documentation requirements
+
+- **Common Pitfalls**:
+  - Architecture violations to avoid
+  - Common architectural mistakes
+  - Performance considerations
+  - Testing blind spots
+
+Include information about when this blueprint was generated and recommendations for keeping it updated as the architecture evolves."

package/.github/skills/create-implementation-plan/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: create-implementation-plan
+description: 'Create a new implementation plan file for new features, refactoring existing code or upgrading packages, design, architecture or infrastructure.'
+---
+
+# Create Implementation Plan
+
+## Primary Directive
+
+Your goal is to create a new implementation plan file for `${input:PlanPurpose}`. 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/.github/skills/create-specification/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: create-specification
+description: 'Create a new specification file for the solution, optimized for Generative AI consumption.'
+---
+
+# 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/](/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:
+
+```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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@abarcenas/ai-workflow-template",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "description": "A comprehensive template repository for AI-assisted development workflows using GitHub Copilot. This template provides a structured approach to leveraging AI assistance through pre-configured skills, prompts, agents, and coding standards.",
   "main": "index.js",
   "scripts": {

package/scripts/sync.js

@@ -9,6 +9,7 @@ const sourceGithubDir = resolve(packageRoot, '.github')
 const consumerRoot = process.env.INIT_CWD ? resolve(process.env.INIT_CWD) : process.cwd()
 const targetGithubDir = resolve(consumerRoot, '.github')
 const manifestPath = resolve(consumerRoot, '.github-sync-manifest.json')
+const excludedRelativePaths = new Set(['workflows/npm-publish.yml'])
 const args = new Set(process.argv.slice(2))
 const forceOverwrite = args.has('--force')
 const dryRun = args.has('--dry-run')
@@ -88,6 +89,10 @@ let added = 0
 
 for (const sourceFile of sourceFiles) {
   const relativePath = relative(sourceGithubDir, sourceFile)
+  if (excludedRelativePaths.has(relativePath)) {
+    continue
+  }
+
   const targetFile = resolve(targetGithubDir, relativePath)
   const sourceHash = hashFile(sourceFile)
   const existingHash = existsSync(targetFile) ? hashFile(targetFile) : null