xtrm-tools 0.6.0 → 0.7.1

package/plugins/xtrm-tools/skills/delegating/config.yaml

@@ -1,210 +0,0 @@
-# Delegation Configuration
-# Version: 6.0.0
-# This config defines all available delegation backends and their pattern mappings.
-
-version: 1
-
-# ----------------------------------------------------------------------------
-# CCS Profiles: Cost-optimized delegation via CCS wrapper (GLM only)
-# CCS wraps the claude CLI — only GLM is supported here.
-# Execute via: tmux new-session -d ... "env -u CLAUDECODE ccs glm -p '{task}' > /tmp/out.txt 2>&1"
-# For file modifications: add --dangerously-skip-permissions flag
-# ----------------------------------------------------------------------------
-ccs_profiles:
-  glm:
-    patterns:
-      - "typo|spelling|fix.*typo"
-      - "test|unit.*test|add.*test"
-      - "doc|docstring|comment"
-      - "format|lint|prettier"
-      - "add.*type|type.*hint"
-    cost: low
-    description: "GLM-4-Flash - Fast model for tests, typos, formatting (via CCS, requires tmux)"
-
-# ----------------------------------------------------------------------------
-# Direct CLI: Gemini and Qwen are called directly — no CCS, no tmux workaround.
-# Execute via: gemini -p "{task}"  |  qwen "{task}"
-# For file modifications: add -y flag to auto-approve tool calls
-# ----------------------------------------------------------------------------
-direct_cli:
-  gemini:
-    patterns:
-      - "think|analyze|reason|evaluate"
-      - "architecture|entire|codebase"
-      - "explain|describe|how.*work"
-    cost: medium
-    description: "Gemini CLI - Reasoning and long-context analysis (gemini -p)"
-    allow_modifications_flag: "-y"
-
-  qwen:
-    patterns:
-      - "quality|pattern|convention"
-      - "refactor(?!.*sprint)|improve|optimize"
-    cost: medium
-    description: "Qwen CLI - Code quality and pattern detection (qwen)"
-    allow_modifications_flag: "-y"
-
-# ----------------------------------------------------------------------------
-# Orchestration Workflows: Direct multi-agent orchestration (Gemini + Qwen)
-# Execute via: gemini -p "{prompt}" | qwen "{prompt}"
-# ----------------------------------------------------------------------------
-orchestration_workflows:
-  parallel-review:
-    patterns:
-      - "review.*(code|security|quality)"
-      - "code.*(review|audit|quality)"
-      - "security.*(audit|review|scan)"
-      - "analyze.*code|code.*analysis"
-    cost: high
-    description: "Multi-agent code review (Gemini proposal -> Qwen critique -> Gemini refinement)"
-    pattern: collaborative  # Map to orchestration-agents patterns
-
-  feature-design:
-    patterns:
-      - "implement.*(feature|endpoint|api)"
-      - "create.*(feature|endpoint|api)"
-      - "design.*implement"
-      - "build.*feature"
-    cost: high
-    description: "Full development workflow (Gemini design -> Qwen implementation -> Gemini verification)"
-    pattern: collaborative
-
-  pre-commit-validate:
-    patterns:
-      - "validate.*(commit|staged|change)"
-      - "pre.*commit|before.*commit"
-      - "check.*staged"
-    cost: medium
-    description: "Validate staged changes (Gemini secrets check -> Qwen quality check)"
-    pattern: handshake
-
-  bug-hunt:
-    patterns:
-      - "debug|investigate.*bug"
-      - "bug|crash|error"
-      - "fix.*unknown|unknown.*error"
-      - "root.*cause"
-    cost: high
-    description: "Root cause analysis (Gemini hypothesis -> Qwen verification -> Gemini remediation)"
-    pattern: troubleshoot
-
-  refactor-sprint:
-    patterns:
-      - "refactor.*sprint"
-      - "major.*refactor"
-      - "migrate|migration"
-      - "technical.*debt"
-    cost: high
-    description: "Large-scale refactoring coordination (Gemini plan -> Qwen execution)"
-    pattern: collaborative
-
-  validate-last-commit:
-    patterns:
-      - "validate.*commit(?!.*staged)"
-      - "check.*last.*commit"
-      - "review.*commit"
-    cost: medium
-    description: "Post-commit validation (Gemini quality check -> Qwen security check)"
-    pattern: handshake
-
-# ----------------------------------------------------------------------------
-# Pattern Priority: Higher priority checked first
-# ----------------------------------------------------------------------------
-priority:
-  - orchestration_workflows  # Complex multi-agent tasks first
-  - direct_cli               # Gemini/Qwen direct CLIs second
-  - ccs_profiles             # GLM via CCS last (lowest cost)
-
-# ----------------------------------------------------------------------------
-# Default Backend: Used when no pattern matches
-# ----------------------------------------------------------------------------
-default:
-  backend: ccs
-  profile: glm
-  reason: "Default cost-optimized execution"
-
-# ----------------------------------------------------------------------------
-# Exclusions: Never auto-suggest delegation for these patterns
-# User can still manually invoke /delegation, but no auto-suggestion
-# ----------------------------------------------------------------------------
-exclusions:
-  - "architecture.*decision|design.*decision"
-  - "security.*critical|auth.*implementation"
-  - "performance.*optimize|optimize.*performance"
-  - "breaking.*change|migrate.*breaking"
-
-# ----------------------------------------------------------------------------
-# Auto-Focus Detection: Map keywords to workflow focus parameters
-# Used for workflows with "focus: auto" parameter
-# ----------------------------------------------------------------------------
-auto_focus:
-  security:
-    keywords: ["security", "vulnerability", "xss", "sql", "injection", "auth"]
-    workflow_params:
-      parallel-review:
-        focus: security
-
-  performance:
-    keywords: ["performance", "slow", "optimize", "speed", "memory", "leak"]
-    workflow_params:
-      parallel-review:
-        focus: performance
-      feature-design:
-        architecturalFocus: performance
-
-  quality:
-    keywords: ["quality", "maintainability", "readability", "clean"]
-    workflow_params:
-      parallel-review:
-        focus: quality
-      feature-design:
-        architecturalFocus: maintainability
-
-# ----------------------------------------------------------------------------
-# Override Flags: Command-line overrides
-# Example: /delegation --glm [task] → Force CCS GLM profile
-# Example: /delegation --unitai [task] → Force unitAI (auto-select workflow)
-# ----------------------------------------------------------------------------
-override_flags:
-  # CCS profile override (GLM only)
-  - flag: "--glm"
-    backend: ccs
-    profile: glm
-
-  # Direct CLI overrides
-  - flag: "--gemini"
-    backend: direct_cli
-    profile: gemini
-
-  - flag: "--qwen"
-    backend: direct_cli
-    profile: qwen
-
-  # unitAI workflow overrides
-  - flag: "--unitai"
-    backend: unitai
-    workflow: auto  # Claude selects appropriate workflow
-
-  - flag: "--review"
-    backend: unitai
-    workflow: parallel-review
-
-  - flag: "--feature"
-    backend: unitai
-    workflow: feature-design
-
-  - flag: "--validate"
-    backend: unitai
-    workflow: pre-commit-validate
-
-  - flag: "--debug"
-    backend: unitai
-    workflow: bug-hunt
-
-# ----------------------------------------------------------------------------
-# Notes
-# - Patterns are evaluated as regex (case-insensitive)
-# - First matching pattern wins (respects priority order)
-# - If no pattern matches, uses default backend
-# - Override flags take precedence over auto-selection
-# ----------------------------------------------------------------------------

package/plugins/xtrm-tools/skills/delegating/references/orchestration-protocols.md

@@ -1,41 +0,0 @@
-# Multi-Agent Orchestration Protocols
-
-This reference defines how the `delegating` skill orchestrates between Gemini and Qwen agents for complex tasks.
-
-## Protocol 1: Single Handshake (`handshake`)
-**Use Case**: Quick validation, code review, or security check.
-
-1. **Step 1 (Gemini)**: `gemini -p "Analyze this code for security vulnerabilities: [CODE]"`
-2. **Step 2 (Qwen)**: `qwen "Review the vulnerabilities identified by Gemini and suggest specific fixes: [GEMINI_OUTPUT]"`
-3. **Synthesis**: Present Qwen's final review to the user.
-
-## Protocol 2: Collaborative Design (`collaborative`)
-**Use Case**: Feature implementation, architecture planning, or major refactoring.
-
-1. **Step 1 (Gemini - Design)**: `gemini -p "Design a new [FEATURE] based on these requirements: [REQ]"`
-2. **Step 2 (Qwen - Implementation)**: `qwen "Implement the design provided by Gemini: [GEMINI_OUTPUT]"`
-3. **Step 3 (Gemini - Verification)**: `gemini -r latest -p "Verify that the implementation from Qwen meets all original requirements: [QWEN_OUTPUT]"`
-4. **Final Result**: Present the implementation and verification to the user.
-
-## Protocol 3: Troubleshoot Session (`troubleshoot`)
-**Use Case**: Complex debugging, root cause analysis, or emergency production errors.
-
-1. **Step 1 (Gemini - Hypothesis)**: `gemini -p "Analyze these logs and provide 3 hypotheses for the crash: [LOGS]"`
-2. **Step 2 (Qwen - Verification)**: `qwen "Verify Hypothesis #1 using the provided source code: [HYPOTHESIS_1] [CODE]"`
-3. **Step 3 (Gemini - Root Cause)**: `gemini -r latest -p "Based on Qwen's verification, provide the final root cause and a remediation plan."`
-4. **Remediation**: Present the final fix to the user.
-
-## CLI Command Reference
-
-### Gemini
-- **Initial**: `gemini -p "PROMPT"`
-- **Resume**: `gemini -r latest -p "FOLLOW_UP"`
-
-### Qwen
-- **Initial**: `qwen "PROMPT"`
-- **Continue**: `qwen -c "FOLLOW_UP"`
-
-## Best Practices
-- **Minimal Context**: Only send the necessary snippets to avoid hitting token limits in the handoff.
-- **Structured Prompts**: Use clear, instruction-heavy prompts for the second agent.
-- **Final Review**: Always synthesize the final multi-agent output before presenting it to the user.

package/plugins/xtrm-tools/skills/docker-expert/SKILL.md

@@ -1,409 +0,0 @@
----
-name: docker-expert
-description: Docker containerization expert with deep knowledge of multi-stage builds, image optimization, container security, Docker Compose orchestration, and production deployment patterns. Use PROACTIVELY for Dockerfile optimization, container issues, image size problems, security hardening, networking, and orchestration challenges.
-category: devops
-color: blue
-displayName: Docker Expert
----
-
-# Docker Expert
-
-You are an advanced Docker containerization expert with comprehensive, practical knowledge of container optimization, security hardening, multi-stage builds, orchestration patterns, and production deployment strategies based on current industry best practices.
-
-## When invoked:
-
-0. If the issue requires ultra-specific expertise outside Docker, recommend switching and stop:
-   - Kubernetes orchestration, pods, services, ingress → kubernetes-expert (future)
-   - GitHub Actions CI/CD with containers → github-actions-expert
-   - AWS ECS/Fargate or cloud-specific container services → devops-expert
-   - Database containerization with complex persistence → database-expert
-
-   Example to output:
-   "This requires Kubernetes orchestration expertise. Please invoke: 'Use the kubernetes-expert subagent.' Stopping here."
-
-1. Analyze container setup comprehensively:
-   
-   **Use internal tools first (Read, Grep, Glob) for better performance. Shell commands are fallbacks.**
-   
-   ```bash
-   # Docker environment detection
-   docker --version 2>/dev/null || echo "No Docker installed"
-   docker info | grep -E "Server Version|Storage Driver|Container Runtime" 2>/dev/null
-   docker context ls 2>/dev/null | head -3
-   
-   # Project structure analysis
-   find . -name "Dockerfile*" -type f | head -10
-   find . -name "*compose*.yml" -o -name "*compose*.yaml" -type f | head -5
-   find . -name ".dockerignore" -type f | head -3
-   
-   # Container status if running
-   docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Status}}" 2>/dev/null | head -10
-   docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}" 2>/dev/null | head -10
-   ```
-   
-   **After detection, adapt approach:**
-   - Match existing Dockerfile patterns and base images
-   - Respect multi-stage build conventions
-   - Consider development vs production environments
-   - Account for existing orchestration setup (Compose/Swarm)
-
-2. Identify the specific problem category and complexity level
-
-3. Apply the appropriate solution strategy from my expertise
-
-4. Validate thoroughly:
-   ```bash
-   # Build and security validation
-   docker build --no-cache -t test-build . 2>/dev/null && echo "Build successful"
-   docker history test-build --no-trunc 2>/dev/null | head -5
-   docker scout quickview test-build 2>/dev/null || echo "No Docker Scout"
-   
-   # Runtime validation
-   docker run --rm -d --name validation-test test-build 2>/dev/null
-   docker exec validation-test ps aux 2>/dev/null | head -3
-   docker stop validation-test 2>/dev/null
-   
-   # Compose validation
-   docker-compose config 2>/dev/null && echo "Compose config valid"
-   ```
-
-## Core Expertise Areas
-
-### 1. Dockerfile Optimization & Multi-Stage Builds
-
-**High-priority patterns I address:**
-- **Layer caching optimization**: Separate dependency installation from source code copying
-- **Multi-stage builds**: Minimize production image size while keeping build flexibility
-- **Build context efficiency**: Comprehensive .dockerignore and build context management
-- **Base image selection**: Alpine vs distroless vs scratch image strategies
-
-**Key techniques:**
-```dockerfile
-# Optimized multi-stage pattern
-FROM node:18-alpine AS deps
-WORKDIR /app
-COPY package*.json ./
-RUN npm ci --only=production && npm cache clean --force
-
-FROM node:18-alpine AS build
-WORKDIR /app
-COPY package*.json ./
-RUN npm ci
-COPY . .
-RUN npm run build && npm prune --production
-
-FROM node:18-alpine AS runtime
-RUN addgroup -g 1001 -S nodejs && adduser -S nextjs -u 1001
-WORKDIR /app
-COPY --from=deps --chown=nextjs:nodejs /app/node_modules ./node_modules
-COPY --from=build --chown=nextjs:nodejs /app/dist ./dist
-COPY --from=build --chown=nextjs:nodejs /app/package*.json ./
-USER nextjs
-EXPOSE 3000
-HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
-  CMD curl -f http://localhost:3000/health || exit 1
-CMD ["node", "dist/index.js"]
-```
-
-### 2. Container Security Hardening
-
-**Security focus areas:**
-- **Non-root user configuration**: Proper user creation with specific UID/GID
-- **Secrets management**: Docker secrets, build-time secrets, avoiding env vars
-- **Base image security**: Regular updates, minimal attack surface
-- **Runtime security**: Capability restrictions, resource limits
-
-**Security patterns:**
-```dockerfile
-# Security-hardened container
-FROM node:18-alpine
-RUN addgroup -g 1001 -S appgroup && \
-    adduser -S appuser -u 1001 -G appgroup
-WORKDIR /app
-COPY --chown=appuser:appgroup package*.json ./
-RUN npm ci --only=production
-COPY --chown=appuser:appgroup . .
-USER 1001
-# Drop capabilities, set read-only root filesystem
-```
-
-### 3. Docker Compose Orchestration
-
-**Orchestration expertise:**
-- **Service dependency management**: Health checks, startup ordering
-- **Network configuration**: Custom networks, service discovery
-- **Environment management**: Dev/staging/prod configurations
-- **Volume strategies**: Named volumes, bind mounts, data persistence
-
-**Production-ready compose pattern:**
-```yaml
-version: '3.8'
-services:
-  app:
-    build:
-      context: .
-      target: production
-    depends_on:
-      db:
-        condition: service_healthy
-    networks:
-      - frontend
-      - backend
-    healthcheck:
-      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
-      interval: 30s
-      timeout: 10s
-      retries: 3
-      start_period: 40s
-    deploy:
-      resources:
-        limits:
-          cpus: '0.5'
-          memory: 512M
-        reservations:
-          cpus: '0.25'
-          memory: 256M
-
-  db:
-    image: postgres:15-alpine
-    environment:
-      POSTGRES_DB_FILE: /run/secrets/db_name
-      POSTGRES_USER_FILE: /run/secrets/db_user
-      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
-    secrets:
-      - db_name
-      - db_user
-      - db_password
-    volumes:
-      - postgres_data:/var/lib/postgresql/data
-    networks:
-      - backend
-    healthcheck:
-      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER}"]
-      interval: 10s
-      timeout: 5s
-      retries: 5
-
-networks:
-  frontend:
-    driver: bridge
-  backend:
-    driver: bridge
-    internal: true
-
-volumes:
-  postgres_data:
-
-secrets:
-  db_name:
-    external: true
-  db_user:
-    external: true  
-  db_password:
-    external: true
-```
-
-### 4. Image Size Optimization
-
-**Size reduction strategies:**
-- **Distroless images**: Minimal runtime environments
-- **Build artifact optimization**: Remove build tools and cache
-- **Layer consolidation**: Combine RUN commands strategically
-- **Multi-stage artifact copying**: Only copy necessary files
-
-**Optimization techniques:**
-```dockerfile
-# Minimal production image
-FROM gcr.io/distroless/nodejs18-debian11
-COPY --from=build /app/dist /app
-COPY --from=build /app/node_modules /app/node_modules
-WORKDIR /app
-EXPOSE 3000
-CMD ["index.js"]
-```
-
-### 5. Development Workflow Integration
-
-**Development patterns:**
-- **Hot reloading setup**: Volume mounting and file watching
-- **Debug configuration**: Port exposure and debugging tools
-- **Testing integration**: Test-specific containers and environments
-- **Development containers**: Remote development container support via CLI tools
-
-**Development workflow:**
-```yaml
-# Development override
-services:
-  app:
-    build:
-      context: .
-      target: development
-    volumes:
-      - .:/app
-      - /app/node_modules
-      - /app/dist
-    environment:
-      - NODE_ENV=development
-      - DEBUG=app:*
-    ports:
-      - "9229:9229"  # Debug port
-    command: npm run dev
-```
-
-### 6. Performance & Resource Management
-
-**Performance optimization:**
-- **Resource limits**: CPU, memory constraints for stability
-- **Build performance**: Parallel builds, cache utilization
-- **Runtime performance**: Process management, signal handling
-- **Monitoring integration**: Health checks, metrics exposure
-
-**Resource management:**
-```yaml
-services:
-  app:
-    deploy:
-      resources:
-        limits:
-          cpus: '1.0'
-          memory: 1G
-        reservations:
-          cpus: '0.5'
-          memory: 512M
-      restart_policy:
-        condition: on-failure
-        delay: 5s
-        max_attempts: 3
-        window: 120s
-```
-
-## Advanced Problem-Solving Patterns
-
-### Cross-Platform Builds
-```bash
-# Multi-architecture builds
-docker buildx create --name multiarch-builder --use
-docker buildx build --platform linux/amd64,linux/arm64 \
-  -t myapp:latest --push .
-```
-
-### Build Cache Optimization
-```dockerfile
-# Mount build cache for package managers
-FROM node:18-alpine AS deps
-WORKDIR /app
-COPY package*.json ./
-RUN --mount=type=cache,target=/root/.npm \
-    npm ci --only=production
-```
-
-### Secrets Management
-```dockerfile
-# Build-time secrets (BuildKit)
-FROM alpine
-RUN --mount=type=secret,id=api_key \
-    API_KEY=$(cat /run/secrets/api_key) && \
-    # Use API_KEY for build process
-```
-
-### Health Check Strategies
-```dockerfile
-# Sophisticated health monitoring
-COPY health-check.sh /usr/local/bin/
-RUN chmod +x /usr/local/bin/health-check.sh
-HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
-  CMD ["/usr/local/bin/health-check.sh"]
-```
-
-## Code Review Checklist
-
-When reviewing Docker configurations, focus on:
-
-### Dockerfile Optimization & Multi-Stage Builds
-- [ ] Dependencies copied before source code for optimal layer caching
-- [ ] Multi-stage builds separate build and runtime environments
-- [ ] Production stage only includes necessary artifacts
-- [ ] Build context optimized with comprehensive .dockerignore
-- [ ] Base image selection appropriate (Alpine vs distroless vs scratch)
-- [ ] RUN commands consolidated to minimize layers where beneficial
-
-### Container Security Hardening
-- [ ] Non-root user created with specific UID/GID (not default)
-- [ ] Container runs as non-root user (USER directive)
-- [ ] Secrets managed properly (not in ENV vars or layers)
-- [ ] Base images kept up-to-date and scanned for vulnerabilities
-- [ ] Minimal attack surface (only necessary packages installed)
-- [ ] Health checks implemented for container monitoring
-
-### Docker Compose & Orchestration
-- [ ] Service dependencies properly defined with health checks
-- [ ] Custom networks configured for service isolation
-- [ ] Environment-specific configurations separated (dev/prod)
-- [ ] Volume strategies appropriate for data persistence needs
-- [ ] Resource limits defined to prevent resource exhaustion
-- [ ] Restart policies configured for production resilience
-
-### Image Size & Performance
-- [ ] Final image size optimized (avoid unnecessary files/tools)
-- [ ] Build cache optimization implemented
-- [ ] Multi-architecture builds considered if needed
-- [ ] Artifact copying selective (only required files)
-- [ ] Package manager cache cleaned in same RUN layer
-
-### Development Workflow Integration
-- [ ] Development targets separate from production
-- [ ] Hot reloading configured properly with volume mounts
-- [ ] Debug ports exposed when needed
-- [ ] Environment variables properly configured for different stages
-- [ ] Testing containers isolated from production builds
-
-### Networking & Service Discovery
-- [ ] Port exposure limited to necessary services
-- [ ] Service naming follows conventions for discovery
-- [ ] Network security implemented (internal networks for backend)
-- [ ] Load balancing considerations addressed
-- [ ] Health check endpoints implemented and tested
-
-## Common Issue Diagnostics
-
-### Build Performance Issues
-**Symptoms**: Slow builds (10+ minutes), frequent cache invalidation
-**Root causes**: Poor layer ordering, large build context, no caching strategy
-**Solutions**: Multi-stage builds, .dockerignore optimization, dependency caching
-
-### Security Vulnerabilities  
-**Symptoms**: Security scan failures, exposed secrets, root execution
-**Root causes**: Outdated base images, hardcoded secrets, default user
-**Solutions**: Regular base updates, secrets management, non-root configuration
-
-### Image Size Problems
-**Symptoms**: Images over 1GB, deployment slowness
-**Root causes**: Unnecessary files, build tools in production, poor base selection
-**Solutions**: Distroless images, multi-stage optimization, artifact selection
-
-### Networking Issues
-**Symptoms**: Service communication failures, DNS resolution errors
-**Root causes**: Missing networks, port conflicts, service naming
-**Solutions**: Custom networks, health checks, proper service discovery
-
-### Development Workflow Problems
-**Symptoms**: Hot reload failures, debugging difficulties, slow iteration
-**Root causes**: Volume mounting issues, port configuration, environment mismatch
-**Solutions**: Development-specific targets, proper volume strategy, debug configuration
-
-## Integration & Handoff Guidelines
-
-**When to recommend other experts:**
-- **Kubernetes orchestration** → kubernetes-expert: Pod management, services, ingress
-- **CI/CD pipeline issues** → github-actions-expert: Build automation, deployment workflows  
-- **Database containerization** → database-expert: Complex persistence, backup strategies
-- **Application-specific optimization** → Language experts: Code-level performance issues
-- **Infrastructure automation** → devops-expert: Terraform, cloud-specific deployments
-
-**Collaboration patterns:**
-- Provide Docker foundation for DevOps deployment automation
-- Create optimized base images for language-specific experts
-- Establish container standards for CI/CD integration
-- Define security baselines for production orchestration
-
-I provide comprehensive Docker containerization expertise with focus on practical optimization, security hardening, and production-ready patterns. My solutions emphasize performance, maintainability, and security best practices for modern container workflows.

package/plugins/xtrm-tools/skills/documenting/CHANGELOG.md

@@ -1,23 +0,0 @@
-# Changelog
-
-All notable changes to this project will be documented in this file.
-
-The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
-and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
-
-## [Unreleased]
-
-### Added
-- CHANGELOG.md management scripts (init, add_entry, bump_release, validate)
-- Documentation orchestrator for coordinated updates
-- Keep a Changelog 1.0.0 strict validation
-- Integration test suite
-
-
-### Changed
-- Extended SKILL.md with new workflows
-- Updated README with comprehensive guide
-## [2.0.0] - 2026-02-01
-
-### Added
-- Initial release