@cubis/foundry 0.3.31 → 0.3.33

package/workflows/powers/server-management/SKILL.md

@@ -1,161 +1,21 @@
 ---
 name: server-management
-description: Server management principles and decision-making. Process management, monitoring strategy, and scaling decisions. Teaches thinking, not commands.
-allowed-tools: Read, Write, Edit, Glob, Grep, Bash
+description: "Compatibility alias skill. Deprecated: use sre-engineer."
+metadata:
+  deprecated: true
+  replaced_by: sre-engineer
+  removal_target: v0.6.0
 ---
 
 # Server Management
 
-> Server management principles for production operations.
-> **Learn to THINK, not memorize commands.**
+## Compatibility Alias
 
----
-
-## 1. Process Management Principles
-
-### Tool Selection
-
-| Scenario | Tool |
-|----------|------|
-| **Node.js app** | PM2 (clustering, reload) |
-| **Any app** | systemd (Linux native) |
-| **Containers** | Docker/Podman |
-| **Orchestration** | Kubernetes, Docker Swarm |
-
-### Process Management Goals
-
-| Goal | What It Means |
-|------|---------------|
-| **Restart on crash** | Auto-recovery |
-| **Zero-downtime reload** | No service interruption |
-| **Clustering** | Use all CPU cores |
-| **Persistence** | Survive server reboot |
-
----
-
-## 2. Monitoring Principles
-
-### What to Monitor
-
-| Category | Key Metrics |
-|----------|-------------|
-| **Availability** | Uptime, health checks |
-| **Performance** | Response time, throughput |
-| **Errors** | Error rate, types |
-| **Resources** | CPU, memory, disk |
-
-### Alert Severity Strategy
-
-| Level | Response |
-|-------|----------|
-| **Critical** | Immediate action |
-| **Warning** | Investigate soon |
-| **Info** | Review daily |
-
-### Monitoring Tool Selection
-
-| Need | Options |
-|------|---------|
-| Simple/Free | PM2 metrics, htop |
-| Full observability | Grafana, Datadog |
-| Error tracking | Sentry |
-| Uptime | UptimeRobot, Pingdom |
-
----
-
-## 3. Log Management Principles
-
-### Log Strategy
-
-| Log Type | Purpose |
-|----------|---------|
-| **Application logs** | Debug, audit |
-| **Access logs** | Traffic analysis |
-| **Error logs** | Issue detection |
-
-### Log Principles
-
-1. **Rotate logs** to prevent disk fill
-2. **Structured logging** (JSON) for parsing
-3. **Appropriate levels** (error/warn/info/debug)
-4. **No sensitive data** in logs
-
----
-
-## 4. Scaling Decisions
+This skill is deprecated and kept for backward compatibility.
 
-### When to Scale
+Use `sre-engineer` as the canonical skill.
 
-| Symptom | Solution |
-|---------|----------|
-| High CPU | Add instances (horizontal) |
-| High memory | Increase RAM or fix leak |
-| Slow response | Profile first, then scale |
-| Traffic spikes | Auto-scaling |
-
-### Scaling Strategy
-
-| Type | When to Use |
-|------|-------------|
-| **Vertical** | Quick fix, single instance |
-| **Horizontal** | Sustainable, distributed |
-| **Auto** | Variable traffic |
-
----
-
-## 5. Health Check Principles
-
-### What Constitutes Healthy
-
-| Check | Meaning |
-|-------|---------|
-| **HTTP 200** | Service responding |
-| **Database connected** | Data accessible |
-| **Dependencies OK** | External services reachable |
-| **Resources OK** | CPU/memory not exhausted |
-
-### Health Check Implementation
-
-- Simple: Just return 200
-- Deep: Check all dependencies
-- Choose based on load balancer needs
-
----
-
-## 6. Security Principles
-
-| Area | Principle |
-|------|-----------|
-| **Access** | SSH keys only, no passwords |
-| **Firewall** | Only needed ports open |
-| **Updates** | Regular security patches |
-| **Secrets** | Environment vars, not files |
-| **Audit** | Log access and changes |
-
----
-
-## 7. Troubleshooting Priority
-
-When something's wrong:
-
-1. **Check if running** (process status)
-2. **Check logs** (error messages)
-3. **Check resources** (disk, memory, CPU)
-4. **Check network** (ports, DNS)
-5. **Check dependencies** (database, APIs)
-
----
-
-## 8. Anti-Patterns
-
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Run as root | Use non-root user |
-| Ignore logs | Set up log rotation |
-| Skip monitoring | Monitor from day one |
-| Manual restarts | Auto-restart config |
-| No backups | Regular backup schedule |
-
----
+## Migration
 
-> **Remember:** A well-managed server is boring. That's the goal.
+1. Replace direct references to `server-management` with `sre-engineer`.
+2. Apply the full workflow from `sre-engineer` for new work.

package/workflows/powers/tdd-workflow/POWER.md

@@ -2,151 +2,23 @@
 ---
 inclusion: manual
 name: tdd-workflow
-description: Test-Driven Development workflow principles. RED-GREEN-REFACTOR cycle.
-allowed-tools: Read, Write, Edit, Glob, Grep, Bash
+description: "Compatibility alias skill. Deprecated: use test-master."
+metadata:
+  deprecated: true
+  replaced_by: test-master
+  removal_target: v0.6.0
 ---
 
-# TDD Workflow
+# Tdd Workflow
 
-> Write tests first, code second.
+## Compatibility Alias
 
----
-
-## 1. The TDD Cycle
-
-```
-🔴 RED → Write failing test
-    ↓
-🟢 GREEN → Write minimal code to pass
-    ↓
-🔵 REFACTOR → Improve code quality
-    ↓
-   Repeat...
-```
-
----
-
-## 2. The Three Laws of TDD
-
-1. Write production code only to make a failing test pass
-2. Write only enough test to demonstrate failure
-3. Write only enough code to make the test pass
-
----
-
-## 3. RED Phase Principles
-
-### What to Write
-
-| Focus | Example |
-|-------|---------|
-| Behavior | "should add two numbers" |
-| Edge cases | "should handle empty input" |
-| Error states | "should throw for invalid data" |
-
-### RED Phase Rules
-
-- Test must fail first
-- Test name describes expected behavior
-- One assertion per test (ideally)
-
----
-
-## 4. GREEN Phase Principles
-
-### Minimum Code
-
-| Principle | Meaning |
-|-----------|---------|
-| **YAGNI** | You Aren't Gonna Need It |
-| **Simplest thing** | Write the minimum to pass |
-| **No optimization** | Just make it work |
-
-### GREEN Phase Rules
-
-- Don't write unneeded code
-- Don't optimize yet
-- Pass the test, nothing more
-
----
-
-## 5. REFACTOR Phase Principles
-
-### What to Improve
+This skill is deprecated and kept for backward compatibility.
 
-| Area | Action |
-|------|--------|
-| Duplication | Extract common code |
-| Naming | Make intent clear |
-| Structure | Improve organization |
-| Complexity | Simplify logic |
+Use `test-master` as the canonical skill.
 
-### REFACTOR Rules
-
-- All tests must stay green
-- Small incremental changes
-- Commit after each refactor
-
----
-
-## 6. AAA Pattern
-
-Every test follows:
-
-| Step | Purpose |
-|------|---------|
-| **Arrange** | Set up test data |
-| **Act** | Execute code under test |
-| **Assert** | Verify expected outcome |
-
----
-
-## 7. When to Use TDD
-
-| Scenario | TDD Value |
-|----------|-----------|
-| New feature | High |
-| Bug fix | High (write test first) |
-| Complex logic | High |
-| Exploratory | Low (spike, then TDD) |
-| UI layout | Low |
-
----
-
-## 8. Test Prioritization
-
-| Priority | Test Type |
-|----------|-----------|
-| 1 | Happy path |
-| 2 | Error cases |
-| 3 | Edge cases |
-| 4 | Performance |
-
----
-
-## 9. Anti-Patterns
-
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Skip the RED phase | Watch test fail first |
-| Write tests after | Write tests before |
-| Over-engineer initial | Keep it simple |
-| Multiple asserts | One behavior per test |
-| Test implementation | Test behavior |
-
----
-
-## 10. AI-Augmented TDD
-
-### Multi-Agent Pattern
-
-| Agent | Role |
-|-------|------|
-| Agent A | Write failing tests (RED) |
-| Agent B | Implement to pass (GREEN) |
-| Agent C | Optimize (REFACTOR) |
-
----
+## Migration
 
-> **Remember:** The test is the specification. If you can't write a test, you don't understand the requirement.
+1. Replace direct references to `tdd-workflow` with `test-master`.
+2. Apply the full workflow from `test-master` for new work.
 ````

package/workflows/powers/tdd-workflow/SKILL.md

@@ -1,149 +1,21 @@
 ---
 name: tdd-workflow
-description: Test-Driven Development workflow principles. RED-GREEN-REFACTOR cycle.
-allowed-tools: Read, Write, Edit, Glob, Grep, Bash
+description: "Compatibility alias skill. Deprecated: use test-master."
+metadata:
+  deprecated: true
+  replaced_by: test-master
+  removal_target: v0.6.0
 ---
 
-# TDD Workflow
+# Tdd Workflow
 
-> Write tests first, code second.
+## Compatibility Alias
 
----
-
-## 1. The TDD Cycle
-
-```
-🔴 RED → Write failing test
-    ↓
-🟢 GREEN → Write minimal code to pass
-    ↓
-🔵 REFACTOR → Improve code quality
-    ↓
-   Repeat...
-```
-
----
-
-## 2. The Three Laws of TDD
-
-1. Write production code only to make a failing test pass
-2. Write only enough test to demonstrate failure
-3. Write only enough code to make the test pass
-
----
-
-## 3. RED Phase Principles
-
-### What to Write
-
-| Focus | Example |
-|-------|---------|
-| Behavior | "should add two numbers" |
-| Edge cases | "should handle empty input" |
-| Error states | "should throw for invalid data" |
-
-### RED Phase Rules
-
-- Test must fail first
-- Test name describes expected behavior
-- One assertion per test (ideally)
-
----
-
-## 4. GREEN Phase Principles
-
-### Minimum Code
-
-| Principle | Meaning |
-|-----------|---------|
-| **YAGNI** | You Aren't Gonna Need It |
-| **Simplest thing** | Write the minimum to pass |
-| **No optimization** | Just make it work |
-
-### GREEN Phase Rules
-
-- Don't write unneeded code
-- Don't optimize yet
-- Pass the test, nothing more
-
----
-
-## 5. REFACTOR Phase Principles
-
-### What to Improve
+This skill is deprecated and kept for backward compatibility.
 
-| Area | Action |
-|------|--------|
-| Duplication | Extract common code |
-| Naming | Make intent clear |
-| Structure | Improve organization |
-| Complexity | Simplify logic |
+Use `test-master` as the canonical skill.
 
-### REFACTOR Rules
-
-- All tests must stay green
-- Small incremental changes
-- Commit after each refactor
-
----
-
-## 6. AAA Pattern
-
-Every test follows:
-
-| Step | Purpose |
-|------|---------|
-| **Arrange** | Set up test data |
-| **Act** | Execute code under test |
-| **Assert** | Verify expected outcome |
-
----
-
-## 7. When to Use TDD
-
-| Scenario | TDD Value |
-|----------|-----------|
-| New feature | High |
-| Bug fix | High (write test first) |
-| Complex logic | High |
-| Exploratory | Low (spike, then TDD) |
-| UI layout | Low |
-
----
-
-## 8. Test Prioritization
-
-| Priority | Test Type |
-|----------|-----------|
-| 1 | Happy path |
-| 2 | Error cases |
-| 3 | Edge cases |
-| 4 | Performance |
-
----
-
-## 9. Anti-Patterns
-
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Skip the RED phase | Watch test fail first |
-| Write tests after | Write tests before |
-| Over-engineer initial | Keep it simple |
-| Multiple asserts | One behavior per test |
-| Test implementation | Test behavior |
-
----
-
-## 10. AI-Augmented TDD
-
-### Multi-Agent Pattern
-
-| Agent | Role |
-|-------|------|
-| Agent A | Write failing tests (RED) |
-| Agent B | Implement to pass (GREEN) |
-| Agent C | Optimize (REFACTOR) |
-
----
+## Migration
 
-> **Remember:** The test is the specification. If you can't write a test, you don't understand the requirement.
+1. Replace direct references to `tdd-workflow` with `test-master`.
+2. Apply the full workflow from `test-master` for new work.

package/workflows/powers/testing-patterns/POWER.md

@@ -2,180 +2,23 @@
 ---
 inclusion: manual
 name: testing-patterns
-description: Testing patterns and principles. Unit, integration, mocking strategies.
-allowed-tools: Read, Write, Edit, Glob, Grep, Bash
+description: "Compatibility alias skill. Deprecated: use test-master."
+metadata:
+  deprecated: true
+  replaced_by: test-master
+  removal_target: v0.6.0
 ---
 
 # Testing Patterns
 
-> Principles for reliable test suites.
+## Compatibility Alias
 
----
-
-## 1. Testing Pyramid
-
-```
-        /\          E2E (Few)
-       /  \         Critical flows
-      /----\
-     /      \       Integration (Some)
-    /--------\      API, DB queries
-   /          \
-  /------------\    Unit (Many)
-                    Functions, classes
-```
-
----
-
-## 2. AAA Pattern
-
-| Step | Purpose |
-|------|---------|
-| **Arrange** | Set up test data |
-| **Act** | Execute code under test |
-| **Assert** | Verify outcome |
-
----
-
-## 3. Test Type Selection
-
-### When to Use Each
-
-| Type | Best For | Speed |
-|------|----------|-------|
-| **Unit** | Pure functions, logic | Fast (<50ms) |
-| **Integration** | API, DB, services | Medium |
-| **E2E** | Critical user flows | Slow |
-
----
-
-## 4. Unit Test Principles
-
-### Good Unit Tests
-
-| Principle | Meaning |
-|-----------|---------|
-| Fast | < 100ms each |
-| Isolated | No external deps |
-| Repeatable | Same result always |
-| Self-checking | No manual verification |
-| Timely | Written with code |
-
-### What to Unit Test
-
-| Test | Don't Test |
-|------|------------|
-| Business logic | Framework code |
-| Edge cases | Third-party libs |
-| Error handling | Simple getters |
-
----
-
-## 5. Integration Test Principles
-
-### What to Test
-
-| Area | Focus |
-|------|-------|
-| API endpoints | Request/response |
-| Database | Queries, transactions |
-| External services | Contracts |
-
-### Setup/Teardown
-
-| Phase | Action |
-|-------|--------|
-| Before All | Connect resources |
-| Before Each | Reset state |
-| After Each | Clean up |
-| After All | Disconnect |
-
----
+This skill is deprecated and kept for backward compatibility.
 
-## 6. Mocking Principles
+Use `test-master` as the canonical skill.
 
-### When to Mock
-
-| Mock | Don't Mock |
-|------|------------|
-| External APIs | The code under test |
-| Database (unit) | Simple dependencies |
-| Time/random | Pure functions |
-| Network | In-memory stores |
-
-### Mock Types
-
-| Type | Use |
-|------|-----|
-| Stub | Return fixed values |
-| Spy | Track calls |
-| Mock | Set expectations |
-| Fake | Simplified implementation |
-
----
-
-## 7. Test Organization
-
-### Naming
-
-| Pattern | Example |
-|---------|---------|
-| Should behavior | "should return error when..." |
-| When condition | "when user not found..." |
-| Given-when-then | "given X, when Y, then Z" |
-
-### Grouping
-
-| Level | Use |
-|-------|-----|
-| describe | Group related tests |
-| it/test | Individual case |
-| beforeEach | Common setup |
-
----
-
-## 8. Test Data
-
-### Strategies
-
-| Approach | Use |
-|----------|-----|
-| Factories | Generate test data |
-| Fixtures | Predefined datasets |
-| Builders | Fluent object creation |
-
-### Principles
-
-- Use realistic data
-- Randomize non-essential values (faker)
-- Share common fixtures
-- Keep data minimal
-
----
-
-## 9. Best Practices
-
-| Practice | Why |
-|----------|-----|
-| One assert per test | Clear failure reason |
-| Independent tests | No order dependency |
-| Fast tests | Run frequently |
-| Descriptive names | Self-documenting |
-| Clean up | Avoid side effects |
-
----
-
-## 10. Anti-Patterns
-
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Test implementation | Test behavior |
-| Duplicate test code | Use factories |
-| Complex test setup | Simplify or split |
-| Ignore flaky tests | Fix root cause |
-| Skip cleanup | Reset state |
-
----
+## Migration
 
-> **Remember:** Tests are documentation. If someone can't understand what the code does from the tests, rewrite them.
+1. Replace direct references to `testing-patterns` with `test-master`.
+2. Apply the full workflow from `test-master` for new work.
 ````