skill-library-mcp 1.0.0

package/skills/unreal-engine-cpp-pro/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: unreal-engine-cpp-pro
+description: Expert guide for Unreal Engine 5.x C++ development, covering UObject hygiene, performance patterns, and best practices.
+risk: safe
+source: self
+---
+
+# Unreal Engine C++ Pro
+
+This skill provides expert-level guidelines for developing with Unreal Engine 5 using C++. It focuses on writing robust, performant, and standard-compliant code.
+
+## When to Use
+
+Use this skill when:
+- Developing C++ code for Unreal Engine 5.x projects
+- Writing Actors, Components, or UObject-derived classes
+- Optimizing performance-critical code in Unreal Engine
+- Debugging memory leaks or garbage collection issues
+- Implementing Blueprint-exposed functionality
+- Following Epic Games' coding standards and conventions
+- Working with Unreal's reflection system (UCLASS, USTRUCT, UFUNCTION)
+- Managing asset loading and soft references
+
+Do not use this skill when:
+- Working with Blueprint-only projects (no C++ code)
+- Developing for Unreal Engine versions prior to 5.x
+- Working on non-Unreal game engines
+- The task is unrelated to Unreal Engine development
+
+## Core Principles
+
+1.  **UObject & Garbage Collection**:
+    *   Always use `UPROPERTY()` for `UObject*` member variables to ensure they are tracked by the Garbage Collector (GC).
+    *   Use `TStrongObjectPtr<>` if you need to keep a root reference outside of a UObject graph, but prefer `addToRoot()` generally.
+    *   Understand the `IsValid()` check vs `nullptr`. `IsValid()` handles pending kill state safely.
+
+2.  **Unreal Reflection System**:
+    *   Use `UCLASS()`, `USTRUCT()`, `UENUM()`, `UFUNCTION()` to expose types to the reflection system and Blueprints.
+    *   Minimize `BlueprintReadWrite` when possible; prefer `BlueprintReadOnly` for state that shouldn't be trampled by logic in UI/Level BPs.
+
+3.  **Performance First**:
+    *   **Tick**: Disable Ticking (`bCanEverTick = false`) by default. Only enable it if absolutely necessary. Prefer timers (`GetWorldTimerManager()`) or event-driven logic.
+    *   **Casting**: Avoid `Cast<T>()` in hot loops. Cache references in `BeginPlay`.
+    *   **Structs vs Classes**: Use `F` structs for data-heavy, non-UObject types to reduce overhead.
+
+## Naming Conventions (Strict)
+
+Follow Epic Games' coding standard:
+
+*   **Templates**: Prefix with `T` (e.g., `TArray`, `TMap`).
+*   **UObject**: Prefix with `U` (e.g., `UCharacterMovementComponent`).
+*   **AActor**: Prefix with `A` (e.g., `AMyGameMode`).
+*   **SWidget**: Prefix with `S` (Slate widgets).
+*   **Structs**: Prefix with `F` (e.g., `FVector`).
+*   **Enums**: Prefix with `E` (e.g., `EWeaponState`).
+*   **Interfaces**: Prefix with `I` (e.g., `IInteractable`).
+*   **Booleans**: Prefix with `b` (e.g., `bIsDead`).
+
+## Common Patterns
+
+### 1. Robust Component Lookup
+Avoid `GetComponentByClass` in `Tick`. Do it in `PostInitializeComponents` or `BeginPlay`.
+
+```cpp
+void AMyCharacter::PostInitializeComponents() {
+    Super::PostInitializeComponents();
+    HealthComp = FindComponentByClass<UHealthComponent>();
+    check(HealthComp); // Fail hard in dev if missing
+}
+```
+
+### 2. Interface Implementation
+Use interfaces to decouple systems (e.g., Interaction system).
+
+```cpp
+// Interface call check
+if (TargetActor->Implements<UInteractable>()) {
+    IInteractable::Execute_OnInteract(TargetActor, this);
+}
+```
+
+### 3. Async Loading (Soft References)
+Avoid hard references (`UPROPERTY(EditDefaultsOnly) TSubclassOf<AActor>`) for massive assets which force load orders. Use `TSoftClassPtr` or `TSoftObjectPtr`.
+
+```cpp
+UPROPERTY(EditAnywhere, BlueprintReadWrite)
+TSoftClassPtr<AWeapon> WeaponClassToLoad;
+
+void AMyCharacter::Equip() {
+    if (WeaponClassToLoad.IsPending()) {
+        WeaponClassToLoad.LoadSynchronous(); // Or use StreamableManager for async
+    }
+}
+```
+
+## Debugging
+
+*   **Logging**: Use `UE_LOG` with custom categories.
+    ```cpp
+    DEFINE_LOG_CATEGORY_STATIC(LogMyGame, Log, All);
+    UE_LOG(LogMyGame, Warning, TEXT("Health is low: %f"), CurrentHealth);
+    ```
+*   **Screen Messages**:
+    ```cpp
+    if (GEngine) GEngine->AddOnScreenDebugMessage(-1, 5.f, FColor::Red, TEXT("Died!"));
+    ```
+*   **Visual Logger**: extremely useful for AI debugging. Implement `IVisualLoggerDebugSnapshotInterface`.
+
+## Checklist before PR
+
+- [ ] Does this Actor need to Tick? Can it be a Timer?
+- [ ] Are all `UObject*` members wrapped in `UPROPERTY`?
+- [ ] Are hard references (TSubclassOf) causing load chains? Can they be Soft Ptrs?
+- [ ] Did you clean up verified delegates in `EndPlay`?

package/skills/upgrading-expo/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: upgrading-expo
+description: "Upgrade Expo SDK versions"
+source: "https://github.com/expo/skills/tree/main/plugins/upgrading-expo"
+risk: safe
+---
+
+# Upgrading Expo
+
+## Overview
+
+Upgrade Expo SDK versions safely, handling breaking changes, dependencies, and configuration updates.
+
+## When to Use This Skill
+
+Use this skill when you need to upgrade Expo SDK versions.
+
+Use this skill when:
+- Upgrading to a new Expo SDK version
+- Handling breaking changes between SDK versions
+- Updating dependencies for compatibility
+- Migrating deprecated APIs to new versions
+- Preparing apps for new Expo features
+
+## Instructions
+
+This skill guides you through upgrading Expo SDK versions:
+
+1. **Pre-Upgrade Planning**: Review release notes and breaking changes
+2. **Dependency Updates**: Update packages for SDK compatibility
+3. **Configuration Migration**: Update app.json and configuration files
+4. **Code Updates**: Migrate deprecated APIs to new versions
+5. **Testing**: Verify app functionality after upgrade
+
+## Upgrade Process
+
+### 1. Pre-Upgrade Checklist
+
+- Review Expo SDK release notes
+- Identify breaking changes affecting your app
+- Check compatibility of third-party packages
+- Backup current project state
+- Create a feature branch for the upgrade
+
+### 2. Update Expo SDK
+
+```bash
+# Update Expo CLI
+npm install -g expo-cli@latest
+
+# Upgrade Expo SDK
+npx expo install expo@latest
+
+# Update all Expo packages
+npx expo install --fix
+```
+
+### 3. Handle Breaking Changes
+
+- Review migration guides for breaking changes
+- Update deprecated API calls
+- Modify configuration files as needed
+- Update native dependencies if required
+- Test affected features thoroughly
+
+### 4. Update Dependencies
+
+```bash
+# Check for outdated packages
+npx expo-doctor
+
+# Update packages to compatible versions
+npx expo install --fix
+
+# Verify compatibility
+npx expo-doctor
+```
+
+### 5. Testing
+
+- Test core app functionality
+- Verify native modules work correctly
+- Check for runtime errors
+- Test on both iOS and Android
+- Verify app store builds still work
+
+## Common Issues
+
+### Dependency Conflicts
+
+- Use `expo install` instead of `npm install` for Expo packages
+- Check package compatibility with new SDK version
+- Resolve peer dependency warnings
+
+### Configuration Changes
+
+- Update `app.json` for new SDK requirements
+- Migrate deprecated configuration options
+- Update native configuration files if needed
+
+### Breaking API Changes
+
+- Review API migration guides
+- Update code to use new APIs
+- Test affected features after changes
+
+## Best Practices
+
+- Always upgrade in a feature branch
+- Test thoroughly before merging
+- Review release notes carefully
+- Update dependencies incrementally
+- Keep Expo CLI updated
+- Use `expo-doctor` to verify setup
+
+## Resources
+
+For more information, see the [source repository](https://github.com/expo/skills/tree/main/plugins/upgrading-expo).

package/skills/upstash-qstash/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: upstash-qstash
+description: "Upstash QStash expert for serverless message queues, scheduled jobs, and reliable HTTP-based task delivery without managing infrastructure. Use when: qstash, upstash queue, serverless cron, scheduled http, message queue serverless."
+source: vibeship-spawner-skills (Apache 2.0)
+---
+
+# Upstash QStash
+
+You are an Upstash QStash expert who builds reliable serverless messaging
+without infrastructure management. You understand that QStash's simplicity
+is its power - HTTP in, HTTP out, with reliability in between.
+
+You've scheduled millions of messages, set up cron jobs that run for years,
+and built webhook delivery systems that never drop a message. You know that
+QStash shines when you need "just make this HTTP call later, reliably."
+
+Your core philosophy:
+1. HTTP is the universal language - no c
+
+## Capabilities
+
+- qstash-messaging
+- scheduled-http-calls
+- serverless-cron
+- webhook-delivery
+- message-deduplication
+- callback-handling
+- delay-scheduling
+- url-groups
+
+## Patterns
+
+### Basic Message Publishing
+
+Sending messages to be delivered to endpoints
+
+### Scheduled Cron Jobs
+
+Setting up recurring scheduled tasks
+
+### Signature Verification
+
+Verifying QStash message signatures in your endpoint
+
+## Anti-Patterns
+
+### ❌ Skipping Signature Verification
+
+### ❌ Using Private Endpoints
+
+### ❌ No Error Handling in Endpoints
+
+## ⚠️ Sharp Edges
+
+| Issue | Severity | Solution |
+|-------|----------|----------|
+| Not verifying QStash webhook signatures | critical | # Always verify signatures with both keys: |
+| Callback endpoint taking too long to respond | high | # Design for fast acknowledgment: |
+| Hitting QStash rate limits unexpectedly | high | # Check your plan limits: |
+| Not using deduplication for critical operations | high | # Use deduplication for critical messages: |
+| Expecting QStash to reach private/localhost endpoints | critical | # Production requirements: |
+| Using default retry behavior for all message types | medium | # Configure retries per message: |
+| Sending large payloads instead of references | medium | # Send references, not data: |
+| Not using callback/failureCallback for critical flows | medium | # Use callbacks for critical operations: |
+
+## Related Skills
+
+Works well with: `vercel-deployment`, `nextjs-app-router`, `redis-specialist`, `email-systems`, `supabase-backend`, `cloudflare-workers`

package/skills/using-git-worktrees/SKILL.md

@@ -0,0 +1,217 @@
+---
+name: using-git-worktrees
+description: Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification
+---
+
+# Using Git Worktrees
+
+## Overview
+
+Git worktrees create isolated workspaces sharing the same repository, allowing work on multiple branches simultaneously without switching.
+
+**Core principle:** Systematic directory selection + safety verification = reliable isolation.
+
+**Announce at start:** "I'm using the using-git-worktrees skill to set up an isolated workspace."
+
+## Directory Selection Process
+
+Follow this priority order:
+
+### 1. Check Existing Directories
+
+```bash
+# Check in priority order
+ls -d .worktrees 2>/dev/null     # Preferred (hidden)
+ls -d worktrees 2>/dev/null      # Alternative
+```
+
+**If found:** Use that directory. If both exist, `.worktrees` wins.
+
+### 2. Check CLAUDE.md
+
+```bash
+grep -i "worktree.*director" CLAUDE.md 2>/dev/null
+```
+
+**If preference specified:** Use it without asking.
+
+### 3. Ask User
+
+If no directory exists and no CLAUDE.md preference:
+
+```
+No worktree directory found. Where should I create worktrees?
+
+1. .worktrees/ (project-local, hidden)
+2. ~/.config/superpowers/worktrees/<project-name>/ (global location)
+
+Which would you prefer?
+```
+
+## Safety Verification
+
+### For Project-Local Directories (.worktrees or worktrees)
+
+**MUST verify directory is ignored before creating worktree:**
+
+```bash
+# Check if directory is ignored (respects local, global, and system gitignore)
+git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null
+```
+
+**If NOT ignored:**
+
+Per Jesse's rule "Fix broken things immediately":
+1. Add appropriate line to .gitignore
+2. Commit the change
+3. Proceed with worktree creation
+
+**Why critical:** Prevents accidentally committing worktree contents to repository.
+
+### For Global Directory (~/.config/superpowers/worktrees)
+
+No .gitignore verification needed - outside project entirely.
+
+## Creation Steps
+
+### 1. Detect Project Name
+
+```bash
+project=$(basename "$(git rev-parse --show-toplevel)")
+```
+
+### 2. Create Worktree
+
+```bash
+# Determine full path
+case $LOCATION in
+  .worktrees|worktrees)
+    path="$LOCATION/$BRANCH_NAME"
+    ;;
+  ~/.config/superpowers/worktrees/*)
+    path="~/.config/superpowers/worktrees/$project/$BRANCH_NAME"
+    ;;
+esac
+
+# Create worktree with new branch
+git worktree add "$path" -b "$BRANCH_NAME"
+cd "$path"
+```
+
+### 3. Run Project Setup
+
+Auto-detect and run appropriate setup:
+
+```bash
+# Node.js
+if [ -f package.json ]; then npm install; fi
+
+# Rust
+if [ -f Cargo.toml ]; then cargo build; fi
+
+# Python
+if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
+if [ -f pyproject.toml ]; then poetry install; fi
+
+# Go
+if [ -f go.mod ]; then go mod download; fi
+```
+
+### 4. Verify Clean Baseline
+
+Run tests to ensure worktree starts clean:
+
+```bash
+# Examples - use project-appropriate command
+npm test
+cargo test
+pytest
+go test ./...
+```
+
+**If tests fail:** Report failures, ask whether to proceed or investigate.
+
+**If tests pass:** Report ready.
+
+### 5. Report Location
+
+```
+Worktree ready at <full-path>
+Tests passing (<N> tests, 0 failures)
+Ready to implement <feature-name>
+```
+
+## Quick Reference
+
+| Situation | Action |
+|-----------|--------|
+| `.worktrees/` exists | Use it (verify ignored) |
+| `worktrees/` exists | Use it (verify ignored) |
+| Both exist | Use `.worktrees/` |
+| Neither exists | Check CLAUDE.md → Ask user |
+| Directory not ignored | Add to .gitignore + commit |
+| Tests fail during baseline | Report failures + ask |
+| No package.json/Cargo.toml | Skip dependency install |
+
+## Common Mistakes
+
+### Skipping ignore verification
+
+- **Problem:** Worktree contents get tracked, pollute git status
+- **Fix:** Always use `git check-ignore` before creating project-local worktree
+
+### Assuming directory location
+
+- **Problem:** Creates inconsistency, violates project conventions
+- **Fix:** Follow priority: existing > CLAUDE.md > ask
+
+### Proceeding with failing tests
+
+- **Problem:** Can't distinguish new bugs from pre-existing issues
+- **Fix:** Report failures, get explicit permission to proceed
+
+### Hardcoding setup commands
+
+- **Problem:** Breaks on projects using different tools
+- **Fix:** Auto-detect from project files (package.json, etc.)
+
+## Example Workflow
+
+```
+You: I'm using the using-git-worktrees skill to set up an isolated workspace.
+
+[Check .worktrees/ - exists]
+[Verify ignored - git check-ignore confirms .worktrees/ is ignored]
+[Create worktree: git worktree add .worktrees/auth -b feature/auth]
+[Run npm install]
+[Run npm test - 47 passing]
+
+Worktree ready at /Users/jesse/myproject/.worktrees/auth
+Tests passing (47 tests, 0 failures)
+Ready to implement auth feature
+```
+
+## Red Flags
+
+**Never:**
+- Create worktree without verifying it's ignored (project-local)
+- Skip baseline test verification
+- Proceed with failing tests without asking
+- Assume directory location when ambiguous
+- Skip CLAUDE.md check
+
+**Always:**
+- Follow directory priority: existing > CLAUDE.md > ask
+- Verify directory is ignored for project-local
+- Auto-detect and run project setup
+- Verify clean test baseline
+
+## Integration
+
+**Called by:**
+- **brainstorming** (Phase 4) - REQUIRED when design is approved and implementation follows
+- Any skill needing isolated workspace
+
+**Pairs with:**
+- **finishing-a-development-branch** - REQUIRED for cleanup after work complete
+- **executing-plans** or **subagent-driven-development** - Work happens in this worktree

package/skills/using-neon/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: using-neon
+description: "Guides and best practices for working with Neon Serverless Postgres. Covers getting started, local development with Neon, choosing a connection method, Neon features, authentication (@neondatabase/auth), PostgREST-style data API (@neondatabase/neon-js), Neon CLI, and Neon's Platform API/SDKs. Use for any Neon-related questions."
+source: "https://github.com/neondatabase/agent-skills/tree/main/skills/neon-postgres"
+risk: safe
+---
+
+# Neon Serverless Postgres
+
+Neon is a serverless Postgres platform that separates compute and storage to offer autoscaling, branching, instant restore, and scale-to-zero. It's fully compatible with Postgres and works with any language, framework, or ORM that supports Postgres.
+
+## When to Use This Skill
+
+Use this skill when:
+- Working with Neon Serverless Postgres
+- Setting up Neon databases
+- Choosing connection methods for Neon
+- Using Neon features like branching or autoscaling
+- Working with Neon authentication or APIs
+- Questions about Neon best practices
+
+## Neon Documentation
+
+Always reference the Neon documentation before making Neon-related claims. The documentation is the source of truth for all Neon-related information.
+
+Below you'll find a list of resources organized by area of concern. This is meant to support you find the right documentation pages to fetch and add a bit of additonal context.
+
+You can use the `curl` commands to fetch the documentation page as markdown:
+
+**Documentation:**
+
+```bash
+# Get list of all Neon docs
+curl https://neon.com/llms.txt
+
+# Fetch any doc page as markdown
+curl -H "Accept: text/markdown" https://neon.com/docs/<path>
+```
+
+Don't guess docs pages. Use the `llms.txt` index to find the relevant URL or follow the links in the resources below.
+
+## Overview of Resources
+
+Reference the appropriate resource file based on the user's needs:
+
+### Core Guides
+
+| Area               | Resource                           | When to Use                                                    |
+| ------------------ | ---------------------------------- | -------------------------------------------------------------- |
+| What is Neon       | `references/what-is-neon.md`       | Understanding Neon concepts, architecture, core resources      |
+| Referencing Docs   | `references/referencing-docs.md`   | Looking up official documentation, verifying information       |
+| Features           | `references/features.md`           | Branching, autoscaling, scale-to-zero, instant restore         |
+| Getting Started    | `references/getting-started.md`    | Setting up a project, connection strings, dependencies, schema |
+| Connection Methods | `references/connection-methods.md` | Choosing drivers based on platform and runtime                 |
+| Developer Tools    | `references/devtools.md`           | VSCode extension, MCP server, Neon CLI (`neon init`)           |
+
+### Database Drivers & ORMs
+
+HTTP/WebSocket queries for serverless/edge functions.
+
+| Area              | Resource                        | When to Use                                         |
+| ----------------- | ------------------------------- | --------------------------------------------------- |
+| Serverless Driver | `references/neon-serverless.md` | `@neondatabase/serverless` - HTTP/WebSocket queries |
+| Drizzle ORM       | `references/neon-drizzle.md`    | Drizzle ORM integration with Neon                   |
+
+### Auth & Data API SDKs
+
+Authentication and PostgREST-style data API for Neon.
+
+| Area        | Resource                  | When to Use                                                         |
+| ----------- | ------------------------- | ------------------------------------------------------------------- |
+| Neon Auth   | `references/neon-auth.md` | `@neondatabase/auth` - Authentication only                          |
+| Neon JS SDK | `references/neon-js.md`   | `@neondatabase/neon-js` - Auth + Data API (PostgREST-style queries) |
+
+### Neon Platform API & CLI
+
+Managing Neon resources programmatically via REST API, SDKs, or CLI.
+
+| Area                  | Resource                            | When to Use                                  |
+| --------------------- | ----------------------------------- | -------------------------------------------- |
+| Platform API Overview | `references/neon-platform-api.md`   | Managing Neon resources via REST API         |
+| Neon CLI              | `references/neon-cli.md`            | Terminal workflows, scripts, CI/CD pipelines |
+| TypeScript SDK        | `references/neon-typescript-sdk.md` | `@neondatabase/api-client`                   |
+| Python SDK            | `references/neon-python-sdk.md`     | `neon-api` package                           |

package/skills/using-superpowers/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: using-superpowers
+description: Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions
+---
+
+<EXTREMELY-IMPORTANT>
+If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.
+
+IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
+
+This is not negotiable. This is not optional. You cannot rationalize your way out of this.
+</EXTREMELY-IMPORTANT>
+
+## How to Access Skills
+
+**In Claude Code:** Use the `Skill` tool. When you invoke a skill, its content is loaded and presented to you—follow it directly. Never use the Read tool on skill files.
+
+**In other environments:** Check your platform's documentation for how skills are loaded.
+
+# Using Skills
+
+## The Rule
+
+**Invoke relevant or requested skills BEFORE any response or action.** Even a 1% chance a skill might apply means that you should invoke the skill to check. If an invoked skill turns out to be wrong for the situation, you don't need to use it.
+
+```dot
+digraph skill_flow {
+    "User message received" [shape=doublecircle];
+    "Might any skill apply?" [shape=diamond];
+    "Invoke Skill tool" [shape=box];
+    "Announce: 'Using [skill] to [purpose]'" [shape=box];
+    "Has checklist?" [shape=diamond];
+    "Create TodoWrite todo per item" [shape=box];
+    "Follow skill exactly" [shape=box];
+    "Respond (including clarifications)" [shape=doublecircle];
+
+    "User message received" -> "Might any skill apply?";
+    "Might any skill apply?" -> "Invoke Skill tool" [label="yes, even 1%"];
+    "Might any skill apply?" -> "Respond (including clarifications)" [label="definitely not"];
+    "Invoke Skill tool" -> "Announce: 'Using [skill] to [purpose]'";
+    "Announce: 'Using [skill] to [purpose]'" -> "Has checklist?";
+    "Has checklist?" -> "Create TodoWrite todo per item" [label="yes"];
+    "Has checklist?" -> "Follow skill exactly" [label="no"];
+    "Create TodoWrite todo per item" -> "Follow skill exactly";
+}
+```
+
+## Red Flags
+
+These thoughts mean STOP—you're rationalizing:
+
+| Thought | Reality |
+|---------|---------|
+| "This is just a simple question" | Questions are tasks. Check for skills. |
+| "I need more context first" | Skill check comes BEFORE clarifying questions. |
+| "Let me explore the codebase first" | Skills tell you HOW to explore. Check first. |
+| "I can check git/files quickly" | Files lack conversation context. Check for skills. |
+| "Let me gather information first" | Skills tell you HOW to gather information. |
+| "This doesn't need a formal skill" | If a skill exists, use it. |
+| "I remember this skill" | Skills evolve. Read current version. |
+| "This doesn't count as a task" | Action = task. Check for skills. |
+| "The skill is overkill" | Simple things become complex. Use it. |
+| "I'll just do this one thing first" | Check BEFORE doing anything. |
+| "This feels productive" | Undisciplined action wastes time. Skills prevent this. |
+| "I know what that means" | Knowing the concept ≠ using the skill. Invoke it. |
+
+## Skill Priority
+
+When multiple skills could apply, use this order:
+
+1. **Process skills first** (brainstorming, debugging) - these determine HOW to approach the task
+2. **Implementation skills second** (frontend-design, mcp-builder) - these guide execution
+
+"Let's build X" → brainstorming first, then implementation skills.
+"Fix this bug" → debugging first, then domain-specific skills.
+
+## Skill Types
+
+**Rigid** (TDD, debugging): Follow exactly. Don't adapt away discipline.
+
+**Flexible** (patterns): Adapt principles to context.
+
+The skill itself tells you which.
+
+## User Instructions
+
+Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip workflows.