@acmecloud/core 1.0.5 → 1.0.7

package/dist/skills/builtin/code-concise.md

@@ -0,0 +1,84 @@
+---
+name: code-concise
+description: Code review and optimization based on Clean Code principles
+---
+
+# Clean Code Review & Optimization Skill
+
+This skill provides automated code review and intelligent optimization recommendations based on "Clean Code" principles.
+
+## When to Use
+
+Apply when:
+
+- Reviewing code for issues
+- Analyzing code quality
+- Providing improvement suggestions
+- Optimizing existing code
+
+## Core Rules
+
+### Priority Levels
+
+**CRITICAL** - Must fix immediately:
+
+- Security vulnerabilities
+- Data loss risks
+- Performance disasters
+- Logic errors
+- Null pointer exceptions
+
+**HIGH** - Should fix soon:
+
+- Code duplication > 10 lines
+- Functions > 50 lines
+- Cyclomatic complexity > 10
+- Missing error handling
+
+**MEDIUM** - Should fix eventually:
+
+- Non-meaningful names
+- Inconsistent naming
+- Missing documentation
+
+**LOW** - Nice to have:
+
+- Formatting issues
+- Minor style violations
+
+### Naming Issues
+
+**Bad:** `d`, `temp`, `data`, `process()`, `handle()`
+**Good:** `days`, `dailyRate`, `calculateTotalCost()`
+
+### Function Issues
+
+- Functions should be < 20 lines (WARNING if > 20, HIGH if > 50)
+- Parameters should be ≤ 3 (use objects for more)
+- No boolean flags that change behavior
+- Separate side effects from return values
+
+### Code Duplication
+
+- Extract repeated blocks (>10 lines) to functions
+- Use parameterization for similar logic
+
+### Error Handling
+
+- Never ignore errors (empty catch blocks)
+- Don't return null - throw exceptions or use Optional
+- Don't use magic error codes - use exceptions
+
+### Code Structure
+
+- Max 3 levels of nesting (use guard clauses)
+- No magic numbers (use named constants)
+- Classes should be < 200 lines
+
+## Review Workflow
+
+1. **Quick Scan**: Identify top 3-5 critical issues
+2. **Detailed Review**: Expand on specific issues when asked
+3. **Optimization**: Provide refactoring suggestions when requested
+
+Provide actionable fixes with before/after code examples.

package/dist/skills/builtin/frontend-design.md

@@ -0,0 +1,137 @@
+---
+name: frontend-design
+description: Create distinctive, production-grade frontend interfaces
+---
+
+# Frontend Design
+
+Create distinctive, production-grade frontend interfaces with high design quality.
+
+## When to Use
+
+Use when building:
+
+- Web components
+- Landing pages
+- Dashboards
+- React/Vue components
+- HTML/CSS layouts
+- Any web UI
+
+## Design Principles
+
+### 1. Choose a Bold Direction
+
+Before coding, understand:
+
+- **Purpose**: What problem does this solve?
+- **Tone**: Pick an extreme (minimalist, maximalist, retro, futuristic, etc.)
+- **Constraints**: Technical requirements
+- **Differentiation**: What makes this UNFORGETTABLE?
+
+### 2. Typography Matters
+
+**Do:**
+
+- Choose distinctive fonts
+- Pair display fonts with body fonts
+- Use font weights intentionally
+
+**Avoid:**
+
+- Generic fonts (Arial, Inter, Roboto) as defaults
+- System fonts for distinctive designs
+
+### 3. Color & Theme
+
+- Commit to a cohesive palette
+- Use CSS variables for consistency
+- Dominant colors with sharp accents
+- Avoid timid, evenly-distributed palettes
+
+### 4. Motion & Animation
+
+- Use CSS animations for polish
+- Staggered reveals (animation-delay)
+- Scroll-triggered effects
+- Hover states that surprise
+- One well-orchestrated page load > many micro-interactions
+
+### 5. Spatial Composition
+
+- Unexpected layouts
+- Asymmetry
+- Diagonal flow
+- Grid-breaking elements
+- Generous negative space OR controlled density
+
+### 6. Visual Details
+
+Create atmosphere with:
+
+- Gradient meshes
+- Noise textures
+- Geometric patterns
+- Layered transparencies
+- Dramatic shadows
+- Custom cursors
+- Grain overlays
+
+## Avoid Generic AI Aesthetics
+
+❌ Generic fonts (Inter, Roboto, Arial)
+❌ Purple gradients on white
+❌ Predictable layouts
+❌ Cookie-cutter components
+
+✅ Distinctive font choices
+✅ Unexpected color combinations
+✅ Creative layouts
+✅ Contextual design decisions
+
+## Implementation Guidelines
+
+### Maximalist Design
+
+Needs elaborate code with:
+
+- Extensive animations
+- Multiple effects
+- Layered elements
+- Rich interactions
+
+### Minimalist Design
+
+Needs restraint with:
+
+- Precise spacing
+- Careful typography
+- Subtle details
+- Perfect proportions
+
+## Code Quality
+
+Your code should be:
+
+- Production-grade
+- Functional
+- Visually striking
+- Meticulously refined
+
+Match implementation complexity to aesthetic vision.
+
+## Quick Reference
+
+**Before coding:**
+
+1. What's the purpose?
+2. What's the tone?
+3. What makes it memorable?
+
+**While coding:**
+
+1. Is this distinctive or generic?
+2. Are details refined?
+3. Does it match the vision?
+
+**Remember:** Claude is capable of extraordinary creative work. Don't settle for generic.

package/dist/skills/builtin/systematic-debugging.md

@@ -0,0 +1,156 @@
+---
+name: systematic-debugging
+description: Systematic debugging - find root cause before proposing fixes
+---
+
+# Systematic Debugging
+
+**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
+
+**The Iron Law:** NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
+
+If you haven't completed Phase 1, you cannot propose fixes.
+
+## When to Use
+
+Use for ANY technical issue:
+
+- Test failures
+- Bugs in production
+- Unexpected behavior
+- Performance problems
+- Build failures
+- Integration issues
+
+**Use ESPECIALLY when:**
+
+- Under time pressure (emergencies make guessing tempting)
+- "Just one quick fix" seems obvious
+- You've already tried multiple fixes
+- You don't fully understand the issue
+
+## Phase 1: Root Cause Investigation
+
+### Step 1: Read Error Messages Carefully
+
+- Don't skip past errors or warnings
+- Read stack traces completely
+- Note line numbers, file paths, error codes
+- They often contain the exact solution
+
+### Step 2: Reproduce Consistently
+
+Ask:
+
+- Can you trigger it reliably?
+- What are the exact steps?
+- Does it happen every time?
+- If not reproducible → gather more data, don't guess
+
+### Step 3: Check Recent Changes
+
+- What changed that could cause this?
+- Git diff, recent commits
+- New dependencies, config changes
+- Environmental differences
+
+### Step 4: Gather Evidence
+
+In multi-component systems:
+
+- Log what data enters each component
+- Log what data exits each component
+- Verify environment/config propagation
+- Check state at each layer
+
+**Example diagnostic approach:**
+
+```bash
+# Check each layer
+echo "=== Layer 1: Input ==="
+# Check input data
+
+echo "=== Layer 2: Processing ==="
+# Check processing state
+
+echo "=== Layer 3: Output ==="
+# Check output data
+```
+
+## Phase 2: Hypothesis Formation
+
+After gathering evidence:
+
+1. **List observed symptoms**
+   - What exactly is happening?
+   - What should happen instead?
+
+2. **Form hypotheses**
+   - What could cause these symptoms?
+   - Rank by likelihood
+
+3. **Test hypotheses systematically**
+   - Start with most likely
+   - Design tests that prove/disprove
+
+## Phase 3: Fix Implementation
+
+Only after root cause is found:
+
+1. **Propose minimal fix**
+   - Address root cause, not symptoms
+   - Smallest change possible
+
+2. **Verify fix**
+   - Run all tests
+   - Check for regressions
+   - Verify root cause is resolved
+
+3. **Document learnings**
+   - What caused the bug?
+   - How can we prevent this?
+   - Add tests if missing
+
+## Red Flags
+
+**STOP if you're about to:**
+
+- Change random things hoping it works
+- Apply fixes without understanding
+- Say "let me just try this"
+- Skip error messages
+- Assume you know without checking
+
+## Common Mistakes
+
+❌ **Random fixes** - Changing code without understanding
+❌ **Assumption-based debugging** - "It should work because..."
+❌ **Ignoring error messages** - Skipping past crucial clues
+❌ **Fixing symptoms** - Not addressing root cause
+❌ **Multiple changes** - Can't tell what fixed it
+
+## Debugging Checklist
+
+Before proposing any fix:
+
+- [ ] I have reproduced the issue consistently
+- [ ] I have read the full error message
+- [ ] I have checked recent changes
+- [ ] I have gathered evidence from the system
+- [ ] I understand the root cause
+- [ ] I can explain why my fix will work
+
+## Quick Reference
+
+```
+1. READ errors carefully
+2. REPRODUCE consistently
+3. CHECK recent changes
+4. GATHER evidence
+5. FORM hypotheses
+6. TEST systematically
+7. FIX root cause
+8. VERIFY fix works
+```
+
+**Remember:** Systematic debugging is faster than random fixes.

package/dist/skills/builtin/tdd.md

@@ -0,0 +1,157 @@
+---
+name: tdd
+description: Test-Driven Development - write failing tests first, then minimal code to pass
+---
+
+# Test-Driven Development (TDD)
+
+**Core principle:** Write the test first. Watch it fail. Write minimal code to pass.
+
+If you didn't watch the test fail, you don't know if it tests the right thing.
+
+## When to Use
+
+**Always use for:**
+
+- New features
+- Bug fixes
+- Refactoring
+- Behavior changes
+
+**Exceptions (ask first):**
+
+- Throwaway prototypes
+- Generated code
+- Configuration files
+
+## The Iron Law
+
+**NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST**
+
+Write code before the test? Delete it. Start fresh from tests.
+
+## Red-Green-Refactor Cycle
+
+### 1. RED - Write Failing Test
+
+Write ONE minimal test that demonstrates what should happen:
+
+```typescript
+test("retries failed operations 3 times", async () => {
+  let attempts = 0;
+  const operation = () => {
+    attempts++;
+    if (attempts < 3) throw new Error("fail");
+    return "success";
+  };
+
+  const result = await retryOperation(operation);
+
+  expect(result).toBe("success");
+  expect(attempts).toBe(3);
+});
+```
+
+**Test qualities:**
+
+- Clear, specific name
+- Tests real behavior
+- One thing only
+
+### 2. GREEN - Minimal Code to Pass
+
+Write the simplest code that makes the test pass:
+
+```typescript
+async function retryOperation(operation: () => any, maxRetries: number = 3) {
+  let attempts = 0;
+  while (attempts < maxRetries) {
+    try {
+      return await operation();
+    } catch (e) {
+      attempts++;
+      if (attempts >= maxRetries) throw e;
+    }
+  }
+}
+```
+
+**Don't:**
+
+- Add extra features "just in case"
+- Make it perfect
+- Over-engineer
+
+**Do:**
+
+- Make it work
+- Keep it simple
+- Stay focused on the test
+
+### 3. REFACTOR - Clean Up
+
+Now improve the code while keeping tests green:
+
+- Remove duplication
+- Improve names
+- Extract functions
+- Apply patterns
+
+Then repeat for the next test.
+
+## Test Writing Guidelines
+
+### Good Test Names
+
+✅ `returnsZeroForEmptyArray()`
+✅ `throwsErrorForInvalidInput()`
+✅ `calculatesTotalWithDiscount()`
+
+❌ `test1()`, `test2()`
+❌ `test()`, `check()`
+❌ `works()`, `fails()`
+
+### Test Real Behavior
+
+✅ Tests actual API usage
+✅ Uses real dependencies when possible
+✅ Clear expected outcome
+
+❌ Mocks everything
+❌ Tests the mock, not behavior
+❌ Vague assertions
+
+### One Thing Only
+
+✅ One assertion per concept
+✅ Clear setup, action, result
+
+❌ Testing multiple behaviors
+❌ Complex setup logic
+
+## Common Anti-patterns
+
+### Skipping the Red
+
+Writing implementation first, then tests. This defeats TDD entirely.
+
+### Too Big Steps
+
+Writing a test that does too much. Break into smaller tests.
+
+### Premature Optimization
+
+Adding features "just in case". Add only what tests require.
+
+### Ignoring Failures
+
+Not verifying the test actually fails. Always watch it fail first.
+
+## Quick Reference
+
+```
+RED: Write test → Run → See it fail
+GREEN: Write minimal code → Run → See it pass
+REFACTOR: Clean up → Run → Ensure still passes
+Repeat.
+```

package/dist/skills/builtin/windows-shell-guide.md

@@ -0,0 +1,119 @@
+---
+name: windows-shell-guide
+description: Windows PowerShell command reference - use on Windows instead of Unix commands
+---
+
+# Windows Shell Guide
+
+**Use when OS is Windows (win32)**
+
+## Forbidden Commands on Windows
+
+**DO NOT use:**
+`head`, `tail`, `grep`, `sed`, `awk`, `xargs`, `wc`, `ls`, `cp`, `mv`, `rm`, `ps`, `kill`, `chmod`, `chown`
+
+## Quick Reference
+
+| Need           | PowerShell Command                   |
+| -------------- | ------------------------------------ |
+| View file      | `Get-Content file`                   |
+| First N lines  | `Get-Content file -Head N`           |
+| Last N lines   | `Get-Content file -Tail N`           |
+| Search text    | `Select-String "pattern" file`       |
+| Count lines    | `(Get-Content file).Count`           |
+| List files     | `Get-ChildItem`                      |
+| Copy file      | `Copy-Item src dest`                 |
+| Move file      | `Move-Item src dest`                 |
+| Delete file    | `Remove-Item file -Force`            |
+| Delete folder  | `Remove-Item folder -Recurse -Force` |
+| List processes | `Get-Process`                        |
+| Kill process   | `Stop-Process -Id PID -Force`        |
+
+## Common Patterns
+
+### File Operations
+
+```powershell
+# Read file
+Get-Content file.txt
+
+# Search in file
+Select-String "error" file.txt
+
+# Count lines
+(Get-Content file.txt).Count
+
+# Find files
+Get-ChildItem -Filter "*.py" -Recurse
+
+# Delete with force
+Remove-Item file.txt -Force
+Remove-Item folder -Recurse -Force
+```
+
+### Process Management
+
+```powershell
+# List processes
+Get-Process python
+
+# Kill process
+Stop-Process -Id 1234 -Force
+
+# Filter processes
+Get-Process | Where-Object {$_.Name -like "python"}
+```
+
+### Pipes and Filtering
+
+```powershell
+# Find files > 1MB
+Get-ChildItem -Recurse | Where-Object {$_.Length -gt 1MB}
+
+# Search in multiple files
+Get-ChildItem -Filter "*.log" | Select-String "ERROR"
+
+# Get top 5 by CPU
+Get-Process | Sort-Object CPU -Descending | Select-Object -First 5
+```
+
+## Common Mistakes
+
+| Unix (DON'T)        | PowerShell (DO)                      |
+| ------------------- | ------------------------------------ |
+| `head file.txt`     | `Get-Content file.txt -Head 10`      |
+| `grep "pattern"`    | `Select-String "pattern"`            |
+| `cat file \| wc -l` | `(Get-Content file).Count`           |
+| `rm -rf folder`     | `Remove-Item folder -Recurse -Force` |
+| `ls -la`            | `Get-ChildItem`                      |
+
+## Safe Execution
+
+```powershell
+# Dry run (preview changes)
+Get-ChildItem folder -Recurse -WhatIf
+
+# Check before delete
+if (Test-Path file.txt) { Remove-Item file.txt }
+
+# Suppress errors
+Get-Content file.txt -ErrorAction SilentlyContinue
+```
+
+## Common Parameters
+
+- `-WhatIf` - Preview changes
+- `-Confirm` - Prompt before execution
+- `-ErrorAction` - Stop, SilentlyContinue, Continue
+- `-Verbose` - Detailed output
+- `-Recurse` - Include subdirectories
+- `-Force` - Override restrictions
+
+## Key Principles
+
+1. Always check OS first
+2. Use PowerShell Verb-Noun syntax
+3. Reference this guide before guessing
+4. Test dangerous operations with `-WhatIf`
+
+**Stop errors before they happen:** Check OS, read guide, execute correctly.