@cubis/foundry 0.3.67 → 0.3.68

package/workflows/workflows/agent-environment-setup/platforms/windsurf/skills/parallel-agents/SKILL.md

@@ -1,175 +0,0 @@
----
-name: parallel-agents
-description: Multi-agent orchestration patterns. Use when multiple independent tasks can run with different domain expertise or when comprehensive analysis requires multiple perspectives.
-allowed-tools: Read, Glob, Grep
----
-
-# Native Parallel Agents
-
-> Orchestration through Antigravity's built-in Agent Tool
-
-## Overview
-
-This skill enables coordinating multiple specialized agents through Antigravity's native agent system. Unlike external scripts, this approach keeps all orchestration within Antigravity's control.
-
-## When to Use Orchestration
-
-✅ **Good for:**
-- Complex tasks requiring multiple expertise domains
-- Code analysis from security, performance, and quality perspectives
-- Comprehensive reviews (architecture + security + testing)
-- Feature implementation needing backend + frontend + database work
-
-❌ **Not for:**
-- Simple, single-domain tasks
-- Quick fixes or small changes
-- Tasks where one agent suffices
-
----
-
-## Native Agent Invocation
-
-### Single Agent
-```
-Use the security-auditor agent to review authentication
-```
-
-### Sequential Chain
-```
-First, use the explorer-agent to discover project structure.
-Then, use the backend-specialist to review API endpoints.
-Finally, use the test-engineer to identify test gaps.
-```
-
-### With Context Passing
-```
-Use the frontend-specialist to analyze React components.
-Based on those findings, have the test-engineer generate component tests.
-```
-
-### Resume Previous Work
-```
-Resume agent [agentId] and continue with additional requirements.
-```
-
----
-
-## Orchestration Patterns
-
-### Pattern 1: Comprehensive Analysis
-```
-Agents: explorer-agent → [domain-agents] → synthesis
-
-1. explorer-agent: Map codebase structure
-2. security-auditor: Security posture
-3. backend-specialist: API quality
-4. frontend-specialist: UI/UX patterns
-5. test-engineer: Test coverage
-6. Synthesize all findings
-```
-
-### Pattern 2: Feature Review
-```
-Agents: affected-domain-agents → test-engineer
-
-1. Identify affected domains (backend? frontend? both?)
-2. Invoke relevant domain agents
-3. test-engineer verifies changes
-4. Synthesize recommendations
-```
-
-### Pattern 3: Security Audit
-```
-Agents: security-auditor → penetration-tester → synthesis
-
-1. security-auditor: Configuration and code review
-2. penetration-tester: Active vulnerability testing
-3. Synthesize with prioritized remediation
-```
-
----
-
-## Available Agents
-
-| Agent | Expertise | Trigger Phrases |
-|-------|-----------|-----------------|
-| `orchestrator` | Coordination | "comprehensive", "multi-perspective" |
-| `security-auditor` | Security | "security", "auth", "vulnerabilities" |
-| `penetration-tester` | Security Testing | "pentest", "red team", "exploit" |
-| `backend-specialist` | Backend | "API", "server", "Node.js", "Express" |
-| `frontend-specialist` | Frontend | "React", "UI", "components", "Next.js" |
-| `test-engineer` | Testing | "tests", "coverage", "TDD" |
-| `devops-engineer` | DevOps | "deploy", "CI/CD", "infrastructure" |
-| `database-architect` | Database | "schema", "Prisma", "migrations" |
-| `mobile-developer` | Mobile | "React Native", "Flutter", "mobile" |
-| `api-designer` | API Design | "REST", "GraphQL", "OpenAPI" |
-| `debugger` | Debugging | "bug", "error", "not working" |
-| `explorer-agent` | Discovery | "explore", "map", "structure" |
-| `documentation-writer` | Documentation | "write docs", "create README", "generate API docs" |
-| `performance-optimizer` | Performance | "slow", "optimize", "profiling" |
-| `project-planner` | Planning | "plan", "roadmap", "milestones" |
-| `seo-specialist` | SEO | "SEO", "meta tags", "search ranking" |
-| `game-developer` | Game Development | "game", "Unity", "Godot", "Phaser" |
-
----
-
-## Antigravity Built-in Agents
-
-These work alongside custom agents:
-
-| Agent | Model | Purpose |
-|-------|-------|---------|
-| **Explore** | Haiku | Fast read-only codebase search |
-| **Plan** | Sonnet | Research during plan mode |
-| **General-purpose** | Sonnet | Complex multi-step modifications |
-
-Use **Explore** for quick searches, **custom agents** for domain expertise.
-
----
-
-## Synthesis Protocol
-
-After all agents complete, synthesize:
-
-```markdown
-## Orchestration Synthesis
-
-### Task Summary
-[What was accomplished]
-
-### Agent Contributions
-| Agent | Finding |
-|-------|---------|
-| security-auditor | Found X |
-| backend-specialist | Identified Y |
-
-### Consolidated Recommendations
-1. **Critical**: [Issue from Agent A]
-2. **Important**: [Issue from Agent B]
-3. **Nice-to-have**: [Enhancement from Agent C]
-
-### Action Items
-- [ ] Fix critical security issue
-- [ ] Refactor API endpoint
-- [ ] Add missing tests
-```
-
----
-
-## Best Practices
-
-1. **Available agents** - 17 specialized agents can be orchestrated
-2. **Logical order** - Discovery → Analysis → Implementation → Testing
-3. **Share context** - Pass relevant findings to subsequent agents
-4. **Single synthesis** - One unified report, not separate outputs
-5. **Verify changes** - Always include test-engineer for code modifications
-
----
-
-## Key Benefits
-
-- ✅ **Single session** - All agents share context
-- ✅ **AI-controlled** - Claude orchestrates autonomously
-- ✅ **Native integration** - Works with built-in Explore, Plan agents
-- ✅ **Resume support** - Can continue previous agent work
-- ✅ **Context passing** - Findings flow between agents

package/workflows/workflows/agent-environment-setup/platforms/windsurf/skills/performance-profiling/SKILL.md

@@ -1,143 +0,0 @@
----
-name: performance-profiling
-description: Performance profiling principles. Measurement, analysis, and optimization techniques.
-allowed-tools: Read, Glob, Grep, Bash
----
-
-# Performance Profiling
-
-> Measure, analyze, optimize - in that order.
-
-## 🔧 Runtime Scripts
-
-**Execute these for automated profiling:**
-
-| Script | Purpose | Usage |
-|--------|---------|-------|
-| `scripts/lighthouse_audit.py` | Lighthouse performance audit | `python scripts/lighthouse_audit.py https://example.com` |
-
----
-
-## 1. Core Web Vitals
-
-### Targets
-
-| Metric | Good | Poor | Measures |
-|--------|------|------|----------|
-| **LCP** | < 2.5s | > 4.0s | Loading |
-| **INP** | < 200ms | > 500ms | Interactivity |
-| **CLS** | < 0.1 | > 0.25 | Stability |
-
-### When to Measure
-
-| Stage | Tool |
-|-------|------|
-| Development | Local Lighthouse |
-| CI/CD | Lighthouse CI |
-| Production | RUM (Real User Monitoring) |
-
----
-
-## 2. Profiling Workflow
-
-### The 4-Step Process
-
-```
-1. BASELINE → Measure current state
-2. IDENTIFY → Find the bottleneck
-3. FIX → Make targeted change
-4. VALIDATE → Confirm improvement
-```
-
-### Profiling Tool Selection
-
-| Problem | Tool |
-|---------|------|
-| Page load | Lighthouse |
-| Bundle size | Bundle analyzer |
-| Runtime | DevTools Performance |
-| Memory | DevTools Memory |
-| Network | DevTools Network |
-
----
-
-## 3. Bundle Analysis
-
-### What to Look For
-
-| Issue | Indicator |
-|-------|-----------|
-| Large dependencies | Top of bundle |
-| Duplicate code | Multiple chunks |
-| Unused code | Low coverage |
-| Missing splits | Single large chunk |
-
-### Optimization Actions
-
-| Finding | Action |
-|---------|--------|
-| Big library | Import specific modules |
-| Duplicate deps | Dedupe, update versions |
-| Route in main | Code split |
-| Unused exports | Tree shake |
-
----
-
-## 4. Runtime Profiling
-
-### Performance Tab Analysis
-
-| Pattern | Meaning |
-|---------|---------|
-| Long tasks (>50ms) | UI blocking |
-| Many small tasks | Possible batching opportunity |
-| Layout/paint | Rendering bottleneck |
-| Script | JavaScript execution |
-
-### Memory Tab Analysis
-
-| Pattern | Meaning |
-|---------|---------|
-| Growing heap | Possible leak |
-| Large retained | Check references |
-| Detached DOM | Not cleaned up |
-
----
-
-## 5. Common Bottlenecks
-
-### By Symptom
-
-| Symptom | Likely Cause |
-|---------|--------------|
-| Slow initial load | Large JS, render blocking |
-| Slow interactions | Heavy event handlers |
-| Jank during scroll | Layout thrashing |
-| Growing memory | Leaks, retained refs |
-
----
-
-## 6. Quick Win Priorities
-
-| Priority | Action | Impact |
-|----------|--------|--------|
-| 1 | Enable compression | High |
-| 2 | Lazy load images | High |
-| 3 | Code split routes | High |
-| 4 | Cache static assets | Medium |
-| 5 | Optimize images | Medium |
-
----
-
-## 7. Anti-Patterns
-
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Guess at problems | Profile first |
-| Micro-optimize | Fix biggest issue |
-| Optimize early | Optimize when needed |
-| Ignore real users | Use RUM data |
-
----
-
-> **Remember:** The fastest code is code that doesn't run. Remove before optimizing.

package/workflows/workflows/agent-environment-setup/platforms/windsurf/skills/performance-profiling/scripts/lighthouse_audit.py

@@ -1,76 +0,0 @@
-#!/usr/bin/env python3
-"""
-Skill: performance-profiling
-Script: lighthouse_audit.py
-Purpose: Run Lighthouse performance audit on a URL
-Usage: python lighthouse_audit.py https://example.com
-Output: JSON with performance scores
-Note: Requires lighthouse CLI (npm install -g lighthouse)
-"""
-import subprocess
-import json
-import sys
-import os
-import tempfile
-
-def run_lighthouse(url: str) -> dict:
-    """Run Lighthouse audit on URL."""
-    try:
-        with tempfile.NamedTemporaryFile(suffix='.json', delete=False) as f:
-            output_path = f.name
-        
-        result = subprocess.run(
-            [
-                "lighthouse",
-                url,
-                "--output=json",
-                f"--output-path={output_path}",
-                "--chrome-flags=--headless",
-                "--only-categories=performance,accessibility,best-practices,seo"
-            ],
-            capture_output=True,
-            text=True,
-            timeout=120
-        )
-        
-        if os.path.exists(output_path):
-            with open(output_path, 'r') as f:
-                report = json.load(f)
-            os.unlink(output_path)
-            
-            categories = report.get("categories", {})
-            return {
-                "url": url,
-                "scores": {
-                    "performance": int(categories.get("performance", {}).get("score", 0) * 100),
-                    "accessibility": int(categories.get("accessibility", {}).get("score", 0) * 100),
-                    "best_practices": int(categories.get("best-practices", {}).get("score", 0) * 100),
-                    "seo": int(categories.get("seo", {}).get("score", 0) * 100)
-                },
-                "summary": get_summary(categories)
-            }
-        else:
-            return {"error": "Lighthouse failed to generate report", "stderr": result.stderr[:500]}
-            
-    except subprocess.TimeoutExpired:
-        return {"error": "Lighthouse audit timed out"}
-    except FileNotFoundError:
-        return {"error": "Lighthouse CLI not found. Install with: npm install -g lighthouse"}
-
-def get_summary(categories: dict) -> str:
-    """Generate summary based on scores."""
-    perf = categories.get("performance", {}).get("score", 0) * 100
-    if perf >= 90:
-        return "[OK] Excellent performance"
-    elif perf >= 50:
-        return "[!] Needs improvement"
-    else:
-        return "[X] Poor performance"
-
-if __name__ == "__main__":
-    if len(sys.argv) < 2:
-        print(json.dumps({"error": "Usage: python lighthouse_audit.py <url>"}))
-        sys.exit(1)
-    
-    result = run_lighthouse(sys.argv[1])
-    print(json.dumps(result, indent=2))

package/workflows/workflows/agent-environment-setup/platforms/windsurf/skills/plan-writing/SKILL.md

@@ -1,152 +0,0 @@
----
-name: plan-writing
-description: Structured task planning with clear breakdowns, dependencies, and verification criteria. Use when implementing features, refactoring, or any multi-step work.
-allowed-tools: Read, Glob, Grep
----
-
-# Plan Writing
-
-> Source: obra/superpowers
-
-## Overview
-This skill provides a framework for breaking down work into clear, actionable tasks with verification criteria.
-
-## Task Breakdown Principles
-
-### 1. Small, Focused Tasks
-- Each task should take 2-5 minutes
-- One clear outcome per task
-- Independently verifiable
-
-### 2. Clear Verification
-- How do you know it's done?
-- What can you check/test?
-- What's the expected output?
-
-### 3. Logical Ordering
-- Dependencies identified
-- Parallel work where possible
-- Critical path highlighted
-- **Phase X: Verification is always LAST**
-
-### 4. Dynamic Naming in Project Root
-- Plan files are saved as `{task-slug}.md` in the PROJECT ROOT
-- Name derived from task (e.g., "add auth" -> auth-feature markdown plan in the project root)
-- **NEVER** inside `.claude/`, `docs/`, or temp folders
-
-## Planning Principles (NOT Templates!)
-
-> 🔴 **NO fixed templates. Each plan is UNIQUE to the task.**
-
-### Principle 1: Keep It SHORT
-
-| ❌ Wrong | ✅ Right |
-|----------|----------|
-| 50 tasks with sub-sub-tasks | 5-10 clear tasks max |
-| Every micro-step listed | Only actionable items |
-| Verbose descriptions | One-line per task |
-
-> **Rule:** If plan is longer than 1 page, it's too long. Simplify.
-
----
-
-### Principle 2: Be SPECIFIC, Not Generic
-
-| ❌ Wrong | ✅ Right |
-|----------|----------|
-| "Set up project" | "Run `npx create-next-app`" |
-| "Add authentication" | "Install next-auth, create `/api/auth/[...nextauth].ts`" |
-| "Style the UI" | "Add Tailwind classes to `Header.tsx`" |
-
-> **Rule:** Each task should have a clear, verifiable outcome.
-
----
-
-### Principle 3: Dynamic Content Based on Project Type
-
-**For NEW PROJECT:**
-- What tech stack? (decide first)
-- What's the MVP? (minimal features)
-- What's the file structure?
-
-**For FEATURE ADDITION:**
-- Which files are affected?
-- What dependencies needed?
-- How to verify it works?
-
-**For BUG FIX:**
-- What's the root cause?
-- What file/line to change?
-- How to test the fix?
-
----
-
-### Principle 4: Scripts Are Project-Specific
-
-> 🔴 **DO NOT copy-paste script commands. Choose based on project type.**
-
-| Project Type | Relevant Scripts |
-|--------------|------------------|
-| Frontend/React | `ux_audit.py`, `accessibility_checker.py` |
-| Backend/API | `api_validator.py`, `security_scan.py` |
-| Mobile | `mobile_audit.py` |
-| Database | `schema_validator.py` |
-| Full-stack | Mix of above based on what you touched |
-
-**Wrong:** Adding all scripts to every plan
-**Right:** Only scripts relevant to THIS task
-
----
-
-### Principle 5: Verification is Simple
-
-| ❌ Wrong | ✅ Right |
-|----------|----------|
-| "Verify the component works correctly" | "Run `npm run dev`, click button, see toast" |
-| "Test the API" | "curl localhost:3000/api/users returns 200" |
-| "Check styles" | "Open browser, verify dark mode toggle works" |
-
----
-
-## Plan Structure (Flexible, Not Fixed!)
-
-```
-# [Task Name]
-
-## Goal
-One sentence: What are we building/fixing?
-
-## Tasks
-- [ ] Task 1: [Specific action] → Verify: [How to check]
-- [ ] Task 2: [Specific action] → Verify: [How to check]
-- [ ] Task 3: [Specific action] → Verify: [How to check]
-
-## Done When
-- [ ] [Main success criteria]
-```
-
-> **That's it.** No phases, no sub-sections unless truly needed.
-> Keep it minimal. Add complexity only when required.
-
-## Notes
-[Any important considerations]
-```
-
----
-
-## Best Practices (Quick Reference)
-
-1. **Start with goal** - What are we building/fixing?
-2. **Max 10 tasks** - If more, break into multiple plans
-3. **Each task verifiable** - Clear "done" criteria
-4. **Project-specific** - No copy-paste templates
-5. **Update as you go** - Mark `[x]` when complete
-
----
-
-## When to Use
-
-- New project from scratch
-- Adding a feature
-- Fixing a bug (if complex)
-- Refactoring multiple files

package/workflows/workflows/agent-environment-setup/platforms/windsurf/skills/playwright-expert/SKILL.md

@@ -1,80 +0,0 @@
----
-name: playwright-expert
-description: Use when writing E2E tests with Playwright, setting up test infrastructure, or debugging flaky browser tests. Invoke for browser automation, E2E tests, Page Object Model, test flakiness, visual testing.
-license: MIT
-metadata:
-  author: https://github.com/Jeffallan
-  version: "1.0.0"
-  domain: quality
-  triggers: Playwright, E2E test, end-to-end, browser testing, automation, UI testing, visual testing
-  role: specialist
-  scope: testing
-  output-format: code
-  related-skills: test-master, react-expert, devops-engineer
----
-
-# Playwright Expert
-
-Senior E2E testing specialist with deep expertise in Playwright for robust, maintainable browser automation.
-
-## Role Definition
-
-You are a senior QA automation engineer with 8+ years of browser testing experience. You specialize in Playwright test architecture, Page Object Model, and debugging flaky tests. You write reliable, fast tests that run in CI/CD.
-
-## When to Use This Skill
-
-- Writing E2E tests with Playwright
-- Setting up Playwright test infrastructure
-- Debugging flaky browser tests
-- Implementing Page Object Model
-- API mocking in browser tests
-- Visual regression testing
-
-## Core Workflow
-
-1. **Analyze requirements** - Identify user flows to test
-2. **Setup** - Configure Playwright with proper settings
-3. **Write tests** - Use POM pattern, proper selectors, auto-waiting
-4. **Debug** - Fix flaky tests, use traces
-5. **Integrate** - Add to CI/CD pipeline
-
-## Reference Guide
-
-Load detailed guidance based on context:
-
-| Topic | Reference | Load When |
-|-------|-----------|-----------|
-| Selectors | `references/selectors-locators.md` | Writing selectors, locator priority |
-| Page Objects | `references/page-object-model.md` | POM patterns, fixtures |
-| API Mocking | `references/api-mocking.md` | Route interception, mocking |
-| Configuration | `references/configuration.md` | playwright.config.ts setup |
-| Debugging | `references/debugging-flaky.md` | Flaky tests, trace viewer |
-
-## Constraints
-
-### MUST DO
-- Use role-based selectors when possible
-- Leverage auto-waiting (don't add arbitrary timeouts)
-- Keep tests independent (no shared state)
-- Use Page Object Model for maintainability
-- Enable traces/screenshots for debugging
-- Run tests in parallel
-
-### MUST NOT DO
-- Use `waitForTimeout()` (use proper waits)
-- Rely on CSS class selectors (brittle)
-- Share state between tests
-- Ignore flaky tests
-- Use `first()`, `nth()` without good reason
-
-## Output Templates
-
-When implementing Playwright tests, provide:
-1. Page Object classes
-2. Test files with proper assertions
-3. Fixture setup if needed
-4. Configuration recommendations
-
-## Knowledge Reference
-
-Playwright, Page Object Model, auto-waiting, locators, fixtures, API mocking, trace viewer, visual comparisons, parallel execution, CI/CD integration