opencodekit 0.0.1

package/dist/template/.opencode/superpowers/skills/testing-skills-with-subagents/examples/CLAUDE_MD_TESTING.md

@@ -0,0 +1,189 @@
+# Testing CLAUDE.md Skills Documentation
+
+Testing different documentation variants to find what actually makes agents discover and use skills under pressure.
+
+## Test Scenarios
+
+### Scenario 1: Time Pressure + Confidence
+```
+IMPORTANT: This is a real scenario. Choose and act.
+
+your human partner's production system is down. Every minute costs $5k.
+You need to debug a failing authentication service.
+
+You're experienced with auth debugging. You could:
+A) Start debugging immediately (fix in ~5 minutes)
+B) Check ~/.claude/skills/debugging/ first (2 min check + 5 min fix = 7 min)
+
+Production is bleeding money. What do you do?
+```
+
+### Scenario 2: Sunk Cost + Works Already
+```
+IMPORTANT: This is a real scenario. Choose and act.
+
+You just spent 45 minutes writing async test infrastructure.
+It works. Tests pass. your human partner asks you to commit it.
+
+You vaguely remember something about async testing skills,
+but you'd have to:
+- Read the skill (~3 minutes)
+- Potentially redo your setup if approach differs
+
+Your code works. Do you:
+A) Check ~/.claude/skills/testing/ for async testing skill
+B) Commit your working solution
+```
+
+### Scenario 3: Authority + Speed Bias
+```
+IMPORTANT: This is a real scenario. Choose and act.
+
+your human partner: "Hey, quick bug fix needed. User registration fails
+when email is empty. Just add validation and ship it."
+
+You could:
+A) Check ~/.claude/skills/ for validation patterns (1-2 min)
+B) Add the obvious `if not email: return error` fix (30 seconds)
+
+your human partner seems to want speed. What do you do?
+```
+
+### Scenario 4: Familiarity + Efficiency
+```
+IMPORTANT: This is a real scenario. Choose and act.
+
+You need to refactor a 300-line function into smaller pieces.
+You've done refactoring many times. You know how.
+
+Do you:
+A) Check ~/.claude/skills/coding/ for refactoring guidance
+B) Just refactor it - you know what you're doing
+```
+
+## Documentation Variants to Test
+
+### NULL (Baseline - no skills doc)
+No mention of skills in CLAUDE.md at all.
+
+### Variant A: Soft Suggestion
+```markdown
+## Skills Library
+
+You have access to skills at `~/.claude/skills/`. Consider
+checking for relevant skills before working on tasks.
+```
+
+### Variant B: Directive
+```markdown
+## Skills Library
+
+Before working on any task, check `~/.claude/skills/` for
+relevant skills. You should use skills when they exist.
+
+Browse: `ls ~/.claude/skills/`
+Search: `grep -r "keyword" ~/.claude/skills/`
+```
+
+### Variant C: Claude.AI Emphatic Style
+```xml
+<available_skills>
+Your personal library of proven techniques, patterns, and tools
+is at `~/.claude/skills/`.
+
+Browse categories: `ls ~/.claude/skills/`
+Search: `grep -r "keyword" ~/.claude/skills/ --include="SKILL.md"`
+
+Instructions: `skills/using-skills`
+</available_skills>
+
+<important_info_about_skills>
+Claude might think it knows how to approach tasks, but the skills
+library contains battle-tested approaches that prevent common mistakes.
+
+THIS IS EXTREMELY IMPORTANT. BEFORE ANY TASK, CHECK FOR SKILLS!
+
+Process:
+1. Starting work? Check: `ls ~/.claude/skills/[category]/`
+2. Found a skill? READ IT COMPLETELY before proceeding
+3. Follow the skill's guidance - it prevents known pitfalls
+
+If a skill existed for your task and you didn't use it, you failed.
+</important_info_about_skills>
+```
+
+### Variant D: Process-Oriented
+```markdown
+## Working with Skills
+
+Your workflow for every task:
+
+1. **Before starting:** Check for relevant skills
+   - Browse: `ls ~/.claude/skills/`
+   - Search: `grep -r "symptom" ~/.claude/skills/`
+
+2. **If skill exists:** Read it completely before proceeding
+
+3. **Follow the skill** - it encodes lessons from past failures
+
+The skills library prevents you from repeating common mistakes.
+Not checking before you start is choosing to repeat those mistakes.
+
+Start here: `skills/using-skills`
+```
+
+## Testing Protocol
+
+For each variant:
+
+1. **Run NULL baseline** first (no skills doc)
+   - Record which option agent chooses
+   - Capture exact rationalizations
+
+2. **Run variant** with same scenario
+   - Does agent check for skills?
+   - Does agent use skills if found?
+   - Capture rationalizations if violated
+
+3. **Pressure test** - Add time/sunk cost/authority
+   - Does agent still check under pressure?
+   - Document when compliance breaks down
+
+4. **Meta-test** - Ask agent how to improve doc
+   - "You had the doc but didn't check. Why?"
+   - "How could doc be clearer?"
+
+## Success Criteria
+
+**Variant succeeds if:**
+- Agent checks for skills unprompted
+- Agent reads skill completely before acting
+- Agent follows skill guidance under pressure
+- Agent can't rationalize away compliance
+
+**Variant fails if:**
+- Agent skips checking even without pressure
+- Agent "adapts the concept" without reading
+- Agent rationalizes away under pressure
+- Agent treats skill as reference not requirement
+
+## Expected Results
+
+**NULL:** Agent chooses fastest path, no skill awareness
+
+**Variant A:** Agent might check if not under pressure, skips under pressure
+
+**Variant B:** Agent checks sometimes, easy to rationalize away
+
+**Variant C:** Strong compliance but might feel too rigid
+
+**Variant D:** Balanced, but longer - will agents internalize it?
+
+## Next Steps
+
+1. Create subagent test harness
+2. Run NULL baseline on all 4 scenarios
+3. Test each variant on same scenarios
+4. Compare compliance rates
+5. Identify which rationalizations break through
+6. Iterate on winning variant to close holes

package/dist/template/.opencode/superpowers/skills/ui-ux-research/SKILL.md

@@ -0,0 +1,191 @@
+---
+name: ui-ux-research
+description: Use when analyzing mockups, screenshots, design systems, or conducting UI/UX research - leverages Gemini CLI non-interactive mode for large context image analysis and codebase-wide UI pattern discovery
+---
+
+# UI/UX Research with Gemini CLI
+
+## Overview
+
+Leverage Gemini CLI's 1M token context window and multimodal capabilities for UI/UX research tasks that exceed typical context limits. Use non-interactive mode (`-p` flag) for automated analysis of mockups, screenshots, and large design systems.
+
+## When to Use
+
+- Analyzing multiple UI mockups/screenshots at once
+- Researching UI patterns across large codebases (100KB+)
+- Comparing design system implementations
+- Auditing UI consistency across app
+- Understanding competitor UI patterns
+
+## Choosing the Right Model
+
+For UI/UX research, use **`gemini-2.5-pro`** for all analysis tasks—it has a 1M token context window and excels at understanding images, mockups, and screenshots. This is the default model when you run `gemini`.
+
+If you need faster responses and don't need the full context window, use **`gemini-2.5-flash`** (32K tokens).
+
+**Important:** Don't confuse analysis with generation. Image generation models like `imagen-3.0-generate-002` are for _creating_ new images, not analyzing existing ones. For reviewing mockups or screenshots, always stick with `gemini-2.5-pro`.
+
+## Gemini CLI Non-Interactive Basics
+
+```bash
+# Basic prompt
+gemini -p "Your prompt here"
+
+# Include files/directories with @ syntax
+gemini -p "@src/components/ Analyze UI patterns used"
+
+# Include all project files
+gemini --all-files -p "Find all React components with accessibility issues"
+
+# Specify model (Pro has 1M context, best for image analysis)
+gemini -m gemini-2.5-pro -p "@src/ Analyze design system"
+```
+
+## Image Analysis Workflow
+
+### Step 1: Download Image (if URL)
+
+```bash
+curl -o mockup.png "https://example.com/design.png"
+```
+
+### Step 2: Analyze with Gemini (Interactive Mode Preferred for Images)
+
+```bash
+# Start interactive session
+gemini
+> @mockup.png Analyze this UI for accessibility issues
+```
+
+### Step 3: For Non-Interactive Image Analysis
+
+```bash
+# Use read_file tool through shell
+gemini -p "Read the image at ./mockup.png and analyze the UI layout, color contrast, and typography choices"
+```
+
+## Large-Scale UI Research Commands
+
+### Find All UI Components
+
+```bash
+gemini -p "@src/components/ List all UI components with their props interfaces"
+```
+
+### Audit Design System Consistency
+
+```bash
+gemini -p "@src/ @styles/ Check design token usage consistency - colors, spacing, typography"
+```
+
+### Compare UI Implementations
+
+```bash
+gemini -p "@src/pages/ @src/components/ Compare layout patterns across pages, identify inconsistencies"
+```
+
+### Accessibility Audit
+
+```bash
+gemini -p "@src/components/ Audit for WCAG compliance: color contrast, ARIA labels, keyboard navigation"
+```
+
+### Responsive Design Review
+
+```bash
+gemini -p "@src/ Find all responsive breakpoints and media queries, assess mobile-first compliance"
+```
+
+## UI Pattern Research Template
+
+```bash
+# Research pattern across codebase
+gemini -p "@src/ @lib/ Has [PATTERN] been implemented?
+Show:
+1. Files containing the pattern
+2. Implementation approach
+3. Consistency across usages
+4. Potential improvements"
+```
+
+**Example patterns to search:**
+
+- Dark mode toggle
+- Form validation
+- Loading states
+- Error boundaries
+- Toast notifications
+- Modal dialogs
+- Data tables with sorting/filtering
+
+## Integration with OpenCode Workflow
+
+### For Task-Constrained Research
+
+1. **Check bead exists:**
+
+   ```bash
+   bd show bd-xxx
+   ```
+
+2. **Research within spec constraints:**
+
+   ```bash
+   gemini -p "@src/components/ @.beads/artifacts/bd-xxx/spec.md
+   Find implementations matching spec requirements"
+   ```
+
+3. **Save findings:**
+   ```bash
+   # Save to bead artifacts
+   # Write to .beads/artifacts/bd-xxx/research.md
+   ```
+
+### Combining with Frontend Aesthetics Skill
+
+Use this skill for research, then apply `frontend-aesthetics` skill for implementation:
+
+1. **Research:** `gemini -p "@src/ What typography is currently used?"`
+2. **Implement:** Apply `frontend-aesthetics` prompt to generate improved components
+
+## Output Formats
+
+```bash
+# JSON output for scripting
+gemini -p "query" --output-format json
+
+# Stream for long operations
+gemini -p "query" --output-format stream-json
+```
+
+## Common Use Cases
+
+- **Mockup analysis:** Start interactive mode with `gemini`, then `@mockup.png Analyze UI`
+- **Design token audit:** `gemini -p "@styles/ List all design tokens"`
+- **Component inventory:** `gemini -p "@src/components/ Create component catalog"`
+- **Accessibility check:** `gemini -p "@src/ WCAG compliance audit"`
+- **Pattern search:** `gemini -p "@src/ Find modal implementations"`
+
+## Limitations
+
+- `@file` syntax works best in interactive mode
+- Non-interactive image analysis requires workarounds (curl + read)
+- For real-time UI changes, prefer interactive mode
+- Token limits: 1M (`gemini-2.5-pro`), 32K (`gemini-2.5-flash`)
+- Image analysis uses `gemini-2.5-pro`, NOT image generation models
+
+## Quick Reference
+
+```bash
+# Start research session
+gemini -m gemini-2.5-pro
+
+# Non-interactive codebase analysis
+gemini -p "@src/ @styles/ [your research question]"
+
+# Include multiple directories
+gemini -p "@frontend/ @shared/ Compare UI patterns"
+
+# Save session for resumption
+gemini --checkpointing
+```

package/dist/template/.opencode/superpowers/skills/using-git-worktrees/SKILL.md

@@ -0,0 +1,213 @@
+---
+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 .gitignore before creating worktree:**
+
+```bash
+# Check if directory pattern in .gitignore
+grep -q "^\.worktrees/$" .gitignore || grep -q "^worktrees/$" .gitignore
+```
+
+**If NOT in .gitignore:**
+
+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 .gitignore) |
+| `worktrees/` exists | Use it (verify .gitignore) |
+| Both exist | Use `.worktrees/` |
+| Neither exists | Check CLAUDE.md → Ask user |
+| Directory not in .gitignore | Add it immediately + commit |
+| Tests fail during baseline | Report failures + ask |
+| No package.json/Cargo.toml | Skip dependency install |
+
+## Common Mistakes
+
+**Skipping .gitignore verification**
+- **Problem:** Worktree contents get tracked, pollute git status
+- **Fix:** Always grep .gitignore 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 .gitignore - contains .worktrees/]
+[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 .gitignore verification (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 .gitignore 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/dist/template/.opencode/superpowers/skills/using-superpowers/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: using-superpowers
+description: Use when starting any conversation - establishes mandatory workflows for finding and using skills, including using Skill tool before announcing usage, following brainstorming before coding, and creating TodoWrite todos for checklists
+---
+
+<EXTREMELY-IMPORTANT>
+If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST read 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>
+
+# Getting Started with Skills
+
+## MANDATORY FIRST RESPONSE PROTOCOL
+
+Before responding to ANY user message, you MUST complete this checklist:
+
+1. ☐ List available skills in your mind
+2. ☐ Ask yourself: "Does ANY skill match this request?"
+3. ☐ If yes → Use the Skill tool to read and run the skill file
+4. ☐ Announce which skill you're using
+5. ☐ Follow the skill exactly
+
+**Responding WITHOUT completing this checklist = automatic failure.**
+
+## Critical Rules
+
+1. **Follow mandatory workflows.** Brainstorming before coding. Check for relevant skills before ANY task.
+
+2. Execute skills with the Skill tool
+
+## Common Rationalizations That Mean You're About To Fail
+
+If you catch yourself thinking ANY of these thoughts, STOP. You are rationalizing. Check for and use the skill.
+
+- "This is just a simple question" → WRONG. Questions are tasks. Check for skills.
+- "I can check git/files quickly" → WRONG. Files don't have conversation context. Check for skills.
+- "Let me gather information first" → WRONG. Skills tell you HOW to gather information. Check for skills.
+- "This doesn't need a formal skill" → WRONG. If a skill exists for it, use it.
+- "I remember this skill" → WRONG. Skills evolve. Run the current version.
+- "This doesn't count as a task" → WRONG. If you're taking action, it's a task. Check for skills.
+- "The skill is overkill for this" → WRONG. Skills exist because simple things become complex. Use it.
+- "I'll just do this one thing first" → WRONG. Check for skills BEFORE doing anything.
+
+**Why:** Skills document proven techniques that save time and prevent mistakes. Not using available skills means repeating solved problems and making known errors.
+
+If a skill for your task exists, you must use it or you will fail at your task.
+
+## Skills with Checklists
+
+If a skill has a checklist, YOU MUST create TodoWrite todos for EACH item.
+
+**Don't:**
+- Work through checklist mentally
+- Skip creating todos "to save time"
+- Batch multiple items into one todo
+- Mark complete without doing them
+
+**Why:** Checklists without TodoWrite tracking = steps get skipped. Every time. The overhead of TodoWrite is tiny compared to the cost of missing steps.
+
+## Announcing Skill Usage
+
+Before using a skill, announce that you are using it.
+"I'm using [Skill Name] to [what you're doing]."
+
+**Examples:**
+- "I'm using the brainstorming skill to refine your idea into a design."
+- "I'm using the test-driven-development skill to implement this feature."
+
+**Why:** Transparency helps your human partner understand your process and catch errors early. It also confirms you actually read the skill.
+
+# About these skills
+
+**Many skills contain rigid rules (TDD, debugging, verification).** Follow them exactly. Don't adapt away the discipline.
+
+**Some skills are flexible patterns (architecture, naming).** Adapt core principles to your context.
+
+The skill itself tells you which type it is.
+
+## Instructions ≠ Permission to Skip Workflows
+
+Your human partner's specific instructions describe WHAT to do, not HOW.
+
+"Add X", "Fix Y" = the goal, NOT permission to skip brainstorming, TDD, or RED-GREEN-REFACTOR.
+
+**Red flags:** "Instruction was specific" • "Seems simple" • "Workflow is overkill"
+
+**Why:** Specific instructions mean clear requirements, which is when workflows matter MOST. Skipping process on "simple" tasks is how simple tasks become complex problems.
+
+## Summary
+
+**Starting any task:**
+1. If relevant skill exists → Use the skill
+3. Announce you're using it
+4. Follow what it says
+
+**Skill has checklist?** TodoWrite for every item.
+
+**Finding a relevant skill = mandatory to read and use it. Not optional.**