@lavralabs/lavra 0.7.0

package/plugins/lavra/gemini/skills/brainstorming/SKILL.md

@@ -0,0 +1,197 @@
+<!-- Generated by lavra v0.6.0 -->
+<!-- Source: brainstorming/SKILL.md -->
+<!-- DO NOT EDIT - changes will be overwritten on next install -->
+
+---
+name: brainstorming
+description: This skill should be used before implementing features, building components, or making changes. It guides exploring user intent, approaches, and design decisions before planning. Triggers on "let's brainstorm", "help me think through", "what should we build", "explore approaches", ambiguous feature requests, or when the user's request has multiple valid interpretations that need clarification.
+---
+
+# Brainstorming
+
+This skill provides detailed process knowledge for effective brainstorming sessions that clarify **WHAT** to build before diving into **HOW** to build it.
+
+## When to Use This Skill
+
+Brainstorming is valuable when:
+- Requirements are unclear or ambiguous
+- Multiple approaches could solve the problem
+- Trade-offs need to be explored with the user
+- The user hasn't fully articulated what they want
+- The feature scope needs refinement
+
+Brainstorming can be skipped when:
+- Requirements are explicit and detailed
+- The user knows exactly what they want
+- The task is a straightforward bug fix or well-defined change
+
+## Core Process
+
+### Phase 0: Assess Requirement Clarity
+
+Before diving into questions, assess whether brainstorming is needed.
+
+**Signals that requirements are clear:**
+- User provided specific acceptance criteria
+- User referenced existing patterns to follow
+- User described exact behavior expected
+- Scope is constrained and well-defined
+
+**Signals that brainstorming is needed:**
+- User used vague terms ("make it better", "add something like")
+- Multiple reasonable interpretations exist
+- Trade-offs haven't been discussed
+- User seems unsure about the approach
+
+If requirements are clear, suggest: "Your requirements seem clear. Consider proceeding directly to planning or implementation."
+
+### Phase 1: Understand the Idea
+
+Ask questions **one at a time** to understand the user's intent. Avoid overwhelming with multiple questions.
+
+**Question Techniques:**
+
+1. **Prefer multiple choice when natural options exist**
+   - Good: "Should the notification be: (a) email only, (b) in-app only, or (c) both?"
+   - Avoid: "How should users be notified?"
+
+2. **Start broad, then narrow**
+   - First: What is the core purpose?
+   - Then: Who are the users?
+   - Finally: What constraints exist?
+
+3. **Validate assumptions explicitly**
+   - "I'm assuming users will be logged in. Is that correct?"
+
+4. **Ask about success criteria early**
+   - "How will you know this feature is working well?"
+
+**Key Topics to Explore:**
+
+| Topic | Example Questions |
+|-------|-------------------|
+| Purpose | What problem does this solve? What's the motivation? |
+| Users | Who uses this? What's their context? |
+| Constraints | Any technical limitations? Timeline? Dependencies? |
+| Success | How will you measure success? What's the happy path? |
+| Edge Cases | What shouldn't happen? Any error states to consider? |
+| Existing Patterns | Are there similar features in the codebase to follow? |
+
+**Exit Condition:** Continue until the idea is clear OR user says "proceed" or "let's move on"
+
+### Phase 2: Explore Approaches
+
+After understanding the idea, propose 2-3 concrete approaches.
+
+**Structure for Each Approach:**
+
+```markdown
+### Approach A: [Name]
+
+[2-3 sentence description]
+
+**Pros:**
+- [Benefit 1]
+- [Benefit 2]
+
+**Cons:**
+- [Drawback 1]
+- [Drawback 2]
+
+**Best when:** [Circumstances where this approach shines]
+```
+
+**Guidelines:**
+- Lead with a recommendation and explain why
+- Be honest about trade-offs
+- Consider YAGNI--simpler is usually better
+- Reference codebase patterns when relevant
+
+### Phase 3: Capture the Design
+
+Summarize key decisions as bead comments to persist the brainstorming output.
+
+**Capture key decisions and investigation results using bead comments:**
+
+For each significant decision or finding, log it to the active bead:
+
+```bash
+# Log the chosen approach
+bd comments add {BEAD_ID} "DECISION: Chose [approach name] because [rationale]. Alternatives considered: [list]"
+
+# Log key investigation findings
+bd comments add {BEAD_ID} "INVESTIGATION: Explored [topic]. Found that [key finding]. This means [implication]."
+
+# Log important facts discovered during brainstorming
+bd comments add {BEAD_ID} "FACT: [Constraint or requirement discovered during brainstorming]"
+```
+
+**If no active bead exists**, present a summary in this format:
+
+```markdown
+## What We're Building
+[Concise description--1-2 paragraphs max]
+
+## Why This Approach
+[Brief explanation of approaches considered and why this one was chosen]
+
+## Key Decisions
+- [Decision 1]: [Rationale]
+- [Decision 2]: [Rationale]
+
+## Open Questions
+- [Any unresolved questions for the planning phase]
+```
+
+### Phase 4: Handoff
+
+Present clear options for what to do next:
+
+1. **Proceed to planning** -> Run `/lavra-plan`
+2. **Refine further** -> Continue exploring the design
+3. **Done for now** -> User will return later
+
+## YAGNI Principles
+
+During brainstorming, actively resist complexity:
+
+- **Don't design for hypothetical future requirements**
+- **Choose the simplest approach that solves the stated problem**
+- **Prefer boring, proven patterns over clever solutions**
+- **Ask "Do we really need this?" when complexity emerges**
+- **Defer decisions that don't need to be made now**
+
+## Incremental Validation
+
+Keep sections short--200-300 words maximum. After each section of output, pause to validate understanding:
+
+- "Does this match what you had in mind?"
+- "Any adjustments before we continue?"
+- "Is this the direction you want to go?"
+
+This prevents wasted effort on misaligned designs.
+
+## Anti-Patterns to Avoid
+
+| Anti-Pattern | Better Approach |
+|--------------|-----------------|
+| Asking 5 questions at once | Ask one at a time |
+| Jumping to implementation details | Stay focused on WHAT, not HOW |
+| Proposing overly complex solutions | Start simple, add complexity only if needed |
+| Ignoring existing codebase patterns | Research what exists first |
+| Making assumptions without validating | State assumptions explicitly and confirm |
+| Creating lengthy design documents | Keep it concise--details go in the plan |
+
+## Integration with Planning
+
+Brainstorming answers **WHAT** to build:
+- Requirements and acceptance criteria
+- Chosen approach and rationale
+- Key decisions and trade-offs
+
+Planning answers **HOW** to build it:
+- Implementation steps and file changes
+- Technical details and code patterns
+- Testing strategy and verification
+
+When brainstorm output exists (as bead comments), `/lavra-plan` should detect it and use it as input, skipping its own idea refinement phase.

package/plugins/lavra/gemini/skills/create-agent-skills/SKILL.md

@@ -0,0 +1,304 @@
+<!-- Generated by lavra v0.6.0 -->
+<!-- Source: create-agent-skills/SKILL.md -->
+<!-- DO NOT EDIT - changes will be overwritten on next install -->
+
+---
+name: creating-agent-skills
+description: "Expert guidance for creating, writing, and refining Claude Code Skills. Use when working with SKILL.md files, authoring new skills, improving existing skills, or understanding skill structure and best practices."
+disable-model-invocation: true
+---
+
+# Creating Agent Skills
+
+This skill teaches how to create effective Claude Code Skills following Anthropic's official specification.
+
+## Core Principles
+
+### 1. Skills Are Prompts
+
+All prompting best practices apply. Be clear, be direct. Assume Claude is smart - only add context Claude doesn't have.
+
+### 2. Standard Markdown Format
+
+Use YAML frontmatter + markdown body. **No XML tags** - use standard markdown headings.
+
+```markdown
+---
+name: my-skill-name
+description: What it does and when to use it
+---
+
+# My Skill Name
+
+## Quick Start
+Immediate actionable guidance...
+
+## Instructions
+Step-by-step procedures...
+
+## Examples
+Concrete usage examples...
+```
+
+### 3. Progressive Disclosure
+
+Keep SKILL.md under 500 lines. Split detailed content into reference files. Load only what's needed.
+
+```
+my-skill/
+├── SKILL.md              # Entry point (required)
+├── reference.md          # Detailed docs (loaded when needed)
+├── examples.md           # Usage examples
+└── scripts/              # Utility scripts (executed, not loaded)
+```
+
+### 4. Effective Descriptions
+
+The description field enables skill discovery. Include both what the skill does AND when to use it. Write in third person.
+
+**Good:**
+```yaml
+description: Extracts text and tables from PDF files, fills forms, merges documents. Use when working with PDF files or when the user mentions PDFs, forms, or document extraction.
+```
+
+**Bad:**
+```yaml
+description: Helps with documents
+```
+
+## Skill Structure
+
+### Required Frontmatter
+
+| Field | Required | Max Length | Description |
+|-------|----------|------------|-------------|
+| `name` | Yes | 64 chars | Lowercase letters, numbers, hyphens only |
+| `description` | Yes | 1024 chars | What it does AND when to use it |
+| `allowed-tools` | No | - | Tools Claude can use without asking |
+| `model` | No | - | Specific model to use |
+
+### Naming Conventions
+
+Use **gerund form** (verb + -ing) for skill names:
+
+- `processing-pdfs`
+- `analyzing-spreadsheets`
+- `generating-commit-messages`
+- `reviewing-code`
+
+Avoid: `helper`, `utils`, `tools`, `anthropic-*`, `claude-*`
+
+### Body Structure
+
+Use standard markdown headings:
+
+```markdown
+# Skill Name
+
+## Quick Start
+Fastest path to value...
+
+## Instructions
+Core guidance Claude follows...
+
+## Examples
+Input/output pairs showing expected behavior...
+
+## Advanced Features
+Additional capabilities (link to reference files)...
+
+## Guidelines
+Rules and constraints...
+```
+
+## What Would You Like To Do?
+
+1. **Create new skill** - Build from scratch
+2. **Audit existing skill** - Check against best practices
+3. **Add component** - Add workflow/reference/example
+4. **Get guidance** - Understand skill design
+
+## Creating a New Skill
+
+### Step 1: Choose Type
+
+**Simple skill (single file):**
+- Under 500 lines
+- Self-contained guidance
+- No complex workflows
+
+**Progressive disclosure skill (multiple files):**
+- SKILL.md as overview
+- Reference files for detailed docs
+- Scripts for utilities
+
+### Step 2: Create SKILL.md
+
+```markdown
+---
+name: your-skill-name
+description: [What it does]. Use when [trigger conditions].
+---
+
+# Your Skill Name
+
+## Quick Start
+
+[Immediate actionable example]
+
+```[language]
+[Code example]
+```
+
+## Instructions
+
+[Core guidance]
+
+## Examples
+
+**Example 1:**
+Input: [description]
+Output:
+```
+[result]
+```
+
+## Guidelines
+
+- [Constraint 1]
+- [Constraint 2]
+```
+
+### Step 3: Add Reference Files (If Needed)
+
+Link from SKILL.md to detailed content:
+
+```markdown
+For API reference, see [REFERENCE.md](REFERENCE.md).
+For form filling guide, see [FORMS.md](FORMS.md).
+```
+
+Keep references **one level deep** from SKILL.md.
+
+### Step 4: Add Scripts (If Needed)
+
+Scripts execute without loading into context:
+
+```markdown
+## Utility Scripts
+
+Extract fields:
+```bash
+python scripts/analyze.py input.pdf > fields.json
+```
+```
+
+### Step 5: Test With Real Usage
+
+1. Test with actual tasks, not test scenarios
+2. Observe where Claude struggles
+3. Refine based on real behavior
+4. Test with Haiku, Sonnet, and Opus
+
+## Auditing Existing Skills
+
+Check against this rubric:
+
+- [ ] Valid YAML frontmatter (name + description)
+- [ ] Description includes trigger keywords
+- [ ] Uses standard markdown headings (not XML tags)
+- [ ] SKILL.md under 500 lines
+- [ ] References one level deep
+- [ ] Examples are concrete, not abstract
+- [ ] Consistent terminology
+- [ ] No time-sensitive information
+- [ ] Scripts handle errors explicitly
+
+## Common Patterns
+
+### Template Pattern
+
+Provide output templates for consistent results:
+
+```markdown
+## Report Template
+
+```markdown
+# [Analysis Title]
+
+## Executive Summary
+[One paragraph overview]
+
+## Key Findings
+- Finding 1
+- Finding 2
+
+## Recommendations
+1. [Action item]
+2. [Action item]
+```
+```
+
+### Workflow Pattern
+
+For complex multi-step tasks:
+
+```markdown
+## Migration Workflow
+
+Copy this checklist:
+
+```
+- [ ] Step 1: Backup database
+- [ ] Step 2: Run migration script
+- [ ] Step 3: Validate output
+- [ ] Step 4: Update configuration
+```
+
+**Step 1: Backup database**
+Run: `./scripts/backup.sh`
+...
+```
+
+### Conditional Pattern
+
+Guide through decision points:
+
+```markdown
+## Choose Your Approach
+
+**Creating new content?** Follow "Creation workflow" below.
+**Editing existing?** Follow "Editing workflow" below.
+```
+
+## Anti-Patterns to Avoid
+
+- **XML tags in body** - Use markdown headings instead
+- **Vague descriptions** - Be specific with trigger keywords
+- **Deep nesting** - Keep references one level from SKILL.md
+- **Too many options** - Provide a default with escape hatch
+- **Windows paths** - Always use forward slashes
+- **Punting to Claude** - Scripts should handle errors
+- **Time-sensitive info** - Use "old patterns" section instead
+
+## Reference Files
+
+For detailed guidance, see:
+
+- [official-spec.md](references/official-spec.md) - Anthropic's official skill specification
+- [best-practices.md](references/best-practices.md) - Skill authoring best practices
+
+## Success Criteria
+
+A well-structured skill:
+- Has valid YAML frontmatter with descriptive name and description
+- Uses standard markdown headings (not XML tags)
+- Keeps SKILL.md under 500 lines
+- Links to reference files for detailed content
+- Includes concrete examples with input/output pairs
+- Has been tested with real usage
+
+Sources:
+- [Agent Skills - Claude Code Docs](https://code.claude.com/docs/en/skills)
+- [Skill authoring best practices](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices)
+- [GitHub - anthropics/skills](https://github.com/anthropics/skills)

package/plugins/lavra/gemini/skills/dhh-rails-style/SKILL.md

@@ -0,0 +1,189 @@
+<!-- Generated by lavra-compound v0.6.0 -->
+<!-- Source: dhh-rails-style/SKILL.md -->
+<!-- DO NOT EDIT - changes will be overwritten on next install -->
+
+---
+name: dhh-rails-style
+description: This skill should be used when writing Ruby and Rails code in DHH's distinctive 37signals style. It applies when writing Ruby code, Rails applications, creating models, controllers, or any Ruby file. Triggers on Ruby/Rails code generation, refactoring requests, code review, or when the user mentions DHH, 37signals, Basecamp, HEY, or Campfire style. Embodies REST purity, fat models, thin controllers, Current attributes, Hotwire patterns, and the "clarity over cleverness" philosophy.
+---
+
+<objective>
+Apply 37signals/DHH Rails conventions to Ruby and Rails code. This skill provides comprehensive domain expertise extracted from analyzing production 37signals codebases (Fizzy/Campfire) and DHH's code review patterns.
+</objective>
+
+<essential_principles>
+## Core Philosophy
+
+"The best code is the code you don't write. The second best is the code that's obviously correct."
+
+**Vanilla Rails is plenty:**
+- Rich domain models over service objects
+- CRUD controllers over custom actions
+- Concerns for horizontal code sharing
+- Records as state instead of boolean columns
+- Database-backed everything (no Redis)
+- Build solutions before reaching for gems
+
+**What they deliberately avoid:**
+- devise (custom ~150-line auth instead)
+- pundit/cancancan (simple role checks in models)
+- sidekiq (Solid Queue uses database)
+- redis (database for everything)
+- view_component (partials work fine)
+- GraphQL (REST with Turbo sufficient)
+- factory_bot (fixtures are simpler)
+- rspec (Minitest ships with Rails)
+- Tailwind (native CSS with layers)
+
+**Development Philosophy:**
+- Ship, Validate, Refine - prototype-quality code to production to learn
+- Fix root causes, not symptoms
+- Write-time operations over read-time computations
+- Database constraints over ActiveRecord validations
+</essential_principles>
+
+<intake>
+What are you working on?
+
+1. **Controllers** - REST mapping, concerns, Turbo responses, API patterns
+2. **Models** - Concerns, state records, callbacks, scopes, POROs
+3. **Views & Frontend** - Turbo, Stimulus, CSS, partials
+4. **Architecture** - Routing, multi-tenancy, authentication, jobs, caching
+5. **Testing** - Minitest, fixtures, integration tests
+6. **Gems & Dependencies** - What to use vs avoid
+7. **Code Review** - Review code against DHH style
+8. **General Guidance** - Philosophy and conventions
+
+**Specify a number or describe your task.**
+</intake>
+
+<routing>
+
+| Response | Reference to Read |
+|----------|-------------------|
+| 1, controller | [controllers.md](./references/controllers.md) |
+| 2, model | [models.md](./references/models.md) |
+| 3, view, frontend, turbo, stimulus, css | [frontend.md](./references/frontend.md) |
+| 4, architecture, routing, auth, job, cache | [architecture.md](./references/architecture.md) |
+| 5, test, testing, minitest, fixture | [testing.md](./references/testing.md) |
+| 6, gem, dependency, library | [gems.md](./references/gems.md) |
+| 7, review | Read all references, then review code |
+| 8, general task | Read relevant references based on context |
+
+**After reading relevant references, apply patterns to the user's code.**
+</routing>
+
+<quick_reference>
+## Naming Conventions
+
+**Verbs:** `card.close`, `card.gild`, `board.publish` (not `set_style` methods)
+
+**Predicates:** `card.closed?`, `card.golden?` (derived from presence of related record)
+
+**Concerns:** Adjectives describing capability (`Closeable`, `Publishable`, `Watchable`)
+
+**Controllers:** Nouns matching resources (`Cards::ClosuresController`)
+
+**Scopes:**
+- `chronologically`, `reverse_chronologically`, `alphabetically`, `latest`
+- `preloaded` (standard eager loading name)
+- `indexed_by`, `sorted_by` (parameterized)
+- `active`, `unassigned` (business terms, not SQL-ish)
+
+## REST Mapping
+
+Instead of custom actions, create new resources:
+
+```
+POST /cards/:id/close    → POST /cards/:id/closure
+DELETE /cards/:id/close  → DELETE /cards/:id/closure
+POST /cards/:id/archive  → POST /cards/:id/archival
+```
+
+## Ruby Syntax Preferences
+
+```ruby
+# Symbol arrays with spaces inside brackets
+before_action :set_message, only: %i[ show edit update destroy ]
+
+# Private method indentation
+  private
+    def set_message
+      @message = Message.find(params[:id])
+    end
+
+# Expression-less case for conditionals
+case
+when params[:before].present?
+  messages.page_before(params[:before])
+else
+  messages.last_page
+end
+
+# Bang methods for fail-fast
+@message = Message.create!(params)
+
+# Ternaries for simple conditionals
+@room.direct? ? @room.users : @message.mentionees
+```
+
+## Key Patterns
+
+**State as Records:**
+```ruby
+Card.joins(:closure)         # closed cards
+Card.where.missing(:closure) # open cards
+```
+
+**Current Attributes:**
+```ruby
+belongs_to :creator, default: -> { Current.user }
+```
+
+**Authorization on Models:**
+```ruby
+class User < ApplicationRecord
+  def can_administer?(message)
+    message.creator == self || admin?
+  end
+end
+```
+</quick_reference>
+
+<reference_index>
+## Domain Knowledge
+
+All detailed patterns in `references/`:
+
+| File | Topics |
+|------|--------|
+| [controllers.md](./references/controllers.md) | REST mapping, concerns, Turbo responses, API patterns, HTTP caching |
+| [models.md](./references/models.md) | Concerns, state records, callbacks, scopes, POROs, authorization, broadcasting |
+| [frontend.md](./references/frontend.md) | Turbo Streams, Stimulus controllers, CSS layers, OKLCH colors, partials |
+| [architecture.md](./references/architecture.md) | Routing, authentication, jobs, Current attributes, caching, database patterns |
+| [testing.md](./references/testing.md) | Minitest, fixtures, unit/integration/system tests, testing patterns |
+| [gems.md](./references/gems.md) | What they use vs avoid, decision framework, Gemfile examples |
+</reference_index>
+
+<success_criteria>
+Code follows DHH style when:
+- Controllers map to CRUD verbs on resources
+- Models use concerns for horizontal behavior
+- State is tracked via records, not booleans
+- No unnecessary service objects or abstractions
+- Database-backed solutions preferred over external services
+- Tests use Minitest with fixtures
+- Turbo/Stimulus for interactivity (no heavy JS frameworks)
+- Native CSS with modern features (layers, OKLCH, nesting)
+- Authorization logic lives on User model
+- Jobs are shallow wrappers calling model methods
+</success_criteria>
+
+<credits>
+Based on [The Unofficial 37signals/DHH Rails Style Guide](https://github.com/marckohlbrugge/unofficial-37signals-coding-style-guide) by [Marc Köhlbrugge](https://x.com/marckohlbrugge), generated through deep analysis of 265 pull requests from the Fizzy codebase.
+
+**Important Disclaimers:**
+- LLM-generated guide - may contain inaccuracies
+- Code examples from Fizzy are licensed under the O'Saasy License
+- Not affiliated with or endorsed by 37signals
+</credits>