opencode-skills-collection 3.1.11 → 3.1.13

package/bundled-skills/debugging-code/references/installing-debuggers.md

@@ -0,0 +1,67 @@
+# Installing Debug Adapters
+
+`dap` relies on language-specific debug adapters (backends). Many IDEs already ship them — **check before installing**.
+
+---
+
+## Python — debugpy
+
+**Check:** `python3 -m debugpy --version`
+
+**Install:** `pip install debugpy`
+
+**Virtualenv:** `dap` picks up the active venv automatically via `$VIRTUAL_ENV`.
+Activate the venv (`source .venv/bin/activate`) before running `dap debug`, or pass
+`--python /path/to/venv/bin/python` to override. Without either, `dap` falls back
+to `python3` on PATH — which may not have `debugpy` installed or may be the wrong
+interpreter version.
+
+---
+
+## Go — Delve
+
+**Check:** `dlv version`
+
+**Install:**
+- macOS: `brew install delve` (or `go install github.com/go-delve/delve/cmd/dlv@latest`)
+- Linux: `go install github.com/go-delve/delve/cmd/dlv@latest`
+
+macOS note: you may need `sudo DevToolsSecurity -enable` for debugging permissions.
+
+---
+
+## Node.js/TypeScript — js-debug
+
+`dap` auto-discovers js-debug from common locations:
+- VS Code extensions (`~/.vscode/extensions/`)
+- Cursor extensions (`~/.cursor/extensions/`)
+- Standalone install (`~/.dap-cli/js-debug/`)
+
+**Check:** Look for js-debug in the paths above, or run `dap debug --backend js-debug script.js` — if it fails, install below.
+
+**Standalone install** (only if not found above):
+```bash
+DAP_VER=$(curl -fsSL https://api.github.com/repos/microsoft/vscode-js-debug/releases/latest | grep -o '"tag_name":"[^"]*"' | cut -d'"' -f4) && \
+mkdir -p ~/.dap-cli/js-debug && \
+curl -fsSL "https://github.com/microsoft/vscode-js-debug/releases/download/${DAP_VER}/js-debug-dap-${DAP_VER}.tar.gz" | tar -xz -C ~/.dap-cli/js-debug
+```
+
+Also supports **Chrome DevTools debugging** for browser-side JavaScript.
+
+---
+
+## Rust/C/C++ — lldb-dap
+
+**Check:** `lldb-dap --version`
+
+**Install:**
+- macOS: `brew install llvm` (v18+ required)
+- Linux: `apt install lldb` (or equivalent for your distro)
+
+After Homebrew install, ensure the Homebrew `llvm` bin is on your PATH (e.g. `export PATH="$(brew --prefix llvm)/bin:$PATH"`).
+
+---
+
+## Known Gotchas
+
+- **lldb-dap on macOS**: The version bundled with Xcode Command Line Tools (v17) lacks the `--connection` flag that `dap` requires. Use the Homebrew `llvm` package (v18+) instead.

package/bundled-skills/debugging-code/scripts/install-dap.sh

@@ -0,0 +1,87 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+REPO="AlmogBaku/debug-skill"
+BINARY="dap"
+
+go_install_fallback() {
+  if ! command -v go >/dev/null 2>&1; then
+    echo "Error: go is not installed. Install Go from https://go.dev/dl/ and re-run, or download a binary from:"
+    echo "  https://github.com/$REPO/releases/latest"
+    exit 1
+  fi
+  echo "Falling back to go install..."
+  go install "github.com/$REPO/cmd/dap@latest"
+  exit 0
+}
+
+# Detect OS
+OS=$(uname -s | tr '[:upper:]' '[:lower:]')
+case "$OS" in
+  linux)  OS="linux" ;;
+  darwin) OS="darwin" ;;
+  *)
+    echo "Unsupported OS: $OS."
+    go_install_fallback
+    ;;
+esac
+
+# Detect arch
+ARCH=$(uname -m)
+case "$ARCH" in
+  x86_64|amd64)  ARCH="amd64" ;;
+  aarch64|arm64) ARCH="arm64" ;;
+  *)
+    echo "Unsupported architecture: $ARCH."
+    go_install_fallback
+    ;;
+esac
+
+ASSET_NAME="dap-${OS}-${ARCH}"
+
+# Get latest release tag
+LATEST=$(curl -fsSL "https://api.github.com/repos/$REPO/releases/latest" \
+  | grep '"tag_name"' \
+  | sed 's/.*"tag_name": *"\([^"]*\)".*/\1/')
+
+if [ -z "$LATEST" ]; then
+  echo "Could not determine latest release."
+  go_install_fallback
+fi
+
+DOWNLOAD_URL="https://github.com/$REPO/releases/download/$LATEST/$ASSET_NAME"
+
+# Determine install location
+if mkdir -p "$HOME/.local/bin" 2>/dev/null && [ -w "$HOME/.local/bin" ]; then
+  INSTALL_DIR="$HOME/.local/bin"
+elif [ -w "/usr/local/bin" ]; then
+  INSTALL_DIR="/usr/local/bin"
+else
+  echo "Error: no writable install directory found. Try running with sudo or ensure ~/.local/bin is accessible."
+  exit 1
+fi
+
+INSTALL_PATH="$INSTALL_DIR/$BINARY"
+
+echo "Downloading $ASSET_NAME ($LATEST)..."
+if ! curl -fsSL "$DOWNLOAD_URL" -o "$INSTALL_PATH"; then
+  rm -f "$INSTALL_PATH"
+  echo "Download failed."
+  go_install_fallback
+fi
+
+chmod +x "$INSTALL_PATH"
+echo "Installed $BINARY to $INSTALL_PATH"
+
+# Suggest PATH update if needed
+if [[ ":$PATH:" != *":$INSTALL_DIR:"* ]]; then
+  echo ""
+  echo "NOTE: Add $INSTALL_DIR to your PATH."
+  # Suggest the right shell config file
+  case "${SHELL:-}" in
+    */zsh)  RC_FILE="~/.zshrc" ;;
+    */fish) RC_FILE="~/.config/fish/config.fish" ;;
+    *)      RC_FILE="~/.bashrc" ;;
+  esac
+  echo "  echo 'export PATH=\"\$PATH:$INSTALL_DIR\"' >> $RC_FILE"
+fi

package/bundled-skills/deprecation-and-migration/SKILL.md

@@ -0,0 +1,219 @@
+---
+name: deprecation-and-migration
+description: Manages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when deciding whether to maintain or sunset existing code.
+risk: unknown
+source: https://github.com/addyosmani/agent-skills/tree/main/skills/deprecation-and-migration
+source_repo: addyosmani/agent-skills
+source_type: community
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/addyosmani/agent-skills/blob/main/LICENSE
+---
+
+# Deprecation and Migration
+
+## Overview
+
+Code is a liability, not an asset. Every line of code has ongoing maintenance cost — bugs to fix, dependencies to update, security patches to apply, and new engineers to onboard. Deprecation is the discipline of removing code that no longer earns its keep, and migration is the process of moving users safely from the old to the new.
+
+Most engineering organizations are good at building things. Few are good at removing them. This skill addresses that gap.
+
+## When to Use
+
+- Replacing an old system, API, or library with a new one
+- Sunsetting a feature that's no longer needed
+- Consolidating duplicate implementations
+- Removing dead code that nobody owns but everybody depends on
+- Planning the lifecycle of a new system (deprecation planning starts at design time)
+- Deciding whether to maintain a legacy system or invest in migration
+
+## Core Principles
+
+### Code Is a Liability
+
+Every line of code has ongoing cost: it needs tests, documentation, security patches, dependency updates, and mental overhead for anyone working nearby. The value of code is the functionality it provides, not the code itself. When the same functionality can be provided with less code, less complexity, or better abstractions — the old code should go.
+
+### Hyrum's Law Makes Removal Hard
+
+With enough users, every observable behavior becomes depended on — including bugs, timing quirks, and undocumented side effects. This is why deprecation requires active migration, not just announcement. Users can't "just switch" when they depend on behaviors the replacement doesn't replicate.
+
+### Deprecation Planning Starts at Design Time
+
+When building something new, ask: "How would we remove this in 3 years?" Systems designed with clean interfaces, feature flags, and minimal surface area are easier to deprecate than systems that leak implementation details everywhere.
+
+## The Deprecation Decision
+
+Before deprecating anything, answer these questions:
+
+```
+1. Does this system still provide unique value?
+   → If yes, maintain it. If no, proceed.
+
+2. How many users/consumers depend on it?
+   → Quantify the migration scope.
+
+3. Does a replacement exist?
+   → If no, build the replacement first. Don't deprecate without an alternative.
+
+4. What's the migration cost for each consumer?
+   → If trivially automated, do it. If manual and high-effort, weigh against maintenance cost.
+
+5. What's the ongoing maintenance cost of NOT deprecating?
+   → Security risk, engineer time, opportunity cost of complexity.
+```
+
+## Compulsory vs Advisory Deprecation
+
+| Type | When to Use | Mechanism |
+|------|-------------|-----------|
+| **Advisory** | Migration is optional, old system is stable | Warnings, documentation, nudges. Users migrate on their own timeline. |
+| **Compulsory** | Old system has security issues, blocks progress, or maintenance cost is unsustainable | Hard deadline. Old system will be removed by date X. Provide migration tooling. |
+
+**Default to advisory.** Use compulsory only when the maintenance cost or risk justifies forcing migration. Compulsory deprecation requires providing migration tooling, documentation, and support — you can't just announce a deadline.
+
+## The Migration Process
+
+### Step 1: Build the Replacement
+
+Don't deprecate without a working alternative. The replacement must:
+
+- Cover all critical use cases of the old system
+- Have documentation and migration guides
+- Be proven in production (not just "theoretically better")
+
+### Step 2: Announce and Document
+
+```markdown
+## Deprecation Notice: OldService
+
+**Status:** Deprecated as of 2025-03-01
+**Replacement:** NewService (see migration guide below)
+**Removal date:** Advisory — no hard deadline yet
+**Reason:** OldService requires manual scaling and lacks observability.
+            NewService handles both automatically.
+
+### Migration Guide
+1. Replace `import { client } from 'old-service'` with `import { client } from 'new-service'`
+2. Update configuration (see examples below)
+3. Run the migration verification script: `npx migrate-check`
+```
+
+### Step 3: Migrate Incrementally
+
+Migrate consumers one at a time, not all at once. For each consumer:
+
+```
+1. Identify all touchpoints with the deprecated system
+2. Update to use the replacement
+3. Verify behavior matches (tests, integration checks)
+4. Remove references to the old system
+5. Confirm no regressions
+```
+
+**The Churn Rule:** If you own the infrastructure being deprecated, you are responsible for migrating your users — or providing backward-compatible updates that require no migration. Don't announce deprecation and leave users to figure it out.
+
+### Step 4: Remove the Old System
+
+Only after all consumers have migrated:
+
+```
+1. Verify zero active usage (metrics, logs, dependency analysis)
+2. Remove the code
+3. Remove associated tests, documentation, and configuration
+4. Remove the deprecation notices
+5. Celebrate — removing code is an achievement
+```
+
+## Migration Patterns
+
+### Strangler Pattern
+
+Run old and new systems in parallel. Route traffic incrementally from old to new. When the old system handles 0% of traffic, remove it.
+
+```
+Phase 1: New system handles 0%, old handles 100%
+Phase 2: New system handles 10% (canary)
+Phase 3: New system handles 50%
+Phase 4: New system handles 100%, old system idle
+Phase 5: Remove old system
+```
+
+### Adapter Pattern
+
+Create an adapter that translates calls from the old interface to the new implementation. Consumers keep using the old interface while you migrate the backend.
+
+```typescript
+// Adapter: old interface, new implementation
+class LegacyTaskService implements OldTaskAPI {
+  constructor(private newService: NewTaskService) {}
+
+  // Old method signature, delegates to new implementation
+  getTask(id: number): OldTask {
+    const task = this.newService.findById(String(id));
+    return this.toOldFormat(task);
+  }
+}
+```
+
+### Feature Flag Migration
+
+Use feature flags to switch consumers from old to new system one at a time:
+
+```typescript
+function getTaskService(userId: string): TaskService {
+  if (featureFlags.isEnabled('new-task-service', { userId })) {
+    return new NewTaskService();
+  }
+  return new LegacyTaskService();
+}
+```
+
+## Zombie Code
+
+Zombie code is code that nobody owns but everybody depends on. It's not actively maintained, has no clear owner, and accumulates security vulnerabilities and compatibility issues. Signs:
+
+- No commits in 6+ months but active consumers exist
+- No assigned maintainer or team
+- Failing tests that nobody fixes
+- Dependencies with known vulnerabilities that nobody updates
+- Documentation that references systems that no longer exist
+
+**Response:** Either assign an owner and maintain it properly, or deprecate it with a concrete migration plan. Zombie code cannot stay in limbo — it either gets investment or removal.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "It still works, why remove it?" | Working code that nobody maintains accumulates security debt and complexity. Maintenance cost grows silently. |
+| "Someone might need it later" | If it's needed later, it can be rebuilt. Keeping unused code "just in case" costs more than rebuilding. |
+| "The migration is too expensive" | Compare migration cost to ongoing maintenance cost over 2-3 years. Migration is usually cheaper long-term. |
+| "We'll deprecate it after we finish the new system" | Deprecation planning starts at design time. By the time the new system is done, you'll have new priorities. Plan now. |
+| "Users will migrate on their own" | They won't. Provide tooling, documentation, and incentives — or do the migration yourself (the Churn Rule). |
+| "We can maintain both systems indefinitely" | Two systems doing the same thing is double the maintenance, testing, documentation, and onboarding cost. |
+
+## Red Flags
+
+- Deprecated systems with no replacement available
+- Deprecation announcements with no migration tooling or documentation
+- "Soft" deprecation that's been advisory for years with no progress
+- Zombie code with no owner and active consumers
+- New features added to a deprecated system (invest in the replacement instead)
+- Deprecation without measuring current usage
+- Removing code without verifying zero active consumers
+
+## Verification
+
+After completing a deprecation:
+
+- [ ] Replacement is production-proven and covers all critical use cases
+- [ ] Migration guide exists with concrete steps and examples
+- [ ] All active consumers have been migrated (verified by metrics/logs)
+- [ ] Old code, tests, documentation, and configuration are fully removed
+- [ ] No references to the deprecated system remain in the codebase
+- [ ] Deprecation notices are removed (they served their purpose)
+
+## Limitations
+
+- Use this skill only when the task clearly matches its upstream source and local project context.
+- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
+- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.

package/bundled-skills/design-philosophy/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: design-philosophy
+description: Visual philosophy and art-direction for frontend. Use when creating high-concept work, campaigns, or when the user asks for a visual philosophy, manifesto, or unmistakable art-like aesthetic.
+risk: unknown
+source: https://github.com/connerkward/ckw-design-skill/tree/main/design-philosophy
+source_repo: connerkward/ckw-design-skill
+source_type: community
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/connerkward/ckw-design-skill/blob/main/LICENSE
+author: Conner K Ward
+---
+
+# Design philosophy
+## When to Use
+
+Use this skill when you need visual philosophy and art-direction for frontend. Use when creating high-concept work, campaigns, or when the user asks for a visual philosophy, manifesto, or unmistakable art-like aesthetic.
+
+
+Apply with **design** for high-concept work, campaigns, or when the user asks for a visual philosophy, manifesto, or art-like aesthetic. This skill guides creating a named movement and expressing it visually.
+
+## Visual philosophy (when creating "art" or high-concept work)
+
+1. **Name the movement** (1–2 words): e.g. "Brutalist Joy," "Chromatic Silence," "Metabolist Dreams."
+2. **Articulate in 4–6 paragraphs** how the philosophy manifests through: space and form; color and material; scale and rhythm; composition and balance; visual hierarchy. Avoid redundancy; each aspect once.
+3. **Craftsmanship**: Stress that the work should look meticulously crafted, labored over with care, the product of deep expertise — "painstaking attention," "master-level execution." Repeat this framing.
+4. **Minimal text**: Information lives in design, not paragraphs. Text sparse and essential; integrated as visual element.
+5. **Creative space**: Be specific about direction but concise so the executor can make high-level interpretive choices with the same level of craft.
+
+For philosophy examples, see [reference.md](reference.md). The numbered checklist above is the canonical generation procedure.
+
+## Deducing the subtle reference
+
+Before building: identify one subtle conceptual thread from the request. The topic is a subtle, niche reference embedded in the work — not literal, always sophisticated. Someone familiar with the subject should feel it intuitively; others experience a strong abstract composition. Weave it into form, color, and composition. "Jazz quote" principle: only those who know catch it; everyone benefits.
+
+## Limitations
+
+- Use this skill only when the task clearly matches its upstream source and local project context.
+- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
+- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.

package/bundled-skills/design-philosophy/reference.md

@@ -0,0 +1,19 @@
+# Design philosophy reference
+
+Use when doing philosophy-heavy or art-direction work.
+
+## Philosophy examples (condensed)
+
+**Concrete Poetry** — Communication through monumental form and bold geometry. Massive color blocks, sculptural typography (huge single words, tiny labels), Brutalist spatial divisions. Polish poster energy meets Le Corbusier. Text as rare, powerful gesture — never paragraphs, only essential words in the visual architecture.
+
+**Chromatic Language** — Color as the primary information system. Geometric precision; color zones create meaning. Typography minimal — small sans-serif labels; chromatic fields communicate. Josef Albers' interaction meets data viz. Words only to anchor what color already shows.
+
+**Analog Meditation** — Quiet visual contemplation through texture and breathing room. Paper grain, ink bleeds, vast negative space. Photography and illustration dominate. Typography whispered (small, restrained). Japanese photobook aesthetic. Text sparingly — short phrases, never explanatory blocks.
+
+**Organic Systems** — Natural clustering and modular growth. Rounded forms, organic arrangements, color from nature and architecture. Information through diagrams, spatial relationships, iconography. Text only for key labels floating in space.
+
+**Geometric Silence** — Pure order and restraint. Grid-based precision, bold photography or stark graphics, dramatic negative space. Typography precise but minimal — small essential text, large quiet zones. Swiss formalism meets Brutalist material honesty. Structure communicates, not words.
+
+---
+
+How to *generate* a philosophy: the canonical numbered checklist lives in [SKILL.md](SKILL.md) (name the movement → 4–6 paragraphs → craftsmanship framing → minimal text → creative space).