opencodekit 0.0.1

package/dist/template/.opencode/superpowers/skills/frontend-aesthetics/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: frontend-aesthetics
+description: Use when building UI components, landing pages, dashboards, or any frontend work - avoids generic AI slop aesthetic by steering toward distinctive typography, cohesive themes, meaningful motion, and atmospheric backgrounds
+---
+
+# Frontend Aesthetics
+
+Prevent distributional convergence that creates generic "AI slop" frontends. Every interface should feel intentionally crafted for its specific context.
+
+## When to Use
+
+- Building landing pages, dashboards, forms, components
+- Any frontend generation task
+- Reviewing UI for visual quality
+
+## Decision Gate (Do This First)
+
+Before writing any code, state in 1-2 sentences:
+
+1. **Aesthetic direction** — Which style from the list below?
+2. **Why** — How does it fit the context/purpose?
+
+### Aesthetic Directions
+
+Pick ONE (or combine 2 for hybrid):
+
+| Direction        | Character                                       |
+| ---------------- | ----------------------------------------------- |
+| Neo-Brutalist    | Raw textures, bold type, harsh contrasts        |
+| Soft Minimalism  | Muted palettes, generous whitespace             |
+| Retro-Futuristic | CRT effects, scan lines, neon, cyberpunk        |
+| Editorial        | Dynamic grids, mixed media, bold type           |
+| Glass Morphism   | Translucent layers, backdrop blur, depth        |
+| Dark Academia    | Rich textures, serif type, scholarly            |
+| Swiss Design     | Grid systems, sans-serif, functional            |
+| Art Deco         | Geometric patterns, gold accents, luxury        |
+| Y2K Revival      | Gradients, metallics, early-web nostalgia       |
+| Organic/Natural  | Flowing shapes, nature palettes, paper textures |
+
+## Core Prompt
+
+```xml
+<frontend_aesthetics>
+You tend to converge toward generic outputs. In frontend design, this creates
+"AI slop" aesthetic. Make creative, distinctive frontends that surprise.
+
+Focus on:
+- Typography: Beautiful, unique fonts. Never Inter/Roboto/Arial/system fonts.
+  Good: JetBrains Mono, Fira Code, Space Grotesk, Playfair Display, Crimson Pro,
+  IBM Plex, Bricolage Grotesque, Newsreader, Instrument Serif, Bebas Neue
+- Color: Commit to cohesive theme. CSS variables. Dominant colors with sharp
+  accents beat timid palettes. Draw from IDE themes, cultural aesthetics.
+- Motion: One orchestrated page load with staggered reveals beats scattered
+  micro-interactions. CSS-only for HTML, Motion library for React.
+- Backgrounds: Atmosphere and depth, not solid colors. Layer gradients,
+  geometric patterns, noise textures.
+
+Never do ALL of these together (AI slop signature):
+- Purple/blue gradient backgrounds
+- Inter or system fonts
+- Centered hero with subheading
+- 3-column feature cards with icons
+- Rounded corners on everything (16px border-radius)
+- Drop shadows on all cards
+- #6366F1 or #667eea as primary color
+- "Modern, clean, simple" as only descriptors
+
+Vary light/dark themes, fonts, aesthetics. Make unexpected choices.
+</frontend_aesthetics>
+```
+
+## Typography Quick Reference
+
+| Category    | Good Choices                                    | Avoid            |
+| ----------- | ----------------------------------------------- | ---------------- |
+| Code/Tech   | JetBrains Mono, Fira Code, Space Mono           | Roboto Mono      |
+| Editorial   | Playfair Display, Crimson Pro, Instrument Serif | Times New Roman  |
+| Display     | Bebas Neue, Oswald, Archivo Black               | Impact           |
+| Technical   | IBM Plex, Source Sans 3, Work Sans              | Arial, Helvetica |
+| Distinctive | Bricolage Grotesque, Syne, Outfit               | Inter, Lato      |
+
+**Pairing:** High contrast = interesting. Display + monospace, serif + geometric sans.
+
+**Weight:** Use extremes (100/200 vs 800/900), not middle (400 vs 600). Size jumps 3x+.
+
+## Color Anti-Patterns
+
+```css
+/* BAD - Overused AI gradient */
+background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
+
+/* GOOD - Intentional duotone */
+background:
+  linear-gradient(45deg, #ff6b6b 0%, transparent 70%),
+  linear-gradient(-45deg, #4ecdc4 0%, transparent 70%), #f7fff7;
+```
+
+## Animation Pattern
+
+One orchestrated entrance beats scattered effects:
+
+```css
+@keyframes revealUp {
+  from {
+    opacity: 0;
+    transform: translateY(30px);
+  }
+}
+
+.hero > * {
+  animation: revealUp 800ms cubic-bezier(0.19, 1, 0.22, 1) both;
+}
+.hero > *:nth-child(1) {
+  animation-delay: 0ms;
+}
+.hero > *:nth-child(2) {
+  animation-delay: 80ms;
+}
+.hero > *:nth-child(3) {
+  animation-delay: 160ms;
+}
+```
+
+## Framework Integration
+
+**React + Tailwind:** "Use Tailwind with custom theme, animate with Framer Motion"
+
+**shadcn/ui:** "Use shadcn components but customize theme, avoid default styling"
+
+## Quality Check
+
+Before delivery:
+
+- [ ] Clear aesthetic point of view?
+- [ ] Avoids ALL items in the AI slop list?
+- [ ] Would someone remember this tomorrow?
+- [ ] Responsive, accessible, performs well?

package/dist/template/.opencode/superpowers/skills/gemini-large-context/SKILL.md

@@ -0,0 +1,205 @@
+---
+name: gemini-large-context
+description: Use when analyzing large codebases, comparing multiple files, or researching project-wide patterns that exceed typical context limits - leverages Gemini CLI's 1M token context window for comprehensive analysis
+---
+
+# Gemini CLI Large Context Analysis
+
+## Overview
+
+Use Gemini CLI's massive context window (1M tokens) when analysis requires more context than available in current session. Ideal for codebase-wide searches, multi-file comparisons, and pattern discovery across large projects.
+
+## When to Use
+
+- Analyzing entire codebases or large directories (100KB+)
+- Comparing multiple large files simultaneously
+- Understanding project-wide patterns or architecture
+- Context window insufficient for current task
+- Verifying feature implementations across codebase
+- Research that needs to scan many files at once
+
+## Quick Reference
+
+```bash
+# Basic non-interactive analysis
+gemini -p "@src/ Summarize architecture"
+
+# Multiple directories
+gemini -p "@src/ @tests/ Analyze test coverage"
+
+# All project files
+gemini --all-files -p "Project overview"
+
+# Specific model (Pro = 1M context)
+gemini -m gemini-2.5-pro -p "@src/ Deep analysis"
+```
+
+## File/Directory Inclusion Syntax
+
+```bash
+# Single file
+gemini -p "@src/main.py Explain this file"
+
+# Multiple files
+gemini -p "@package.json @src/index.js Analyze dependencies"
+
+# Entire directory (recursive)
+gemini -p "@src/ Summarize architecture"
+
+# Multiple directories
+gemini -p "@src/ @tests/ Analyze test coverage"
+
+# Current directory
+gemini -p "@./ Project overview"
+
+# Alternative: all files flag
+gemini --all-files -p "Analyze project structure"
+```
+
+## Research Patterns
+
+### Architecture Analysis
+
+```bash
+gemini -p "@src/
+Describe:
+1. Overall architecture pattern (MVC, Clean, etc.)
+2. Key modules and their responsibilities
+3. Data flow between components
+4. External dependencies and integrations"
+```
+
+### Feature Implementation Check
+
+```bash
+gemini -p "@src/ @lib/
+Has [FEATURE] been implemented?
+Show:
+- Relevant files and functions
+- Implementation approach
+- Any gaps or incomplete areas"
+```
+
+### Pattern Discovery
+
+```bash
+gemini -p "@src/
+Find all instances of [PATTERN]:
+- File paths
+- Implementation variations
+- Consistency assessment"
+```
+
+### Security Audit
+
+```bash
+gemini -p "@src/ @api/
+Security review:
+- Input validation practices
+- Authentication/authorization patterns
+- SQL injection protections
+- XSS prevention measures"
+```
+
+### Test Coverage Analysis
+
+```bash
+gemini -p "@src/ @tests/
+Assess test coverage:
+- Which modules have tests?
+- Which are missing tests?
+- Test quality (unit vs integration)
+- Edge cases covered"
+```
+
+## Integration with OpenCode Workflow
+
+### For Task-Constrained Research
+
+When researching within task boundaries:
+
+```bash
+# 1. Include bead spec in context
+gemini -p "@src/ @.beads/artifacts/bd-xxx/spec.md
+Research implementations matching spec constraints"
+
+# 2. Save findings to bead artifacts
+# Write to .beads/artifacts/bd-xxx/research.md
+```
+
+### Delegating Large Research to Gemini
+
+In AGENTS.md or prompts, instruct agents:
+
+```markdown
+When analysis requires more than 100KB of files:
+
+1. Use Gemini CLI: `gemini -p "@[paths] [question]"`
+2. Capture output
+3. Synthesize findings in response
+```
+
+## Output Options
+
+```bash
+# Plain text (default)
+gemini -p "query"
+
+# JSON for parsing
+gemini -p "query" --output-format json
+
+# Streaming for long ops
+gemini -p "query" --output-format stream-json
+```
+
+## Common Research Queries
+
+- **Architecture overview:** `gemini -p "@src/ Describe architecture"`
+- **Find implementations:** `gemini -p "@src/ Where is [X] implemented?"`
+- **Pattern audit:** `gemini -p "@src/ Find all [pattern] usages"`
+- **Dependency analysis:** `gemini -p "@package.json @src/ Analyze dependency usage"`
+- **Code quality:** `gemini -p "@src/ Identify code smells"`
+- **Migration planning:** `gemini -p "@src/ Plan migration from [A] to [B]"`
+
+## Configuration
+
+### Authentication
+
+```bash
+# Google login (free tier: 60 req/min, 1000/day)
+gemini  # Follow OAuth flow
+
+# Or API key
+export GEMINI_API_KEY="your-key"
+```
+
+### Model Selection
+
+For most analysis tasks, **`gemini-2.5-pro`** is the best choice—it has a 1M token context window and handles code, text, and image analysis exceptionally well. This is the default model.
+
+Use **`gemini-2.5-flash`** when you need faster responses and don't need the full context window.
+
+**Important:** If you're analyzing images or screenshots, use `gemini-2.5-pro`. Image generation models like `imagen-3.0-generate-002` are for _creating_ new images, not understanding existing ones.
+
+```bash
+# Gemini 2.5 Pro (1M context) - default, best for analysis
+gemini -p "query"
+
+# Gemini Flash (faster, smaller context)
+gemini -m gemini-2.5-flash -p "query"
+```
+
+## Best Practices
+
+1. **Scope appropriately** - Include only relevant directories
+2. **Be specific** - Ask focused questions, not vague queries
+3. **Use for read-only analysis** - Don't ask Gemini to modify files in non-interactive mode
+4. **Capture output** - Redirect to file for long analyses: `gemini -p "..." > analysis.md`
+5. **Combine with local tools** - Use Gemini for research, local tools for implementation
+
+## Limitations
+
+- Non-interactive mode: no tool approvals (file writes, shell commands)
+- `@file` syntax: best in interactive mode
+- Network dependency: requires internet connection
+- Rate limits: 60 req/min free tier

package/dist/template/.opencode/superpowers/skills/receiving-code-review/SKILL.md

@@ -0,0 +1,209 @@
+---
+name: receiving-code-review
+description: Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
+---
+
+# Code Review Reception
+
+## Overview
+
+Code review requires technical evaluation, not emotional performance.
+
+**Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort.
+
+## The Response Pattern
+
+```
+WHEN receiving code review feedback:
+
+1. READ: Complete feedback without reacting
+2. UNDERSTAND: Restate requirement in own words (or ask)
+3. VERIFY: Check against codebase reality
+4. EVALUATE: Technically sound for THIS codebase?
+5. RESPOND: Technical acknowledgment or reasoned pushback
+6. IMPLEMENT: One item at a time, test each
+```
+
+## Forbidden Responses
+
+**NEVER:**
+- "You're absolutely right!" (explicit CLAUDE.md violation)
+- "Great point!" / "Excellent feedback!" (performative)
+- "Let me implement that now" (before verification)
+
+**INSTEAD:**
+- Restate the technical requirement
+- Ask clarifying questions
+- Push back with technical reasoning if wrong
+- Just start working (actions > words)
+
+## Handling Unclear Feedback
+
+```
+IF any item is unclear:
+  STOP - do not implement anything yet
+  ASK for clarification on unclear items
+
+WHY: Items may be related. Partial understanding = wrong implementation.
+```
+
+**Example:**
+```
+your human partner: "Fix 1-6"
+You understand 1,2,3,6. Unclear on 4,5.
+
+❌ WRONG: Implement 1,2,3,6 now, ask about 4,5 later
+✅ RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."
+```
+
+## Source-Specific Handling
+
+### From your human partner
+- **Trusted** - implement after understanding
+- **Still ask** if scope unclear
+- **No performative agreement**
+- **Skip to action** or technical acknowledgment
+
+### From External Reviewers
+```
+BEFORE implementing:
+  1. Check: Technically correct for THIS codebase?
+  2. Check: Breaks existing functionality?
+  3. Check: Reason for current implementation?
+  4. Check: Works on all platforms/versions?
+  5. Check: Does reviewer understand full context?
+
+IF suggestion seems wrong:
+  Push back with technical reasoning
+
+IF can't easily verify:
+  Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
+
+IF conflicts with your human partner's prior decisions:
+  Stop and discuss with your human partner first
+```
+
+**your human partner's rule:** "External feedback - be skeptical, but check carefully"
+
+## YAGNI Check for "Professional" Features
+
+```
+IF reviewer suggests "implementing properly":
+  grep codebase for actual usage
+
+  IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
+  IF used: Then implement properly
+```
+
+**your human partner's rule:** "You and reviewer both report to me. If we don't need this feature, don't add it."
+
+## Implementation Order
+
+```
+FOR multi-item feedback:
+  1. Clarify anything unclear FIRST
+  2. Then implement in this order:
+     - Blocking issues (breaks, security)
+     - Simple fixes (typos, imports)
+     - Complex fixes (refactoring, logic)
+  3. Test each fix individually
+  4. Verify no regressions
+```
+
+## When To Push Back
+
+Push back when:
+- Suggestion breaks existing functionality
+- Reviewer lacks full context
+- Violates YAGNI (unused feature)
+- Technically incorrect for this stack
+- Legacy/compatibility reasons exist
+- Conflicts with your human partner's architectural decisions
+
+**How to push back:**
+- Use technical reasoning, not defensiveness
+- Ask specific questions
+- Reference working tests/code
+- Involve your human partner if architectural
+
+**Signal if uncomfortable pushing back out loud:** "Strange things are afoot at the Circle K"
+
+## Acknowledging Correct Feedback
+
+When feedback IS correct:
+```
+✅ "Fixed. [Brief description of what changed]"
+✅ "Good catch - [specific issue]. Fixed in [location]."
+✅ [Just fix it and show in the code]
+
+❌ "You're absolutely right!"
+❌ "Great point!"
+❌ "Thanks for catching that!"
+❌ "Thanks for [anything]"
+❌ ANY gratitude expression
+```
+
+**Why no thanks:** Actions speak. Just fix it. The code itself shows you heard the feedback.
+
+**If you catch yourself about to write "Thanks":** DELETE IT. State the fix instead.
+
+## Gracefully Correcting Your Pushback
+
+If you pushed back and were wrong:
+```
+✅ "You were right - I checked [X] and it does [Y]. Implementing now."
+✅ "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."
+
+❌ Long apology
+❌ Defending why you pushed back
+❌ Over-explaining
+```
+
+State the correction factually and move on.
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Performative agreement | State requirement or just act |
+| Blind implementation | Verify against codebase first |
+| Batch without testing | One at a time, test each |
+| Assuming reviewer is right | Check if breaks things |
+| Avoiding pushback | Technical correctness > comfort |
+| Partial implementation | Clarify all items first |
+| Can't verify, proceed anyway | State limitation, ask for direction |
+
+## Real Examples
+
+**Performative Agreement (Bad):**
+```
+Reviewer: "Remove legacy code"
+❌ "You're absolutely right! Let me remove that..."
+```
+
+**Technical Verification (Good):**
+```
+Reviewer: "Remove legacy code"
+✅ "Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Current impl has wrong bundle ID - fix it or drop pre-13 support?"
+```
+
+**YAGNI (Good):**
+```
+Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
+✅ "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?"
+```
+
+**Unclear Item (Good):**
+```
+your human partner: "Fix items 1-6"
+You understand 1,2,3,6. Unclear on 4,5.
+✅ "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."
+```
+
+## The Bottom Line
+
+**External feedback = suggestions to evaluate, not orders to follow.**
+
+Verify. Question. Then implement.
+
+No performative agreement. Technical rigor always.

package/dist/template/.opencode/superpowers/skills/requesting-code-review/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: requesting-code-review
+description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements - dispatches superpowers:code-reviewer subagent to review implementation against plan or requirements before proceeding
+---
+
+# Requesting Code Review
+
+Dispatch superpowers:code-reviewer subagent to catch issues before they cascade.
+
+**Core principle:** Review early, review often.
+
+## When to Request Review
+
+**Mandatory:**
+- After each task in subagent-driven development
+- After completing major feature
+- Before merge to main
+
+**Optional but valuable:**
+- When stuck (fresh perspective)
+- Before refactoring (baseline check)
+- After fixing complex bug
+
+## How to Request
+
+**1. Get git SHAs:**
+```bash
+BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
+HEAD_SHA=$(git rev-parse HEAD)
+```
+
+**2. Dispatch code-reviewer subagent:**
+
+Use Task tool with superpowers:code-reviewer type, fill template at `code-reviewer.md`
+
+**Placeholders:**
+- `{WHAT_WAS_IMPLEMENTED}` - What you just built
+- `{PLAN_OR_REQUIREMENTS}` - What it should do
+- `{BASE_SHA}` - Starting commit
+- `{HEAD_SHA}` - Ending commit
+- `{DESCRIPTION}` - Brief summary
+
+**3. Act on feedback:**
+- Fix Critical issues immediately
+- Fix Important issues before proceeding
+- Note Minor issues for later
+- Push back if reviewer is wrong (with reasoning)
+
+## Example
+
+```
+[Just completed Task 2: Add verification function]
+
+You: Let me request code review before proceeding.
+
+BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
+HEAD_SHA=$(git rev-parse HEAD)
+
+[Dispatch superpowers:code-reviewer subagent]
+  WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
+  PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/deployment-plan.md
+  BASE_SHA: a7981ec
+  HEAD_SHA: 3df7661
+  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
+
+[Subagent returns]:
+  Strengths: Clean architecture, real tests
+  Issues:
+    Important: Missing progress indicators
+    Minor: Magic number (100) for reporting interval
+  Assessment: Ready to proceed
+
+You: [Fix progress indicators]
+[Continue to Task 3]
+```
+
+## Integration with Workflows
+
+**Subagent-Driven Development:**
+- Review after EACH task
+- Catch issues before they compound
+- Fix before moving to next task
+
+**Executing Plans:**
+- Review after each batch (3 tasks)
+- Get feedback, apply, continue
+
+**Ad-Hoc Development:**
+- Review before merge
+- Review when stuck
+
+## Red Flags
+
+**Never:**
+- Skip review because "it's simple"
+- Ignore Critical issues
+- Proceed with unfixed Important issues
+- Argue with valid technical feedback
+
+**If reviewer wrong:**
+- Push back with technical reasoning
+- Show code/tests that prove it works
+- Request clarification
+
+See template at: requesting-code-review/code-reviewer.md