@cubis/foundry 0.3.66 → 0.3.68

package/workflows/skills/architecture-designer/references/system-design.md

@@ -1,103 +0,0 @@
-# System Design Template
-
-> Reference for: Architecture Designer
-> Load when: Designing new systems
-
-## Design Template
-
-```markdown
-# System: {System Name}
-
-## Requirements
-
-### Functional
-- [What the system must do]
-- [Core features and capabilities]
-
-### Non-Functional
-- **Performance**: Response time < 200ms p95
-- **Availability**: 99.9% uptime (8.76 hours downtime/year)
-- **Scalability**: Support 10,000 concurrent users
-- **Security**: PCI DSS compliance required
-
-### Constraints
-- Budget: $X/month for infrastructure
-- Timeline: MVP in 3 months
-- Team: 5 backend, 3 frontend engineers
-
-## High-Level Architecture
-
-```
-┌─────────────┐     ┌─────────────┐     ┌─────────────┐
-│   Client    │────▶│  API Gateway │────▶│  Service    │
-│   (Web)     │     │   (Kong)    │     │  (Node.js)  │
-└─────────────┘     └─────────────┘     └─────────────┘
-                           │                   │
-                           ▼                   ▼
-                    ┌─────────────┐     ┌─────────────┐
-                    │    Auth     │     │  Database   │
-                    │  (Auth0)    │     │ (PostgreSQL)│
-                    └─────────────┘     └─────────────┘
-```
-
-## Component Details
-
-### API Layer
-- Technology: Node.js with Express/NestJS
-- Responsibilities: Request routing, validation, auth
-- Scaling: Horizontal via load balancer
-
-### Data Layer
-- Primary: PostgreSQL (transactions, relationships)
-- Cache: Redis (sessions, hot data)
-- Storage: S3 (files, images)
-
-### External Services
-- Auth: Auth0 (SSO, MFA)
-- Email: SendGrid (transactional)
-- Monitoring: Datadog (APM, logs)
-
-## Key Decisions
-
-| Decision | Rationale |
-|----------|-----------|
-| PostgreSQL over MongoDB | Relational data, ACID needed |
-| Redis for caching | Sub-ms latency required |
-| Auth0 over custom | Reduce security risk |
-
-## Scaling Strategy
-
-### Current (MVP)
-- Single region deployment
-- 2 API instances behind ALB
-- Single RDS instance
-
-### Future (10x growth)
-- Multi-region with CDN
-- Auto-scaling API (2-10 instances)
-- RDS read replicas
-
-## Security Considerations
-- All traffic over TLS 1.3
-- JWT tokens with 15-min expiry
-- Rate limiting: 100 req/min per user
-- WAF for common attacks
-
-## Failure Modes
-
-| Failure | Impact | Mitigation |
-|---------|--------|------------|
-| DB down | Full outage | Multi-AZ failover |
-| Cache down | Degraded perf | Fallback to DB |
-| Auth down | No new logins | Cache valid tokens |
-```
-
-## Quick Reference
-
-| Section | Key Questions |
-|---------|---------------|
-| Requirements | What must it do? How well? |
-| Architecture | What components? How connected? |
-| Decisions | Why these choices? |
-| Scaling | How to grow? |
-| Failures | What can break? How to recover? |

package/workflows/skills/ask-questions-if-underspecified/SKILL.md

@@ -1,85 +0,0 @@
----
-name: ask-questions-if-underspecified
-description: Clarify requirements before implementing. Use when serious doubts arise.
----
-
-# Ask Questions If Underspecified
-
-## When to Use
-
-Use this skill when a request has multiple plausible interpretations or key details (objective, scope, constraints, environment, or safety) are unclear.
-
-## When NOT to Use
-
-Do not use this skill when the request is already clear, or when a quick, low-risk discovery read can answer the missing details.
-
-## Goal
-
-Ask the minimum set of clarifying questions needed to avoid wrong work; do not start implementing until the must-have questions are answered (or the user explicitly approves proceeding with stated assumptions).
-
-## Workflow
-
-### 1) Decide whether the request is underspecified
-
-Treat a request as underspecified if after exploring how to perform the work, some or all of the following are not clear:
-- Define the objective (what should change vs stay the same)
-- Define "done" (acceptance criteria, examples, edge cases)
-- Define scope (which files/components/users are in/out)
-- Define constraints (compatibility, performance, style, deps, time)
-- Identify environment (language/runtime versions, OS, build/test runner)
-- Clarify safety/reversibility (data migration, rollout/rollback, risk)
-
-If multiple plausible interpretations exist, assume it is underspecified.
-
-### 2) Ask must-have questions first (keep it small)
-
-Ask 1-5 questions in the first pass. Prefer questions that eliminate whole branches of work.
-
-Make questions easy to answer:
-- Optimize for scannability (short, numbered questions; avoid paragraphs)
-- Offer multiple-choice options when possible
-- Suggest reasonable defaults when appropriate (mark them clearly as the default/recommended choice; bold the recommended choice in the list, or if you present options in a code block, put a bold "Recommended" line immediately above the block and also tag defaults inside the block)
-- Include a fast-path response (e.g., reply `defaults` to accept all recommended/default choices)
-- Include a low-friction "not sure" option when helpful (e.g., "Not sure - use default")
-- Separate "Need to know" from "Nice to know" if that reduces friction
-- Structure options so the user can respond with compact decisions (e.g., `1b 2a 3c`); restate the chosen options in plain language to confirm
-
-### 3) Pause before acting
-
-Until must-have answers arrive:
-- Do not run commands, edit files, or produce a detailed plan that depends on unknowns
-- Do perform a clearly labeled, low-risk discovery step only if it does not commit you to a direction (e.g., inspect repo structure, read relevant config files)
-
-If the user explicitly asks you to proceed without answers:
-- State your assumptions as a short numbered list
-- Ask for confirmation; proceed only after they confirm or correct them
-
-### 4) Confirm interpretation, then proceed
-
-Once you have answers, restate the requirements in 1-3 sentences (including key constraints and what success looks like), then start work.
-
-## Question templates
-
-- "Before I start, I need: (1) ..., (2) ..., (3) .... If you don't care about (2), I will assume ...."
-- "Which of these should it be? A) ... B) ... C) ... (pick one)"
-- "What would you consider 'done'? For example: ..."
-- "Any constraints I must follow (versions, performance, style, deps)? If none, I will target the existing project defaults."
-- Use numbered questions with lettered options and a clear reply format
-
-```text
-1) Scope?
-a) Minimal change (default)
-b) Refactor while touching the area
-c) Not sure - use default
-2) Compatibility target?
-a) Current project defaults (default)
-b) Also support older versions: <specify>
-c) Not sure - use default
-
-Reply with: defaults (or 1a 2a)
-```
-
-## Anti-patterns
-
-- Don't ask questions you can answer with a quick, low-risk discovery read (e.g., configs, existing patterns, docs).
-- Don't ask open-ended questions if a tight multiple-choice or yes/no would eliminate ambiguity faster.

package/workflows/skills/bash-linux/SKILL.md

@@ -1,199 +0,0 @@
----
-name: bash-linux
-description: Bash/Linux terminal patterns. Critical commands, piping, error handling, scripting. Use when working on macOS or Linux systems.
-allowed-tools: Read, Write, Edit, Glob, Grep, Bash
----
-
-# Bash Linux Patterns
-
-> Essential patterns for Bash on Linux/macOS.
-
----
-
-## 1. Operator Syntax
-
-### Chaining Commands
-
-| Operator | Meaning | Example |
-|----------|---------|---------|
-| `;` | Run sequentially | `cmd1; cmd2` |
-| `&&` | Run if previous succeeded | `npm install && npm run dev` |
-| `\|\|` | Run if previous failed | `npm test \|\| echo "Tests failed"` |
-| `\|` | Pipe output | `ls \| grep ".js"` |
-
----
-
-## 2. File Operations
-
-### Essential Commands
-
-| Task | Command |
-|------|---------|
-| List all | `ls -la` |
-| Find files | `find . -name "*.js" -type f` |
-| File content | `cat file.txt` |
-| First N lines | `head -n 20 file.txt` |
-| Last N lines | `tail -n 20 file.txt` |
-| Follow log | `tail -f log.txt` |
-| Search in files | `grep -r "pattern" --include="*.js"` |
-| File size | `du -sh *` |
-| Disk usage | `df -h` |
-
----
-
-## 3. Process Management
-
-| Task | Command |
-|------|---------|
-| List processes | `ps aux` |
-| Find by name | `ps aux \| grep node` |
-| Kill by PID | `kill -9 <PID>` |
-| Find port user | `lsof -i :3000` |
-| Kill port | `kill -9 $(lsof -t -i :3000)` |
-| Background | `npm run dev &` |
-| Jobs | `jobs -l` |
-| Bring to front | `fg %1` |
-
----
-
-## 4. Text Processing
-
-### Core Tools
-
-| Tool | Purpose | Example |
-|------|---------|---------|
-| `grep` | Search | `grep -rn "TODO" src/` |
-| `sed` | Replace | `sed -i 's/old/new/g' file.txt` |
-| `awk` | Extract columns | `awk '{print $1}' file.txt` |
-| `cut` | Cut fields | `cut -d',' -f1 data.csv` |
-| `sort` | Sort lines | `sort -u file.txt` |
-| `uniq` | Unique lines | `sort file.txt \| uniq -c` |
-| `wc` | Count | `wc -l file.txt` |
-
----
-
-## 5. Environment Variables
-
-| Task | Command |
-|------|---------|
-| View all | `env` or `printenv` |
-| View one | `echo $PATH` |
-| Set temporary | `export VAR="value"` |
-| Set in script | `VAR="value" command` |
-| Add to PATH | `export PATH="$PATH:/new/path"` |
-
----
-
-## 6. Network
-
-| Task | Command |
-|------|---------|
-| Download | `curl -O https://example.com/file` |
-| API request | `curl -X GET https://api.example.com` |
-| POST JSON | `curl -X POST -H "Content-Type: application/json" -d '{"key":"value"}' URL` |
-| Check port | `nc -zv localhost 3000` |
-| Network info | `ifconfig` or `ip addr` |
-
----
-
-## 7. Script Template
-
-```bash
-#!/bin/bash
-set -euo pipefail  # Exit on error, undefined var, pipe fail
-
-# Colors (optional)
-RED='\033[0;31m'
-GREEN='\033[0;32m'
-NC='\033[0m'
-
-# Script directory
-SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-
-# Functions
-log_info() { echo -e "${GREEN}[INFO]${NC} $1"; }
-log_error() { echo -e "${RED}[ERROR]${NC} $1" >&2; }
-
-# Main
-main() {
-    log_info "Starting..."
-    # Your logic here
-    log_info "Done!"
-}
-
-main "$@"
-```
-
----
-
-## 8. Common Patterns
-
-### Check if command exists
-
-```bash
-if command -v node &> /dev/null; then
-    echo "Node is installed"
-fi
-```
-
-### Default variable value
-
-```bash
-NAME=${1:-"default_value"}
-```
-
-### Read file line by line
-
-```bash
-while IFS= read -r line; do
-    echo "$line"
-done < file.txt
-```
-
-### Loop over files
-
-```bash
-for file in *.js; do
-    echo "Processing $file"
-done
-```
-
----
-
-## 9. Differences from PowerShell
-
-| Task | PowerShell | Bash |
-|------|------------|------|
-| List files | `Get-ChildItem` | `ls -la` |
-| Find files | `Get-ChildItem -Recurse` | `find . -type f` |
-| Environment | `$env:VAR` | `$VAR` |
-| String concat | `"$a$b"` | `"$a$b"` (same) |
-| Null check | `if ($x)` | `if [ -n "$x" ]` |
-| Pipeline | Object-based | Text-based |
-
----
-
-## 10. Error Handling
-
-### Set options
-
-```bash
-set -e          # Exit on error
-set -u          # Exit on undefined variable
-set -o pipefail # Exit on pipe failure
-set -x          # Debug: print commands
-```
-
-### Trap for cleanup
-
-```bash
-cleanup() {
-    echo "Cleaning up..."
-    rm -f /tmp/tempfile
-}
-trap cleanup EXIT
-```
-
----
-
-> **Remember:** Bash is text-based. Use `&&` for success chains, `set -e` for safety, and quote your variables!

package/workflows/skills/behavioral-modes/SKILL.md

@@ -1,242 +0,0 @@
----
-name: behavioral-modes
-description: AI operational modes (brainstorm, implement, debug, review, teach, ship, orchestrate). Use to adapt behavior based on task type.
-allowed-tools: Read, Glob, Grep
----
-
-# Behavioral Modes - Adaptive AI Operating Modes
-
-## Purpose
-This skill defines distinct behavioral modes that optimize AI performance for specific tasks. Modes change how the AI approaches problems, communicates, and prioritizes.
-
----
-
-## Available Modes
-
-### 1. 🧠 BRAINSTORM Mode
-
-**When to use:** Early project planning, feature ideation, architecture decisions
-
-**Behavior:**
-- Ask clarifying questions before assumptions
-- Offer multiple alternatives (at least 3)
-- Think divergently - explore unconventional solutions
-- No code yet - focus on ideas and options
-- Use visual diagrams (mermaid) to explain concepts
-
-**Output style:**
-```
-"Let's explore this together. Here are some approaches:
-
-Option A: [description]
-  ✅ Pros: ...
-  ❌ Cons: ...
-
-Option B: [description]
-  ✅ Pros: ...
-  ❌ Cons: ...
-
-What resonates with you? Or should we explore a different direction?"
-```
-
----
-
-### 2. ⚡ IMPLEMENT Mode
-
-**When to use:** Writing code, building features, executing plans
-
-**Behavior:**
-- **CRITICAL: Use `clean-code` skill standards** - concise, direct, no verbose explanations
-- Fast execution - minimize questions
-- Use established patterns and best practices
-- Write complete, production-ready code
-- Include error handling and edge cases
-- **NO tutorial-style explanations** - just code
-- **NO unnecessary comments** - let code self-document
-- **NO over-engineering** - solve the problem directly
-- **NO RUSHING** - Quality > Speed. Read ALL references before coding.
-
-**Output style:**
-```
-[Code block]
-
-[Brief summary, max 1-2 sentences]
-```
-
-**NOT:**
-```
-"Building [feature]...
-
-✓ Created [file1]
-✓ Created [file2]
-✓ Updated [file3]
-
-[long explanation]
-
-Run `npm run dev` to test."
-```
-
----
-
-### 3. 🔍 DEBUG Mode
-
-**When to use:** Fixing bugs, troubleshooting errors, investigating issues
-
-**Behavior:**
-- Ask for error messages and reproduction steps
-- Think systematically - check logs, trace data flow
-- Form hypothesis → test → verify
-- Explain the root cause, not just the fix
-- Prevent future occurrences
-
-**Output style:**
-```
-"Investigating...
-
-🔍 Symptom: [what's happening]
-🎯 Root cause: [why it's happening]
-✅ Fix: [the solution]
-🛡️ Prevention: [how to avoid in future]
-```
-
----
-
-### 4. 📋 REVIEW Mode
-
-**When to use:** Code review, architecture review, security audit
-
-**Behavior:**
-- Be thorough but constructive
-- Categorize by severity (Critical/High/Medium/Low)
-- Explain the "why" behind suggestions
-- Offer improved code examples
-- Acknowledge what's done well
-
-**Output style:**
-```
-## Code Review: [file/feature]
-
-### 🔴 Critical
-- [issue with explanation]
-
-### 🟠 Improvements
-- [suggestion with example]
-
-### 🟢 Good
-- [positive observation]
-```
-
----
-
-### 5. 📚 TEACH Mode
-
-**When to use:** Explaining concepts, documentation, onboarding
-
-**Behavior:**
-- Explain from fundamentals
-- Use analogies and examples
-- Progress from simple to complex
-- Include practical exercises
-- Check understanding
-
-**Output style:**
-```
-## Understanding [Concept]
-
-### What is it?
-[Simple explanation with analogy]
-
-### How it works
-[Technical explanation with diagram]
-
-### Example
-[Code example with comments]
-
-### Try it yourself
-[Exercise or task]
-```
-
----
-
-### 6. 🚀 SHIP Mode
-
-**When to use:** Production deployment, final polish, release preparation
-
-**Behavior:**
-- Focus on stability over features
-- Check for missing error handling
-- Verify environment configs
-- Run all tests
-- Create deployment checklist
-
-**Output style:**
-```
-## Pre-Ship Checklist
-
-### ✅ Code Quality
-- [ ] No TypeScript errors
-- [ ] ESLint passing
-- [ ] All tests passing
-
-### ✅ Security
-- [ ] No exposed secrets
-- [ ] Input validation complete
-
-### ✅ Performance
-- [ ] Bundle size acceptable
-- [ ] No console.logs
-
-### 🚀 Ready to deploy
-```
-
----
-
-## Mode Detection
-
-The AI should automatically detect the appropriate mode based on:
-
-| Trigger | Mode |
-|---------|------|
-| "what if", "ideas", "options" | BRAINSTORM |
-| "build", "create", "add" | IMPLEMENT |
-| "not working", "error", "bug" | DEBUG |
-| "review", "check", "audit" | REVIEW |
-| "explain", "how does", "learn" | TEACH |
-| "deploy", "release", "production" | SHIP |
-
----
-
-## Multi-Agent Collaboration Patterns (2025)
-
-Modern architectures optimized for agent-to-agent collaboration:
-
-### 1. 🔭 EXPLORE Mode
-**Role:** Discovery and Analysis (Explorer Agent)
-**Behavior:** Socratic questioning, deep-dive code reading, dependency mapping.
-**Output:** `discovery-report.json`, architectural visualization.
-
-### 2. 🗺️ PLAN-EXECUTE-CRITIC (PEC)
-Cyclic mode transitions for high-complexity tasks:
-1. **Planner:** Decomposes the task into atomic steps (task handoff or planning artifact).
-2. **Executor:** Performs the actual coding (`IMPLEMENT`).
-3. **Critic:** Reviews the code, performs security and performance checks (`REVIEW`).
-
-### 3. 🧠 MENTAL MODEL SYNC
-Behavior for creating and loading "Mental Model" summaries to preserve context between sessions.
-
----
-
-## Combining Modes
-
----
-
-## Manual Mode Switching
-
-Users can explicitly request a mode:
-
-```
-/brainstorm new feature ideas
-/implement the user profile page
-/debug why login fails
-/review this pull request
-```