npm - aigroup-workflow - Versions diffs - 2.1.2 → 2.2.0 - Mend

aigroup-workflow 2.1.2 → 2.2.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (913) hide show

package/skills/cli-developer/references/ux-patterns.md DELETED Viewed

@@ -1,448 +0,0 @@
-# CLI UX Patterns
-## Progress Indicators
-### When to Use What
-```
-Determinate (known total):
-  [████████████░░░░░░░░] 60% (3/5 files)
-  Use: File operations, downloads, batch processing
-Indeterminate (unknown duration):
-  ⠋ Loading...
-  Use: API calls, database queries, waiting for external services
-Multi-step:
-  ✓ Dependencies installed
-  ⠋ Building application...
-  ⏳ Running tests...
-  Use: Multi-phase operations (build, deploy, etc.)
-```
-### Progress Bar Best Practices
-```
-Good:
-[████████████░░░░░░░░] 60% | 120/200 MB | 2.4 MB/s | ETA: 33s
-↑ Visual     ↑ Percent  ↑ Progress  ↑ Rate     ↑ Time
-Components:
-- Visual bar (20-40 chars)
-- Percentage (when known)
-- Current/total (with units)
-- Speed/rate (when applicable)
-- ETA (estimated time remaining)
-Bad:
-Processing... (no feedback)
-60% (no context)
-[████████████████████████████████████████] (too wide)
-```
-### Spinner Styles
-```
-⠋ ⠙ ⠹ ⠸ ⠼ ⠴ ⠦ ⠧ ⠇ ⠏   Dots (elegant, low-key)
-⣾ ⣽ ⣻ ⢿ ⡿ ⣟ ⣯ ⣷        Blocks (bold, attention)
-◐ ◓ ◑ ◒                  Circle (classic)
-▖ ▘ ▝ ▗                  Corners (minimal)
-⠁ ⠂ ⠄ ⡀ ⢀ ⠠ ⠐ ⠈        Line (subtle)
-Choose based on:
-- Terminal compatibility (stick to ASCII for Windows)
-- Branding (match your tool's personality)
-- Context (subtle for background, bold for main task)
-```
-## Color Usage
-### Semantic Colors
-```
-Red:     Errors, failures, destructive actions
-Yellow:  Warnings, deprecations, non-critical issues
-Green:   Success, completion, positive feedback
-Blue:    Information, hints, neutral messages
-Cyan:    Commands, code, technical details
-Magenta: Highlights, special items
-Gray:    Less important, metadata, timestamps
-Examples:
-✓ Success: Deployment complete
-✗ Error: File not found
-⚠ Warning: Deprecated flag --old-flag
-ℹ Info: Using cache from ~/.mycli/cache
-```
-### When to Disable Colors
-```javascript
-// Detect non-TTY output (piped to file, etc.)
-const noColor = !process.stdout.isTTY ||
-                process.env.NO_COLOR ||
-                process.env.CI === 'true';
-if (noColor) {
-  // Disable colors
-}
-// Support NO_COLOR standard
-// https://no-color.org/
-```
-### Color Accessibility
-```
-- Don't rely on color alone (use symbols too)
-- Provide high contrast (test with various terminals)
-- Support color blindness (red/green alternatives)
-Good:
-✓ Build successful (green)
-✗ Build failed (red)
-↑ Symbols work without color
-Bad:
-Success (only color, no symbol)
-Failed (only color, no symbol)
-```
-## Help Text Design
-### Command Help Structure
-```
-USAGE
-  mycli <command> [options]
-COMMANDS
-  init         Initialize a new project
-  deploy       Deploy to environment
-  config       Manage configuration
-  plugins      Manage plugins
-OPTIONS
-  -h, --help     Show help
-  -v, --version  Show version
-  --config FILE  Config file path
-Run 'mycli <command> --help' for more information on a command.
-EXAMPLES
-  # Initialize a new project
-  mycli init my-app
-  # Deploy to production
-  mycli deploy production --dry-run
-Learn more: https://docs.mycli.dev
-```
-### Subcommand Help
-```
-USAGE
-  mycli deploy <environment> [options]
-ARGUMENTS
-  environment    Target environment (required)
-                 Values: development, staging, production
-OPTIONS
-  -c, --config <file>    Config file path
-                         Default: ./mycli.config.yml
-  -f, --force            Skip confirmation prompts
-                         Use with caution in production
-  -d, --dry-run          Preview changes without executing
-                         Shows what would happen
-  -v, --verbose          Show detailed output
-                         Includes debug information
-EXAMPLES
-  # Deploy to production (with confirmation)
-  mycli deploy production
-  # Preview staging deployment
-  mycli deploy staging --dry-run
-  # Use custom config
-  mycli deploy production --config ./prod.yml
-  # Force deploy without prompts
-  mycli deploy production --force
-For more information, visit https://docs.mycli.dev/deploy
-```
-## Error Messages
-### Good Error Messages
-```
-Pattern: [Context] → [Problem] → [Solution]
-Example 1: File not found
-✗ Error: Config file not found
-Searched locations:
-  • ./mycli.config.yml
-  • ~/.config/mycli/config.yml
-  • /etc/mycli/config.yml
-Solutions:
-  • Run 'mycli init' to create a config file
-  • Use --config to specify a different location
-  • Check file permissions
-Example 2: Validation error
-✗ Error: Invalid environment 'prod'
-Expected one of:
-  • development
-  • staging
-  • production
-Did you mean 'production'?
-Example 3: Permission error
-✗ Error: Permission denied writing to /etc/mycli/config.yml
-This operation requires elevated permissions.
-Try:
-  • Run with sudo: sudo mycli config set key value
-  • Use user config: mycli config set --user key value
-  • Check file permissions: ls -la /etc/mycli/config.yml
-```
-### Error Message Guidelines
-```
-DO:
-✓ Be specific ("Port 3000 already in use" not "Port unavailable")
-✓ Show context ("in file config.yml, line 42")
-✓ Suggest solutions ("Try running 'mycli fix'")
-✓ Use plain language ("File not found" not "ENOENT")
-DON'T:
-✗ Show stack traces to users (save for --debug)
-✗ Use jargon ("EACCES: permission denied")
-✗ Leave users stuck ("Invalid input" with no explanation)
-✗ Be vague ("Something went wrong")
-```
-## Interactive Prompts
-### Prompt Types
-```
-Text Input:
-  Project name: my-awesome-app
-  ↑ Clear label
-Select (Single Choice):
-  ? Select environment: (Use arrow keys)
-  ❯ development
-    staging
-    production
-Checkbox (Multiple Choice):
-  ? Select features: (Press space to select, enter to confirm)
-  ◉ TypeScript
-  ◯ ESLint
-  ◉ Prettier
-  ◯ Jest
-Confirmation:
-  ? Deploy to production? (y/N)
-  ↑ Default is No (safer)
-Password:
-  ? Enter password: ********
-  ↑ Masked input
-```
-### Prompt Guidelines
-```
-DO:
-✓ Show keyboard hints ("Use arrow keys", "Press space")
-✓ Provide sensible defaults (pre-select common choices)
-✓ Allow skipping with Ctrl+C
-✓ Validate input immediately
-✓ Show preview/summary before final action
-DON'T:
-✗ Require interaction in CI/CD environments
-✗ Ask obvious questions (confirm every action)
-✗ Hide what will happen next
-✗ Make users repeat information
-```
-## Output Formatting
-### Tables
-```
-Good:
-┌─────────────┬──────────┬──────────┐
-│ Environment │ Status   │ Updated  │
-├─────────────┼──────────┼──────────┤
-│ production  │ ✓ Active │ 2h ago   │
-│ staging     │ ✓ Active │ 5m ago   │
-│ development │ ✗ Down   │ 1d ago   │
-└─────────────┴──────────┴──────────┘
-Minimal (for scripting):
-Environment  Status  Updated
-production   Active  2h ago
-staging      Active  5m ago
-development  Down    1d ago
-JSON (for programmatic use):
-[
-  {"env": "production", "status": "active", "updated": "2h ago"},
-  {"env": "staging", "status": "active", "updated": "5m ago"}
-]
-```
-### Lists
-```
-Bulleted:
-Features:
-  • TypeScript support
-  • Hot reload
-  • Auto-formatting
-Numbered:
-Steps to deploy:
-  1. Build application
-  2. Run tests
-  3. Deploy to server
-  4. Verify deployment
-Tree:
-my-app/
-├── src/
-│   ├── components/
-│   └── utils/
-├── tests/
-└── package.json
-```
-## Status Messages
-### Real-time Updates
-```
-Multi-step process:
-✓ Dependencies installed (2.3s)
-✓ Application built (8.1s)
-⠋ Running tests... (current)
-⏳ Deploying... (pending)
-⏳ Verifying... (pending)
-Updates:
-⠋ Installing dependencies...
-  → npm install
-✓ Dependencies installed (2.3s)
-⠋ Building application...
-  → webpack build
-✓ Application built (8.1s)
-  → Output: dist/ (2.4 MB)
-```
-### Summary/Completion
-```
-✓ Deployment complete!
-Summary:
-  Environment:  production
-  Version:      v1.2.3
-  Duration:     2m 34s
-  Deployed:     2023-12-14 10:30:45 UTC
-Next steps:
-  • View logs: mycli logs production
-  • Monitor:   mycli status production
-  • Rollback:  mycli rollback production
-URL: https://app.example.com
-```
-## Debugging & Verbose Mode
-```
-Normal mode (default):
-✓ Deployed to production (2m 34s)
-Verbose mode (--verbose):
-[10:30:12] Starting deployment...
-[10:30:13] Loading config from ./mycli.config.yml
-[10:30:14] Connecting to production server...
-[10:30:15] Uploading files (124 files, 2.4 MB)...
-[10:30:28] Running post-deploy hooks...
-[10:32:46] ✓ Deployment complete
-Debug mode (--debug):
-[DEBUG] Config loaded: {env: 'production', ...}
-[DEBUG] SSH connection established: user@host
-[DEBUG] Executing: rsync -avz ./dist/ user@host:/var/www/
-[DEBUG] Output: sending incremental file list...
-[DEBUG] Exit code: 0
-✓ Deployed to production (2m 34s)
-Usage:
-# Normal: concise output
-mycli deploy production
-# Verbose: detailed steps
-mycli deploy production --verbose
-# Debug: everything including internals
-DEBUG=* mycli deploy production
-```
-## Man Page Format
-```
-NAME
-    mycli-deploy - Deploy application to environment
-SYNOPSIS
-    mycli deploy <environment> [options]
-DESCRIPTION
-    Deploy your application to the specified environment.
-    Supports development, staging, and production environments.
-OPTIONS
-    -c, --config <file>
-        Path to configuration file
-        Default: ./mycli.config.yml
-    -f, --force
-        Skip all confirmation prompts
-        Use with caution in production
-    -d, --dry-run
-        Preview deployment without executing
-        Shows what would be deployed
-EXAMPLES
-    Deploy to production:
-        mycli deploy production
-    Preview staging deployment:
-        mycli deploy staging --dry-run
-SEE ALSO
-    mycli-init(1), mycli-config(1), mycli-rollback(1)
-```

package/skills/cloud-architect/SKILL.md DELETED Viewed

@@ -1,216 +0,0 @@
----
-name: cloud-architect
-description: Designs cloud architectures, creates migration plans, generates cost optimization recommendations, and produces disaster recovery strategies across AWS, Azure, and GCP. Use when designing cloud architectures, planning migrations, or optimizing multi-cloud deployments. Invoke for Well-Architected Framework, cost optimization, disaster recovery, landing zones, security architecture, serverless design.
-license: MIT
-metadata:
-  author: https://github.com/Jeffallan
-  version: "1.1.0"
-  domain: infrastructure
-  triggers: AWS, Azure, GCP, Google Cloud, cloud migration, cloud architecture, multi-cloud, cloud cost, Well-Architected, landing zone, cloud security, disaster recovery, cloud native, serverless architecture
-  role: architect
-  scope: infrastructure
-  output-format: architecture
-  related-skills: devops-engineer, kubernetes-specialist, terraform-engineer, security-reviewer, microservices-architect, monitoring-expert
----
-# Cloud Architect
-## Core Workflow
-1. **Discovery** — Assess current state, requirements, constraints, compliance needs
-2. **Design** — Select services, design topology, plan data architecture
-3. **Security** — Implement zero-trust, identity federation, encryption
-4. **Cost Model** — Right-size resources, reserved capacity, auto-scaling
-5. **Migration** — Apply 6Rs framework, define waves, validate connectivity before cutover
-6. **Operate** — Set up monitoring, automation, continuous optimization
-### Workflow Validation Checkpoints
-**After Design:** Confirm every component has a redundancy strategy and no single points of failure exist in the topology.
-**Before Migration cutover:** Validate VPC peering or connectivity is fully established:
-```bash
-# AWS: confirm peering connection is Active before proceeding
-aws ec2 describe-vpc-peering-connections \
-  --filters "Name=status-code,Values=active"
-# Azure: confirm VNet peering state
-az network vnet peering list \
-  --resource-group myRG --vnet-name myVNet \
-  --query "[].{Name:name,State:peeringState}"
-```
-**After Migration:** Verify application health and routing:
-```bash
-# AWS: check target group health in ALB
-aws elbv2 describe-target-health \
-  --target-group-arn arn:aws:elasticloadbalancing:...
-```
-**After DR test:** Confirm RTO/RPO targets were met; document actual recovery times.
-## Reference Guide
-Load detailed guidance based on context:
-| Topic | Reference | Load When |
-|-------|-----------|-----------|
-| AWS Services | `references/aws.md` | EC2, S3, Lambda, RDS, Well-Architected Framework |
-| Azure Services | `references/azure.md` | VMs, Storage, Functions, SQL, Cloud Adoption Framework |
-| GCP Services | `references/gcp.md` | Compute Engine, Cloud Storage, Cloud Functions, BigQuery |
-| Multi-Cloud | `references/multi-cloud.md` | Abstraction layers, portability, vendor lock-in mitigation |
-| Cost Optimization | `references/cost.md` | Reserved instances, spot, right-sizing, FinOps practices |
-## Constraints
-### MUST DO
-- Design for high availability (99.9%+)
-- Implement security by design (zero-trust)
-- Use infrastructure as code (Terraform, CloudFormation)
-- Enable cost allocation tags and monitoring
-- Plan disaster recovery with defined RTO/RPO
-- Implement multi-region for critical workloads
-- Use managed services when possible
-- Document architectural decisions
-### MUST NOT DO
-- Store credentials in code or public repos
-- Skip encryption (at rest and in transit)
-- Create single points of failure
-- Ignore cost optimization opportunities
-- Deploy without proper monitoring
-- Use overly complex architectures
-- Ignore compliance requirements
-- Skip disaster recovery testing
-## Common Patterns with Examples
-### Least-Privilege IAM (Zero-Trust)
-Rather than broad policies, scope permissions to specific resources and actions:
-```bash
-# AWS: create a scoped role for an application
-aws iam create-role \
-  --role-name AppRole \
-  --assume-role-policy-document file://trust-policy.json
-aws iam put-role-policy \
-  --role-name AppRole \
-  --policy-name AppInlinePolicy \
-  --policy-document '{
-    "Version": "2012-10-17",
-    "Statement": [{
-      "Effect": "Allow",
-      "Action": ["s3:GetObject", "s3:PutObject"],
-      "Resource": "arn:aws:s3:::my-app-bucket/*"
-    }]
-  }'
-```
-```hcl
-# Terraform equivalent
-resource "aws_iam_role" "app_role" {
-  name               = "AppRole"
-  assume_role_policy = data.aws_iam_policy_document.trust.json
-}
-resource "aws_iam_role_policy" "app_policy" {
-  role = aws_iam_role.app_role.id
-  policy = jsonencode({
-    Version = "2012-10-17"
-    Statement = [{
-      Effect   = "Allow"
-      Action   = ["s3:GetObject", "s3:PutObject"]
-      Resource = "${aws_s3_bucket.app.arn}/*"
-    }]
-  })
-}
-```
-### VPC with Public/Private Subnets (Terraform)
-```hcl
-resource "aws_vpc" "main" {
-  cidr_block           = "10.0.0.0/16"
-  enable_dns_hostnames = true
-  tags = { Name = "main", CostCenter = var.cost_center }
-}
-resource "aws_subnet" "private" {
-  count             = 2
-  vpc_id            = aws_vpc.main.id
-  cidr_block        = cidrsubnet("10.0.0.0/16", 8, count.index)
-  availability_zone = data.aws_availability_zones.available.names[count.index]
-}
-resource "aws_subnet" "public" {
-  count                   = 2
-  vpc_id                  = aws_vpc.main.id
-  cidr_block              = cidrsubnet("10.0.0.0/16", 8, count.index + 10)
-  availability_zone       = data.aws_availability_zones.available.names[count.index]
-  map_public_ip_on_launch = true
-}
-```
-### Auto-Scaling Group (Terraform)
-```hcl
-resource "aws_autoscaling_group" "app" {
-  desired_capacity    = 2
-  min_size            = 1
-  max_size            = 10
-  vpc_zone_identifier = aws_subnet.private[*].id
-  launch_template {
-    id      = aws_launch_template.app.id
-    version = "$Latest"
-  }
-  tag {
-    key                 = "CostCenter"
-    value               = var.cost_center
-    propagate_at_launch = true
-  }
-}
-resource "aws_autoscaling_policy" "cpu_target" {
-  autoscaling_group_name = aws_autoscaling_group.app.name
-  policy_type            = "TargetTrackingScaling"
-  target_tracking_configuration {
-    predefined_metric_specification {
-      predefined_metric_type = "ASGAverageCPUUtilization"
-    }
-    target_value = 60.0
-  }
-}
-```
-### Cost Analysis CLI
-```bash
-# AWS: identify top cost drivers for the last 30 days
-aws ce get-cost-and-usage \
-  --time-period Start=$(date -d '30 days ago' +%Y-%m-%d),End=$(date +%Y-%m-%d) \
-  --granularity MONTHLY \
-  --metrics "UnblendedCost" \
-  --group-by Type=DIMENSION,Key=SERVICE \
-  --query 'ResultsByTime[0].Groups[*].{Service:Keys[0],Cost:Metrics.UnblendedCost.Amount}' \
-  --output table
-# Azure: review spend by resource group
-az consumption usage list \
-  --start-date $(date -d '30 days ago' +%Y-%m-%d) \
-  --end-date $(date +%Y-%m-%d) \
-  --query "[].{ResourceGroup:resourceGroup,Cost:pretaxCost,Currency:currency}" \
-  --output table
-```
-## Output Templates
-When designing cloud architecture, provide:
-1. Architecture diagram with services and data flow
-2. Service selection rationale (compute, storage, database, networking)
-3. Security architecture (IAM, network segmentation, encryption)
-4. Cost estimation and optimization strategy
-5. Deployment approach and rollback plan