npm - @cubis/foundry - Versions diffs - 0.3.32 → 0.3.33 - Mend

@cubis/foundry 0.3.32 → 0.3.33

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 (460) hide show

package/workflows/powers/debugging-wizard/POWER.md CHANGED Viewed

@@ -1,90 +1,24 @@
 ````markdown
 ---
 inclusion: manual
-name: "debugging-wizard"
-description: "Use when investigating errors, analyzing stack traces, or finding root causes of unexpected behavior. Invoke for error investigation, troubleshooting, log analysis, root cause analysis."
+name: debugging-wizard
+description: "Compatibility alias skill. Deprecated: use systematic-debugging."
+metadata:
+  deprecated: true
+  replaced_by: systematic-debugging
+  removal_target: v0.6.0
 ---
 # Debugging Wizard
-## Overview
-Expert debugger applying systematic methodology to isolate and resolve issues in any codebase.
-## Role Definition
-You are a senior engineer with 15+ years debugging experience across multiple languages and frameworks. You apply scientific methodology to isolate root causes efficiently. You never guess - you test hypotheses systematically.
-## When to Use This Skill
-- Investigating errors, exceptions, or unexpected behavior
-- Analyzing stack traces and error messages
-- Finding root causes of intermittent issues
-- Performance debugging and profiling
-- Memory leak investigation
-- Race condition diagnosis
-## Core Workflow
-1. **Reproduce** - Establish consistent reproduction steps
-2. **Isolate** - Narrow down to smallest failing case
-3. **Hypothesize** - Form testable theories about cause
-4. **Test** - Verify/disprove each hypothesis
-5. **Fix** - Implement and verify solution
-6. **Prevent** - Add tests/safeguards against regression
-## Available Steering Files
-Load detailed guidance on-demand:
-| Topic           | Reference                     | Load When                              |
-| --------------- | ----------------------------- | -------------------------------------- |
-| Debugging Tools | `references/debugging-tools.md` | Setting up debuggers by language       |
-| Common Patterns | `references/common-patterns.md` | Recognizing bug patterns               |
-| Strategies      | `references/strategies.md`      | Binary search, git bisect, time travel |
-| Quick Fixes     | `references/quick-fixes.md`     | Common error solutions                 |
-<!-- Row below adapted from obra/superpowers by Jesse Vincent (@obra), MIT License -->
-| Systematic Debugging | `references/systematic-debugging.md` | Complex bugs, multiple failed fixes, root cause analysis |
-## Constraints
-### MUST DO
-- Reproduce the issue first
-- Gather complete error messages and stack traces
-- Test one hypothesis at a time
-- Document findings for future reference
-- Add regression tests after fixing
-- Remove all debug code before committing
-### MUST NOT DO
-- Guess without testing
-- Make multiple changes at once
-- Skip reproduction steps
-- Assume you know the cause
-- Debug in production without safeguards
-- Leave console.log/debugger statements in code
-## Output Templates
-When debugging, provide:
-1. **Root Cause**: What specifically caused the issue
-2. **Evidence**: Stack trace, logs, or test that proves it
-3. **Fix**: Code change that resolves it
-4. **Prevention**: Test or safeguard to prevent recurrence
+## Compatibility Alias
-## Knowledge Reference
+This skill is deprecated and kept for backward compatibility.
-Debuggers (Chrome DevTools, VS Code, pdb, delve), profilers, log aggregation, distributed tracing, memory analysis, git bisect, error tracking (Sentry)
+Use `systematic-debugging` as the canonical skill.
-## Related Powers
+## Migration
-- **Test Master** - Writing regression tests
-- **Fullstack Guardian** - Implementing fixes
-- **Monitoring Expert** - Setting up alerting
+1. Replace direct references to `debugging-wizard` with `systematic-debugging`.
+2. Apply the full workflow from `systematic-debugging` for new work.
 ````

package/workflows/powers/debugging-wizard/SKILL.md CHANGED Viewed

@@ -1,87 +1,21 @@
 ---
-name: "debugging-wizard"
-description: "Use when investigating errors, analyzing stack traces, or finding root causes of unexpected behavior. Invoke for error investigation, troubleshooting, log analysis, root cause analysis."
+name: debugging-wizard
+description: "Compatibility alias skill. Deprecated: use systematic-debugging."
+metadata:
+  deprecated: true
+  replaced_by: systematic-debugging
+  removal_target: v0.6.0
 ---
 # Debugging Wizard
-## Overview
-Expert debugger applying systematic methodology to isolate and resolve issues in any codebase.
-## Role Definition
-You are a senior engineer with 15+ years debugging experience across multiple languages and frameworks. You apply scientific methodology to isolate root causes efficiently. You never guess - you test hypotheses systematically.
-## When to Use This Skill
-- Investigating errors, exceptions, or unexpected behavior
-- Analyzing stack traces and error messages
-- Finding root causes of intermittent issues
-- Performance debugging and profiling
-- Memory leak investigation
-- Race condition diagnosis
-## Core Workflow
-1. **Reproduce** - Establish consistent reproduction steps
-2. **Isolate** - Narrow down to smallest failing case
-3. **Hypothesize** - Form testable theories about cause
-4. **Test** - Verify/disprove each hypothesis
-5. **Fix** - Implement and verify solution
-6. **Prevent** - Add tests/safeguards against regression
-## Available Steering Files
-Load detailed guidance on-demand:
-| Topic           | Reference                     | Load When                              |
-| --------------- | ----------------------------- | -------------------------------------- |
-| Debugging Tools | `references/debugging-tools.md` | Setting up debuggers by language       |
-| Common Patterns | `references/common-patterns.md` | Recognizing bug patterns               |
-| Strategies      | `references/strategies.md`      | Binary search, git bisect, time travel |
-| Quick Fixes     | `references/quick-fixes.md`     | Common error solutions                 |
-<!-- Row below adapted from obra/superpowers by Jesse Vincent (@obra), MIT License -->
-| Systematic Debugging | `references/systematic-debugging.md` | Complex bugs, multiple failed fixes, root cause analysis |
-## Constraints
-### MUST DO
-- Reproduce the issue first
-- Gather complete error messages and stack traces
-- Test one hypothesis at a time
-- Document findings for future reference
-- Add regression tests after fixing
-- Remove all debug code before committing
-### MUST NOT DO
-- Guess without testing
-- Make multiple changes at once
-- Skip reproduction steps
-- Assume you know the cause
-- Debug in production without safeguards
-- Leave console.log/debugger statements in code
-## Output Templates
-When debugging, provide:
-1. **Root Cause**: What specifically caused the issue
-2. **Evidence**: Stack trace, logs, or test that proves it
-3. **Fix**: Code change that resolves it
-4. **Prevention**: Test or safeguard to prevent recurrence
+## Compatibility Alias
-## Knowledge Reference
+This skill is deprecated and kept for backward compatibility.
-Debuggers (Chrome DevTools, VS Code, pdb, delve), profilers, log aggregation, distributed tracing, memory analysis, git bisect, error tracking (Sentry)
+Use `systematic-debugging` as the canonical skill.
-## Related Powers
+## Migration
-- **Test Master** - Writing regression tests
-- **Fullstack Guardian** - Implementing fixes
-- **Monitoring Expert** - Setting up alerting
+1. Replace direct references to `debugging-wizard` with `systematic-debugging`.
+2. Apply the full workflow from `systematic-debugging` for new work.

package/workflows/powers/deployment-procedures/POWER.md CHANGED Viewed

@@ -2,243 +2,23 @@
 ---
 inclusion: manual
 name: deployment-procedures
-description: Production deployment principles and decision-making. Safe deployment workflows, rollback strategies, and verification. Teaches thinking, not scripts.
-allowed-tools: Read, Glob, Grep, Bash
+description: "Compatibility alias skill. Deprecated: use devops-engineer."
+metadata:
+  deprecated: true
+  replaced_by: devops-engineer
+  removal_target: v0.6.0
 ---
 # Deployment Procedures
-> Deployment principles and decision-making for safe production releases.
-> **Learn to THINK, not memorize scripts.**
+## Compatibility Alias
----
-## ⚠️ How to Use This Skill
-This skill teaches **deployment principles**, not bash scripts to copy.
-- Every deployment is unique
-- Understand the WHY behind each step
-- Adapt procedures to your platform
----
-## 1. Platform Selection
-### Decision Tree
-```
-What are you deploying?
-│
-├── Static site / JAMstack
-│   └── Vercel, Netlify, Cloudflare Pages
-│
-├── Simple web app
-│   ├── Managed → Railway, Render, Fly.io
-│   └── Control → VPS + PM2/Docker
-│
-├── Microservices
-│   └── Container orchestration
-│
-└── Serverless
-    └── Edge functions, Lambda
-```
-### Each Platform Has Different Procedures
-| Platform | Deployment Method |
-|----------|------------------|
-| **Vercel/Netlify** | Git push, auto-deploy |
-| **Railway/Render** | Git push or CLI |
-| **VPS + PM2** | SSH + manual steps |
-| **Docker** | Image push + orchestration |
-| **Kubernetes** | kubectl apply |
----
-## 2. Pre-Deployment Principles
-### The 4 Verification Categories
-| Category | What to Check |
-|----------|--------------|
-| **Code Quality** | Tests passing, linting clean, reviewed |
-| **Build** | Production build works, no warnings |
-| **Environment** | Env vars set, secrets current |
-| **Safety** | Backup done, rollback plan ready |
-### Pre-Deployment Checklist
-- [ ] All tests passing
-- [ ] Code reviewed and approved
-- [ ] Production build successful
-- [ ] Environment variables verified
-- [ ] Database migrations ready (if any)
-- [ ] Rollback plan documented
-- [ ] Team notified
-- [ ] Monitoring ready
----
-## 3. Deployment Workflow Principles
-### The 5-Phase Process
-```
-1. PREPARE
-   └── Verify code, build, env vars
-2. BACKUP
-   └── Save current state before changing
-3. DEPLOY
-   └── Execute with monitoring open
-4. VERIFY
-   └── Health check, logs, key flows
-5. CONFIRM or ROLLBACK
-   └── All good? Confirm. Issues? Rollback.
-```
-### Phase Principles
-| Phase | Principle |
-|-------|-----------|
-| **Prepare** | Never deploy untested code |
-| **Backup** | Can't rollback without backup |
-| **Deploy** | Watch it happen, don't walk away |
-| **Verify** | Trust but verify |
-| **Confirm** | Have rollback trigger ready |
----
-## 4. Post-Deployment Verification
-### What to Verify
-| Check | Why |
-|-------|-----|
-| **Health endpoint** | Service is running |
-| **Error logs** | No new errors |
-| **Key user flows** | Critical features work |
-| **Performance** | Response times acceptable |
-### Verification Window
-- **First 5 minutes**: Active monitoring
-- **15 minutes**: Confirm stable
-- **1 hour**: Final verification
-- **Next day**: Review metrics
+This skill is deprecated and kept for backward compatibility.
----
-## 5. Rollback Principles
-### When to Rollback
-| Symptom | Action |
-|---------|--------|
-| Service down | Rollback immediately |
-| Critical errors | Rollback |
-| Performance >50% degraded | Consider rollback |
-| Minor issues | Fix forward if quick |
-### Rollback Strategy by Platform
-| Platform | Rollback Method |
-|----------|----------------|
-| **Vercel/Netlify** | Redeploy previous commit |
-| **Railway/Render** | Rollback in dashboard |
-| **VPS + PM2** | Restore backup, restart |
-| **Docker** | Previous image tag |
-| **K8s** | kubectl rollout undo |
-### Rollback Principles
-1. **Speed over perfection**: Rollback first, debug later
-2. **Don't compound errors**: One rollback, not multiple changes
-3. **Communicate**: Tell team what happened
-4. **Post-mortem**: Understand why after stable
----
-## 6. Zero-Downtime Deployment
-### Strategies
-| Strategy | How It Works |
-|----------|--------------|
-| **Rolling** | Replace instances one by one |
-| **Blue-Green** | Switch traffic between environments |
-| **Canary** | Gradual traffic shift |
-### Selection Principles
-| Scenario | Strategy |
-|----------|----------|
-| Standard release | Rolling |
-| High-risk change | Blue-green (easy rollback) |
-| Need validation | Canary (test with real traffic) |
----
-## 7. Emergency Procedures
+Use `devops-engineer` as the canonical skill.
-### Service Down Priority
-1. **Assess**: What's the symptom?
-2. **Quick fix**: Restart if unclear
-3. **Rollback**: If restart doesn't help
-4. **Investigate**: After stable
-### Investigation Order
-| Check | Common Issues |
-|-------|--------------|
-| **Logs** | Errors, exceptions |
-| **Resources** | Disk full, memory |
-| **Network** | DNS, firewall |
-| **Dependencies** | Database, APIs |
----
-## 8. Anti-Patterns
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Deploy on Friday | Deploy early in week |
-| Rush deployment | Follow the process |
-| Skip staging | Always test first |
-| Deploy without backup | Backup before deploy |
-| Walk away after deploy | Monitor for 15+ min |
-| Multiple changes at once | One change at a time |
----
-## 9. Decision Checklist
-Before deploying:
-- [ ] **Platform-appropriate procedure?**
-- [ ] **Backup strategy ready?**
-- [ ] **Rollback plan documented?**
-- [ ] **Monitoring configured?**
-- [ ] **Team notified?**
-- [ ] **Time to monitor after?**
----
-## 10. Best Practices
-1. **Small, frequent deploys** over big releases
-2. **Feature flags** for risky changes
-3. **Automate** repetitive steps
-4. **Document** every deployment
-5. **Review** what went wrong after issues
-6. **Test rollback** before you need it
----
+## Migration
-> **Remember:** Every deployment is a risk. Minimize risk through preparation, not speed.
+1. Replace direct references to `deployment-procedures` with `devops-engineer`.
+2. Apply the full workflow from `devops-engineer` for new work.
 ````

package/workflows/powers/deployment-procedures/SKILL.md CHANGED Viewed

@@ -1,241 +1,21 @@
 ---
 name: deployment-procedures
-description: Production deployment principles and decision-making. Safe deployment workflows, rollback strategies, and verification. Teaches thinking, not scripts.
-allowed-tools: Read, Glob, Grep, Bash
+description: "Compatibility alias skill. Deprecated: use devops-engineer."
+metadata:
+  deprecated: true
+  replaced_by: devops-engineer
+  removal_target: v0.6.0
 ---
 # Deployment Procedures
-> Deployment principles and decision-making for safe production releases.
-> **Learn to THINK, not memorize scripts.**
+## Compatibility Alias
----
-## ⚠️ How to Use This Skill
-This skill teaches **deployment principles**, not bash scripts to copy.
-- Every deployment is unique
-- Understand the WHY behind each step
-- Adapt procedures to your platform
----
-## 1. Platform Selection
-### Decision Tree
-```
-What are you deploying?
-│
-├── Static site / JAMstack
-│   └── Vercel, Netlify, Cloudflare Pages
-│
-├── Simple web app
-│   ├── Managed → Railway, Render, Fly.io
-│   └── Control → VPS + PM2/Docker
-│
-├── Microservices
-│   └── Container orchestration
-│
-└── Serverless
-    └── Edge functions, Lambda
-```
-### Each Platform Has Different Procedures
-| Platform | Deployment Method |
-|----------|------------------|
-| **Vercel/Netlify** | Git push, auto-deploy |
-| **Railway/Render** | Git push or CLI |
-| **VPS + PM2** | SSH + manual steps |
-| **Docker** | Image push + orchestration |
-| **Kubernetes** | kubectl apply |
----
-## 2. Pre-Deployment Principles
-### The 4 Verification Categories
-| Category | What to Check |
-|----------|--------------|
-| **Code Quality** | Tests passing, linting clean, reviewed |
-| **Build** | Production build works, no warnings |
-| **Environment** | Env vars set, secrets current |
-| **Safety** | Backup done, rollback plan ready |
-### Pre-Deployment Checklist
-- [ ] All tests passing
-- [ ] Code reviewed and approved
-- [ ] Production build successful
-- [ ] Environment variables verified
-- [ ] Database migrations ready (if any)
-- [ ] Rollback plan documented
-- [ ] Team notified
-- [ ] Monitoring ready
----
-## 3. Deployment Workflow Principles
-### The 5-Phase Process
-```
-1. PREPARE
-   └── Verify code, build, env vars
-2. BACKUP
-   └── Save current state before changing
-3. DEPLOY
-   └── Execute with monitoring open
-4. VERIFY
-   └── Health check, logs, key flows
-5. CONFIRM or ROLLBACK
-   └── All good? Confirm. Issues? Rollback.
-```
-### Phase Principles
-| Phase | Principle |
-|-------|-----------|
-| **Prepare** | Never deploy untested code |
-| **Backup** | Can't rollback without backup |
-| **Deploy** | Watch it happen, don't walk away |
-| **Verify** | Trust but verify |
-| **Confirm** | Have rollback trigger ready |
----
-## 4. Post-Deployment Verification
-### What to Verify
-| Check | Why |
-|-------|-----|
-| **Health endpoint** | Service is running |
-| **Error logs** | No new errors |
-| **Key user flows** | Critical features work |
-| **Performance** | Response times acceptable |
-### Verification Window
-- **First 5 minutes**: Active monitoring
-- **15 minutes**: Confirm stable
-- **1 hour**: Final verification
-- **Next day**: Review metrics
+This skill is deprecated and kept for backward compatibility.
----
-## 5. Rollback Principles
-### When to Rollback
-| Symptom | Action |
-|---------|--------|
-| Service down | Rollback immediately |
-| Critical errors | Rollback |
-| Performance >50% degraded | Consider rollback |
-| Minor issues | Fix forward if quick |
-### Rollback Strategy by Platform
-| Platform | Rollback Method |
-|----------|----------------|
-| **Vercel/Netlify** | Redeploy previous commit |
-| **Railway/Render** | Rollback in dashboard |
-| **VPS + PM2** | Restore backup, restart |
-| **Docker** | Previous image tag |
-| **K8s** | kubectl rollout undo |
-### Rollback Principles
-1. **Speed over perfection**: Rollback first, debug later
-2. **Don't compound errors**: One rollback, not multiple changes
-3. **Communicate**: Tell team what happened
-4. **Post-mortem**: Understand why after stable
----
-## 6. Zero-Downtime Deployment
-### Strategies
-| Strategy | How It Works |
-|----------|--------------|
-| **Rolling** | Replace instances one by one |
-| **Blue-Green** | Switch traffic between environments |
-| **Canary** | Gradual traffic shift |
-### Selection Principles
-| Scenario | Strategy |
-|----------|----------|
-| Standard release | Rolling |
-| High-risk change | Blue-green (easy rollback) |
-| Need validation | Canary (test with real traffic) |
----
-## 7. Emergency Procedures
+Use `devops-engineer` as the canonical skill.
-### Service Down Priority
-1. **Assess**: What's the symptom?
-2. **Quick fix**: Restart if unclear
-3. **Rollback**: If restart doesn't help
-4. **Investigate**: After stable
-### Investigation Order
-| Check | Common Issues |
-|-------|--------------|
-| **Logs** | Errors, exceptions |
-| **Resources** | Disk full, memory |
-| **Network** | DNS, firewall |
-| **Dependencies** | Database, APIs |
----
-## 8. Anti-Patterns
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Deploy on Friday | Deploy early in week |
-| Rush deployment | Follow the process |
-| Skip staging | Always test first |
-| Deploy without backup | Backup before deploy |
-| Walk away after deploy | Monitor for 15+ min |
-| Multiple changes at once | One change at a time |
----
-## 9. Decision Checklist
-Before deploying:
-- [ ] **Platform-appropriate procedure?**
-- [ ] **Backup strategy ready?**
-- [ ] **Rollback plan documented?**
-- [ ] **Monitoring configured?**
-- [ ] **Team notified?**
-- [ ] **Time to monitor after?**
----
-## 10. Best Practices
-1. **Small, frequent deploys** over big releases
-2. **Feature flags** for risky changes
-3. **Automate** repetitive steps
-4. **Document** every deployment
-5. **Review** what went wrong after issues
-6. **Test rollback** before you need it
----
+## Migration
-> **Remember:** Every deployment is a risk. Minimize risk through preparation, not speed.
+1. Replace direct references to `deployment-procedures` with `devops-engineer`.
+2. Apply the full workflow from `devops-engineer` for new work.