@lavralabs/lavra 0.7.0

package/plugins/lavra/gemini/commands/beads-work.toml

@@ -0,0 +1,347 @@
+# Generated by beads-compound v0.6.0
+# DO NOT EDIT - changes will be overwritten on next install
+
+description = "Execute work on a bead efficiently while maintaining quality and finishing features"
+
+prompt = """
+
+<objective>
+Execute work on a bead efficiently while maintaining quality and finishing features. Takes a bead (or specification) and executes it systematically, focusing on shipping complete features by understanding requirements quickly, following existing patterns, and maintaining quality throughout.
+</objective>
+
+<execution_context>
+<input_document> #{{args}} </input_document>
+</execution_context>
+
+<process>
+
+### Phase 0: Permission Check
+
+**Only when running as a subagent** (BEAD_ID was injected into the prompt, or `--ralph`/`--teams` context is detected):
+
+Check whether the current permission mode will block autonomous execution. Subagents that need human approval for Bash/Write/Edit tools will stall silently.
+
+If tool permissions appear restricted:
+- Warn: "Permission mode may block autonomous execution. Subagents need Bash, Write, and Edit tool access without human approval."
+- Suggest: "For autonomous execution, ensure your settings.json allows Bash and Write tools, or run with --dangerously-skip-permissions. See docs/AUTONOMOUS_EXECUTION.md"
+
+This is a warning only -- continue regardless of the result.
+
+### Phase 1: Quick Start
+
+1. **Read Bead and Clarify**
+
+   If a bead ID was provided:
+   ```bash
+   bd show {BEAD_ID} --json
+   ```
+
+   Read the bead description completely including:
+   - What section (implementation requirements)
+   - Context section (research findings, constraints)
+   - Testing section (test cases to implement)
+   - Validation section (acceptance criteria)
+   - Dependencies section (blockers)
+
+   If a specification path was provided instead:
+   - Read the document completely
+   - Create a bead for tracking: `bd create "{title from spec}" -d "{spec content}" --type task`
+
+   If nothing was provided:
+   - Find the next ready bead: `bd ready --json | jq -r '.[0]'`
+   - If no ready beads, list open beads and ask which to work on
+
+   **Clarify ambiguities:**
+   - If anything is unclear or ambiguous, use **AskUserQuestion tool** now
+   - Get user approval to proceed
+   - **Do not skip this** - better to ask questions now than build the wrong thing
+
+2. **Recall Relevant Knowledge** *(required -- do not skip)*
+
+   ```bash
+   # Search memory for relevant context
+   .lavra/memory/recall.sh "{keywords from bead title}"
+   .lavra/memory/recall.sh "{tech stack keywords}"
+   ```
+
+   **You MUST output the recall results here before continuing.** If recall returns nothing, output: "No relevant knowledge found." Do not proceed to step 3 until this is done. This step exists to prevent repeating solved problems -- skipping it defeats the purpose of the memory system.
+
+3. **Check Dependencies & Related Beads**
+
+   ```bash
+   bd dep list {BEAD_ID} --json
+   ```
+
+   If there are unresolved blockers, list them and ask if the user wants to work on those first.
+
+   Check for `relates_to` links in the dependency list. For each related bead, fetch its title and description:
+   ```bash
+   bd show {RELATED_BEAD_ID}
+   ```
+   Present related bead context to inform the work -- these beads share domain knowledge but don't block each other.
+
+4. **Setup Environment**
+
+   First, check the current branch:
+
+   ```bash
+   current_branch=$(git branch --show-current)
+   default_branch=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')
+   if [ -z "$default_branch" ]; then
+     default_branch=$(git rev-parse --verify origin/main >/dev/null 2>&1 && echo "main" || echo "master")
+   fi
+   ```
+
+   Use **AskUserQuestion tool** to ask how to proceed:
+
+   **Question:** "How do you want to handle branching for this work?"
+
+   **Options:**
+   1. **Work on current branch** - Continue on `[current_branch]` as-is
+   2. **Create a feature branch** - `bd-{BEAD_ID}/{short-description}`
+   3. **Use a worktree** - Isolated copy for parallel development
+
+   Then execute the chosen option:
+
+   **Work on current branch:** proceed to next step
+
+   **Create a feature branch:**
+   ```bash
+   git pull origin [default_branch]
+   git checkout -b bd-{BEAD_ID}/{short-description}
+   ```
+
+   **Use a worktree:**
+   ```bash
+   skill: git-worktree
+   ```
+
+5. **Update Bead Status**
+
+   ```bash
+   bd update {BEAD_ID} --status in_progress
+   ```
+
+6. **Create Task List**
+   - Use TaskCreate to break the bead description into actionable tasks
+   - Use TaskUpdate with addBlockedBy/addBlocks for dependencies between tasks
+   - Include testing and quality check tasks
+
+### Phase 2: Execute
+
+1. **Task Execution Loop**
+
+   For each task in priority order:
+
+   ```
+   while (tasks remain):
+     - Mark task as in_progress with TaskUpdate
+     - Read any referenced files from the bead description
+     - Look for similar patterns in codebase
+     - Implement following existing conventions
+     - Write tests for new functionality
+     - Run tests after changes
+     - Mark task as completed with TaskUpdate
+     - Evaluate for incremental commit (see below)
+   ```
+
+2. **Incremental Commits**
+
+   After completing each task, evaluate whether to create an incremental commit:
+
+   | Commit when... | Don't commit when... |
+   |----------------|---------------------|
+   | Logical unit complete (model, service, component) | Small part of a larger unit |
+   | Tests pass + meaningful progress | Tests failing |
+   | About to switch contexts (backend -> frontend) | Purely scaffolding with no behavior |
+   | About to attempt risky/uncertain changes | Would need a "WIP" commit message |
+
+   **Heuristic:** "Can I write a commit message that describes a complete, valuable change? If yes, commit."
+
+   **Commit workflow:**
+   ```bash
+   # 1. Verify tests pass
+   # 2. Stage only related files (not `git add .`)
+   git add <files related to this logical unit>
+   # 3. Commit with conventional message
+   git commit -m "feat(scope): description of this unit"
+   ```
+
+3. **Log Knowledge as You Work** *(required -- inline, not at the end)*
+
+   **This is mandatory.** Log a comment the moment you encounter any of these triggers. Do not batch them for later -- by the time you finish the task, the details are stale and you will skip it.
+
+   | Trigger | Prefix | Example |
+   |---------|--------|---------|
+   | Read code that surprises you | `FACT:` | Column is a string `'kg'\|'lbs'`, not a boolean |
+   | Make a non-obvious implementation choice | `DECISION:` | Chose 2.5 lb rounding because smaller increments cause UI jitter |
+   | Hit an error and figure out why | `LEARNED:` | Enum comparison fails unless you cast to string first |
+   | Notice a pattern you'll want to reuse | `PATTERN:` | Service uses `.tap` to log before returning |
+   | Find a constraint that limits options | `FACT:` | API rate-limits to 10 req/s per tenant |
+
+   ```bash
+   bd comments add {BEAD_ID} "LEARNED: {key technical insight}"
+   bd comments add {BEAD_ID} "DECISION: {what was chosen and why}"
+   bd comments add {BEAD_ID} "FACT: {constraint or gotcha discovered}"
+   bd comments add {BEAD_ID} "PATTERN: {coding pattern followed}"
+   ```
+
+   **You MUST log at least one comment per task completed.** Non-trivial work always produces an insight. If you finish a task with nothing logged, you skipped this step -- go back and add it before marking the task complete.
+
+4. **Follow Existing Patterns**
+
+   - The bead description should reference similar code - read those files first
+   - Match naming conventions exactly
+   - Reuse existing components where possible
+   - Follow project coding standards (see CLAUDE.md or AGENTS.md)
+   - When in doubt, grep for similar implementations
+
+5. **Track Progress**
+   - Keep task list updated (TaskUpdate) as you complete tasks
+   - Note any blockers or unexpected discoveries
+   - Create new tasks if scope expands
+   - Keep user informed of major milestones
+
+### Phase 3: Quality Check
+
+1. **Run Core Quality Checks**
+
+   Always run before submitting:
+
+   ```bash
+   # Run full test suite (use project's test command)
+   # Run linting (per CLAUDE.md or AGENTS.md)
+   ```
+
+2. **Consider Reviewer Agents** (Optional)
+
+   Use for complex, risky, or large changes:
+
+   - **code-simplicity-reviewer**: Check for unnecessary complexity
+   - **security-sentinel**: Scan for security vulnerabilities
+   - **performance-oracle**: Check for performance issues
+
+   Run reviewers in parallel with Task tool:
+
+   ```
+   Task(code-simplicity-reviewer): "Review changes for simplicity"
+   Task(security-sentinel): "Security scan of changes"
+   ```
+
+   Present findings to user and address critical issues.
+
+3. **Quick Simplicity Check**
+
+   Run Task code-simplicity-reviewer() on the changes to catch unnecessary complexity before shipping.
+
+4. **Final Validation**
+   - All tasks marked completed (TaskList shows none pending)
+   - All tests pass
+   - Linting passes
+   - Code follows existing patterns
+   - Bead's validation criteria are met
+   - No console errors or warnings
+
+### Phase 4: Ship It
+
+1. **Create Commit**
+
+   ```bash
+   git add <changed files>
+   git status  # Review what's being committed
+   git diff --staged  # Check the changes
+
+   git commit -m "feat(scope): description of what and why"
+   ```
+
+2. **Create Pull Request**
+
+   ```bash
+   git push -u origin bd-{BEAD_ID}/{short-description}
+
+   gh pr create --title "BD-{BEAD_ID}: {description}" --body "## Summary
+   - What was built
+   - Key decisions made
+
+   ## Bead
+   {BEAD_ID}: {bead title}
+
+   ## Testing
+   - Tests added/modified
+   - Manual testing performed
+
+   ## Knowledge Captured
+   - {key learnings logged to bead}
+   "
+   ```
+
+3. **Verify Knowledge Was Captured** *(required gate -- do not skip)*
+
+   You must have logged at least one knowledge comment per task during Phase 2. **Do not proceed to the PR until this is true.** Run `bd show {BEAD_ID}` and check the comments. If there are none, add them now -- but treat this as a process failure and correct the habit going forward.
+
+   ```bash
+   bd comments add {BEAD_ID} "LEARNED: {most important insight from this work}"
+   ```
+
+4. **Offer Next Steps**
+
+   Use **AskUserQuestion tool**:
+
+   **Question:** "Work complete on {BEAD_ID}. What next?"
+
+   **Options:**
+   1. **Run `/beads-review`** - Multi-agent code review before closing
+   2. **Close bead** - Mark as complete: `bd close {BEAD_ID}`
+   3. **Run `/beads-checkpoint`** - Save progress without closing
+   4. **Continue working** - Keep implementing
+
+</process>
+
+<success_criteria>
+- [ ] All clarifying questions asked and answered
+- [ ] All tasks marked completed (TaskList shows none pending)
+- [ ] Tests pass (run project's test command)
+- [ ] Linting passes
+- [ ] Code follows existing patterns
+- [ ] Bead validation criteria met
+- [ ] Knowledge captured (at least one LEARNED/DECISION comment)
+- [ ] Commit messages follow conventional format
+- [ ] PR description includes bead reference and summary
+</success_criteria>
+
+<guardrails>
+
+### Start Fast, Execute Faster
+
+- Get clarification once at the start, then execute
+- Don't wait for perfect understanding - ask questions and move
+- The goal is to **finish the feature**, not create perfect process
+
+### The Bead is Your Guide
+
+- Bead descriptions should reference similar code and patterns
+- Load those references and follow them
+- Don't reinvent - match what exists
+
+### Test As You Go
+
+- Run tests after each change, not at the end
+- Fix failures immediately
+- Continuous testing prevents big surprises
+
+### Quality is Built In
+
+- Follow existing patterns
+- Write tests for new code
+- Run linting before pushing
+- Use reviewer agents for complex/risky changes only
+
+### Ship Complete Features
+
+- Mark all tasks completed before moving on
+- Don't leave features 80% done
+- A finished feature that ships beats a perfect feature that doesn't
+
+</guardrails>
+
+"""

package/plugins/lavra/gemini/commands/changelog.toml

@@ -0,0 +1,151 @@
+# Generated by lavra v0.6.0
+# DO NOT EDIT - changes will be overwritten on next install
+
+description = "Create engaging changelogs for recent merges to main branch"
+
+prompt = """
+
+<objective>
+Create a fun, engaging changelog summarizing the latest merges to the main branch, highlighting new features, bug fixes, and giving credit to developers. Written from the perspective of a witty and enthusiastic product marketer for an internal development team.
+</objective>
+
+<process>
+
+## Time Period
+
+- For daily changelogs: Look at PRs merged in the last 24 hours
+- For weekly summaries: Look at PRs merged in the last 7 days
+- Always specify the time period in the title (e.g., "Daily" vs "Weekly")
+- Default: Get the latest changes from the last day from the main branch of the repository
+
+## PR Analysis
+
+Analyze the provided GitHub changes and related issues. Look for:
+
+1. New features that have been added
+2. Bug fixes that have been implemented
+3. Any other significant changes or improvements
+4. References to specific issues and their details
+5. Names of contributors who made the changes
+6. Use gh cli to lookup the PRs as well and the description of the PRs
+7. Check PR labels to identify feature type (feature, bug, chore, etc.)
+8. Look for breaking changes and highlight them prominently
+9. Include PR numbers for traceability
+10. Check if PRs are linked to issues and include issue context
+
+## Content Priorities
+
+1. Breaking changes (if any) - MUST be at the top
+2. User-facing features
+3. Critical bug fixes
+4. Performance improvements
+5. Developer experience improvements
+6. Documentation updates
+
+## Formatting Guidelines
+
+Now, create a change log summary with the following guidelines:
+
+1. Keep it concise and to the point
+2. Highlight the most important changes first
+3. Group similar changes together (e.g., all new features, all bug fixes)
+4. Include issue references where applicable
+5. Mention the names of contributors, giving them credit for their work
+6. Add a touch of humor or playfulness to make it engaging
+7. Use emojis sparingly to add visual interest
+8. Keep total message under 2000 characters for Discord
+9. Use consistent emoji for each section
+10. Format code/technical terms in backticks
+11. Include PR numbers in parentheses (e.g., "Fixed login bug (#123)")
+
+## Deployment Notes
+
+When relevant, include:
+
+- Database migrations required
+- Environment variable updates needed
+- Manual intervention steps post-deploy
+- Dependencies that need updating
+
+## Output Format
+
+Your final output should be formatted as follows:
+
+<change_log>
+
+# Change Log: [Current Date]
+
+## Breaking Changes (if any)
+
+[List any breaking changes that require immediate attention]
+
+## New Features
+
+[List new features here with PR numbers]
+
+## Bug Fixes
+
+[List bug fixes here with PR numbers]
+
+## Other Improvements
+
+[List other significant changes or improvements]
+
+## Shoutouts
+
+[Mention contributors and their contributions]
+
+## Fun Fact of the Day
+
+[Include a brief, work-related fun fact or joke]
+
+</change_log>
+
+## Style Guide Review
+
+Now review the changelog using the EVERY_WRITE_STYLE.md file and go one by one to make sure you are following the style guide. Use multiple agents, run in parallel to make it faster.
+
+Remember, your final output should only include the content within the <change_log> tags. Do not include any of your thought process or the original data in the output.
+
+## Discord Posting (Optional)
+
+You can post changelogs to Discord by adding your own webhook URL:
+
+```
+# Set your Discord webhook URL
+DISCORD_WEBHOOK_URL="https://discord.com/api/webhooks/YOUR_WEBHOOK_ID/YOUR_WEBHOOK_TOKEN"
+
+# Post using curl
+curl -H "Content-Type: application/json" \
+  -d "{\"content\": \"\{\{CHANGELOG\}\}\"}" \
+  $DISCORD_WEBHOOK_URL
+```
+
+To get a webhook URL, go to your Discord server -> Server Settings -> Integrations -> Webhooks -> New Webhook.
+
+</process>
+
+<guardrails>
+- If no changes in the time period, post a "quiet day" message: "Quiet day! No new changes merged."
+- If unable to fetch PR details, list the PR numbers for manual review
+- Always validate message length before posting to Discord (max 2000 chars)
+</guardrails>
+
+<context>
+
+## Schedule Recommendations
+
+- Run daily at 6 AM NY time for previous day's changes
+- Run weekly summary on Mondays for the previous week
+- Special runs after major releases or deployments
+
+## Audience Considerations
+
+Adjust the tone and detail level based on the channel:
+
+- **Dev team channels**: Include technical details, performance metrics, code snippets
+- **Product team channels**: Focus on user-facing changes and business impact
+- **Leadership channels**: Highlight progress on key initiatives and blockers
+</context>
+
+"""

package/plugins/lavra/gemini/commands/create-agent-skill.toml

@@ -0,0 +1,18 @@
+# Generated by beads-compound v0.6.0
+# DO NOT EDIT - changes will be overwritten on next install
+
+description = "Create or edit Claude Code skills with expert guidance on structure and best practices"
+
+prompt = """
+
+<objective>
+Create or edit Claude Code skills by invoking the create-agent-skills skill with expert guidance on structure and best practices.
+</objective>
+
+<process>
+
+Invoke the create-agent-skills skill for: {{args}}
+
+</process>
+
+"""

package/plugins/lavra/gemini/commands/deploy-docs.toml

@@ -0,0 +1,68 @@
+# Generated by beads-compound v0.6.0
+# DO NOT EDIT - changes will be overwritten on next install
+
+description = "Validate and prepare documentation for GitHub Pages deployment"
+
+prompt = """
+
+<objective>
+Validate the documentation site structure, check component counts and JSON validity, and prepare for GitHub Pages deployment.
+</objective>
+
+<process>
+
+## Step 1: Validate Documentation
+
+Run these checks:
+
+```bash
+# Count components
+echo "Agents: $(find plugins/beads-compound/agents -name '*.md' | wc -l)"
+echo "Commands: $(ls plugins/beads-compound/commands/*.md | wc -l)"
+echo "Skills: $(ls -d plugins/beads-compound/skills/*/ 2>/dev/null | wc -l)"
+
+# Validate JSON
+cat .claude-plugin/marketplace.json | jq . > /dev/null && echo "marketplace.json valid"
+cat plugins/beads-compound/.claude-plugin/plugin.json | jq . > /dev/null && echo "plugin.json valid"
+```
+
+## Step 2: Check for Uncommitted Changes
+
+```bash
+git status --porcelain plugins/beads-compound/
+```
+
+If there are uncommitted changes, warn the user to commit first.
+
+## Step 3: Deployment Instructions
+
+Since GitHub Pages deployment requires a workflow file with special permissions, provide these instructions:
+
+### First-time Setup
+
+1. Create `.github/workflows/deploy-docs.yml` with the GitHub Pages workflow
+2. Go to repository Settings > Pages
+3. Set Source to "GitHub Actions"
+
+### Deploying
+
+After merging to `main`, the docs will auto-deploy. Or:
+
+1. Go to Actions tab
+2. Select "Deploy Documentation to GitHub Pages"
+3. Click "Run workflow"
+
+</process>
+
+<success_criteria>
+- All HTML pages present
+- JSON files valid
+- Component counts match
+
+### Next Steps
+- [ ] Commit any pending changes
+- [ ] Push to main branch
+- [ ] Verify GitHub Pages workflow exists
+</success_criteria>
+
+"""