@lavralabs/lavra 0.7.0

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

@@ -0,0 +1,338 @@
+# Generated by beads-compound v0.6.0
+# DO NOT EDIT - changes will be overwritten on next install
+
+description = "Perform exhaustive code reviews using multi-agent analysis and ultra-thinking"
+
+prompt = """
+
+<objective>
+Perform exhaustive code reviews using multi-agent analysis, ultra-thinking, and Git worktrees for deep local inspection.
+</objective>
+
+<execution_context>
+<review_target> #{{args}} </review_target>
+
+<requirements>
+- Git repository with GitHub CLI (`gh`) installed and authenticated
+- Clean main/master branch
+- Proper permissions to create worktrees and access the repository
+- `bd` CLI installed for bead management
+</requirements>
+</execution_context>
+
+<process>
+
+### 1. Determine Review Target & Setup (ALWAYS FIRST)
+
+<thinking>
+First, I need to determine the review target type and set up the code for analysis.
+</thinking>
+
+#### Immediate Actions:
+
+- [ ] Determine review type: bead ID (BD-xxx), PR number (numeric), GitHub URL, or empty (current in-progress bead)
+- [ ] If bead ID provided, get bead details: `bd show {BEAD_ID} --json`
+- [ ] If no target provided, find current in-progress bead: `bd list --status in_progress --json | jq -r '.[0].id'`
+- [ ] Check current git branch
+- [ ] If ALREADY on the target branch -> proceed with analysis on current branch
+- [ ] If DIFFERENT branch than the review target -> offer to use worktree: "Use git-worktree skill for isolated checkout." Call `skill: git-worktree` with branch name
+- [ ] Fetch PR metadata using `gh pr view --json` for title, body, files, linked issues (if PR exists)
+- [ ] Set up language-specific analysis tools
+- [ ] Make sure we are on the branch we are reviewing
+
+Ensure that the code is ready for analysis (either in worktree or on current branch). ONLY then proceed to the next step.
+
+### 2. Recall Relevant Knowledge
+
+Search for knowledge related to the code being reviewed:
+
+```bash
+# Extract keywords from bead title/description
+.lavra/memory/recall.sh "{keywords from bead title}"
+.lavra/memory/recall.sh "{tech stack keywords}"
+.lavra/memory/recall.sh --recent 10
+```
+
+Present any relevant LEARNED/DECISION/FACT/PATTERN entries that reviewers should consider.
+
+#### Protected Artifacts
+
+The following paths are beads-compound pipeline artifacts and must never be flagged for deletion, removal, or gitignore by any review agent:
+
+- `.lavra/memory/knowledge.jsonl` -- Persistent knowledge store
+- `.lavra/memory/knowledge.archive.jsonl` -- Archived knowledge
+- `.lavra/memory/recall.sh` -- Knowledge search script
+
+If a review agent flags any file in `.lavra/memory/` for cleanup or removal, discard that finding during synthesis. Do not create a bead for it.
+
+### 3. Dispatch Review Agents in Parallel
+
+Run ALL or most of these agents at the same time:
+
+1. Task kieran-rails-reviewer(PR content)
+2. Task dhh-rails-reviewer(PR content)
+3. Task kieran-typescript-reviewer(PR content)
+4. Task kieran-python-reviewer(PR content)
+5. Task git-history-analyzer(PR content)
+6. Task pattern-recognition-specialist(PR content)
+7. Task architecture-strategist(PR content)
+8. Task security-sentinel(PR content)
+9. Task performance-oracle(PR content)
+10. Task data-integrity-guardian(PR content)
+11. Task agent-native-reviewer(PR content)
+12. Task julik-frontend-races-reviewer(PR content)
+
+#### Conditional Agents (Run if applicable):
+
+These agents are run ONLY when the PR matches specific criteria. Check the PR files list to determine if they apply:
+
+**If PR contains database migrations or data backfills:**
+
+13. Task data-migration-expert(PR content) - Validates ID mappings match production, checks for swapped values, verifies rollback safety
+14. Task deployment-verification-agent(PR content) - Creates Go/No-Go deployment checklist with SQL verification queries
+
+**When to run migration agents:**
+- PR includes migration files
+- PR modifies columns that store IDs, enums, or mappings
+- PR includes data backfill scripts
+- PR changes how data is read/written
+- PR title/body mentions: migration, backfill, data transformation, ID mapping
+
+### 4. Ultra-Thinking Deep Dive Phases
+
+For each phase below, spend maximum cognitive effort. Think step by step. Consider all angles. Question assumptions. And bring all reviews in a synthesis to the user.
+
+#### Phase A: Stakeholder Perspective Analysis
+
+<thinking>
+ULTRA-THINK: Put yourself in each stakeholder's shoes. What matters to them? What are their pain points?
+</thinking>
+
+1. **Developer Perspective**
+   - How easy is this to understand and modify?
+   - Are the APIs intuitive?
+   - Is debugging straightforward?
+   - Can I test this easily?
+
+2. **Operations Perspective**
+   - How do I deploy this safely?
+   - What metrics and logs are available?
+   - How do I troubleshoot issues?
+   - What are the resource requirements?
+
+3. **End User Perspective**
+   - Is the feature intuitive?
+   - Are error messages helpful?
+   - Is performance acceptable?
+   - Does it solve my problem?
+
+4. **Security Team Perspective**
+   - What's the attack surface?
+   - Are there compliance requirements?
+   - How is data protected?
+   - What are the audit capabilities?
+
+#### Phase B: Scenario Exploration
+
+<thinking>
+ULTRA-THINK: Explore edge cases and failure scenarios. What could go wrong? How does the system behave under stress?
+</thinking>
+
+- [ ] **Happy Path**: Normal operation with valid inputs
+- [ ] **Invalid Inputs**: Null, empty, malformed data
+- [ ] **Boundary Conditions**: Min/max values, empty collections
+- [ ] **Concurrent Access**: Race conditions, deadlocks
+- [ ] **Scale Testing**: 10x, 100x, 1000x normal load
+- [ ] **Network Issues**: Timeouts, partial failures
+- [ ] **Resource Exhaustion**: Memory, disk, connections
+- [ ] **Security Attacks**: Injection, overflow, DoS
+- [ ] **Data Corruption**: Partial writes, inconsistency
+- [ ] **Cascading Failures**: Downstream service issues
+
+### 5. Simplification and Minimalism Review
+
+Run the Task code-simplicity-reviewer() to see if we can simplify the code.
+
+### 6. Findings Synthesis and Bead Creation
+
+ALL findings MUST be stored as child beads of the reviewed bead. Create beads immediately after synthesis - do NOT present findings for user approval first.
+
+#### Step 1: Build Agent Finding Inventory
+
+Before synthesizing, build a complete inventory of what each agent returned:
+
+```
+From kieran-rails-reviewer: [finding 1], [finding 2], ...
+From dhh-rails-reviewer: [finding 1], [finding 2], ...
+From security-sentinel: [finding 1], [finding 2], ...
+From performance-oracle: [finding 1], [finding 2], ...
+... (one row per agent that ran)
+```
+
+This inventory is the source of truth for synthesis. Do not proceed to Step 2 until every agent's output is listed.
+
+#### Step 2: Synthesize All Findings
+
+<thinking>
+Consolidate all agent reports into a categorized list of findings.
+Remove duplicates, prioritize by severity and impact.
+</thinking>
+
+- [ ] Collect findings from the inventory above
+- [ ] Discard any findings that recommend deleting or gitignoring files in `.lavra/memory/` (see Protected Artifacts above)
+- [ ] Categorize by type: security, performance, architecture, quality, etc.
+- [ ] Assign severity levels: P1 CRITICAL, P2 IMPORTANT, P3 NICE-TO-HAVE
+- [ ] Remove duplicate or overlapping findings
+- [ ] Estimate effort for each finding (Small/Medium/Large)
+
+#### Step 2a: Completeness Verification
+
+Before creating beads, verify no agent output was silently dropped:
+
+- [ ] Every finding in the inventory is either included in the categorized list OR explicitly marked as duplicate/inapplicable with a reason
+- [ ] Count: inventory total findings vs. categorized findings + discarded -- they must reconcile
+- [ ] If any inventory items are unaccounted for, categorize them now
+
+**Do not proceed to bead creation until the inventory is fully accounted for.**
+
+#### Step 3: Create Beads for All Findings
+
+For each finding, create a child bead:
+
+```bash
+bd create "{finding title}" \
+  --parent {BEAD_ID} \
+  --type {bug|task|improvement} \
+  --priority {1-5} \
+  --tags "review,{category},{BEAD_ID}" \
+  -d "## Issue
+{Detailed description}
+
+## Severity
+{P1/P2/P3} - {Why this severity}
+
+## Location
+{file:line references}
+
+## Why This Matters
+{Impact and consequences}
+
+## Validation Criteria
+- [ ] {Test that must pass}
+- [ ] {Behavior to verify}
+
+## Testing Steps
+1. {How to reproduce/test}
+2. {Expected outcome}"
+```
+
+**Priority mapping:**
+- P1 CRITICAL -> priority 1 (blocks closing original bead)
+- P2 IMPORTANT -> priority 2 (should fix before closing)
+- P3 NICE-TO-HAVE -> priority 3-5 (can defer)
+
+#### Step 4: Link Critical Issues
+
+For P1 findings, create blocking dependencies:
+
+```bash
+bd dep relate {FINDING_BEAD_ID} {ORIGINAL_BEAD_ID}
+```
+
+This ensures the original bead cannot be closed until critical issues are resolved.
+
+#### Step 5: Log Knowledge
+
+For significant findings, log knowledge:
+
+```bash
+bd comments add {BEAD_ID} "LEARNED: {key insight from review}"
+bd comments add {BEAD_ID} "PATTERN: {pattern issue discovered}"
+```
+
+#### Step 6: Summary Report
+
+After creating all beads, present comprehensive summary:
+
+```
+## Code Review Complete
+
+**Review Target:** {BEAD_ID} - {title}
+**Branch:** {branch-name}
+
+### Findings Summary:
+
+- **Total Findings:** [X]
+- **P1 CRITICAL:** [count] - BLOCKS CLOSURE
+- **P2 IMPORTANT:** [count] - Should Fix
+- **P3 NICE-TO-HAVE:** [count] - Enhancements
+
+### Created Beads:
+
+**P1 - Critical (BLOCKS CLOSURE):**
+- {BD-XXX}: {description}
+- {BD-XXX}: {description}
+
+**P2 - Important:**
+- {BD-XXX}: {description}
+
+**P3 - Nice-to-Have:**
+- {BD-XXX}: {description}
+
+### Review Agents Used:
+- {list of agents}
+
+### Next Steps:
+
+1. **Address P1 Findings**: CRITICAL - must be fixed before closing
+   - `/beads-work {P1_BEAD_ID}` for each critical finding
+2. **Close bead** (if no P1/P2 findings): `bd close {BEAD_ID}`
+3. **Resolve in parallel**: `/beads-parallel {BEAD_ID}`
+4. **Triage remaining**: `/beads-triage {BEAD_ID}`
+5. **View all findings**: `bd list --tags "review,{BEAD_ID}"`
+```
+
+### 7. End-to-End Testing (Optional)
+
+**First, detect the project type from PR files:**
+
+| Indicator | Project Type |
+|-----------|--------------|
+| `*.xcodeproj`, `*.xcworkspace`, `Package.swift` | iOS/macOS |
+| `Gemfile`, `package.json`, `app/views/*` | Web |
+| Both iOS files AND web files | Hybrid |
+
+After presenting the Summary Report, offer appropriate testing based on project type:
+
+**For Web Projects:**
+"Want to run browser tests on the affected pages?"
+1. Yes - run browser tests
+2. No - skip
+
+**For iOS Projects:**
+"Want to run Xcode simulator tests on the app?"
+1. Yes - run Xcode tests
+2. No - skip
+
+</process>
+
+<success_criteria>
+- All review agents dispatched and findings collected
+- Complete agent finding inventory built before synthesis
+- Every finding accounted for (applied, deduplicated, or explicitly discarded with reason)
+- All findings stored as child beads with severity, validation criteria, and testing steps
+- P1 findings linked as blocking dependencies
+- Knowledge logged for significant findings
+- Summary report presented with next-step options
+</success_criteria>
+
+<guardrails>
+- P1 (CRITICAL) findings must be addressed before closing the bead -- they are linked as blocking dependencies
+- Each reviewer creates beads for issues found (not markdown files or comments)
+- Each bead has a thorough description with severity level, validation criteria, and testing steps
+- Beads are tagged with `review,{BEAD_ID}` for easy filtering
+- Use `/beads-work {ISSUE_BEAD_ID}` to fix issues found
+- The original bead cannot be closed until all blocking dependencies are resolved
+</guardrails>
+
+"""

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

@@ -0,0 +1,161 @@
+# Generated by beads-compound v0.6.0
+# DO NOT EDIT - changes will be overwritten on next install
+
+description = "Triage and categorize beads for prioritization"
+
+prompt = """
+
+<objective>
+Present all findings, decisions, or issues one by one for triage. Go through each bead and decide whether to keep, modify, dismiss, or defer it. Useful for triaging code review findings, security audit results, performance analysis, or any categorized findings that need tracking.
+</objective>
+
+<execution_context>
+<bead_input> #{{args}} </bead_input>
+
+**First, determine if the argument is a bead ID or empty:**
+
+Check if the argument matches a bead ID pattern:
+- Pattern: lowercase alphanumeric segments separated by hyphens (e.g., `bikiniup-xhr`, `beads-123`, `fix-auth-bug2`)
+- Regex: `^[a-z0-9]+-[a-z0-9]+(-[a-z0-9]+)*$`
+
+**If the argument matches a bead ID pattern:**
+
+1. Try to load the bead using the Bash tool:
+   ```bash
+   bd show "#$ARGUMENTS" --json
+   ```
+
+2. If the bead exists:
+   - Extract the `title` and `type` fields from the JSON array (first element)
+   - Example: `bd show "#{{args}}" --json | jq -r '.[0].type'`
+   - Announce: "Triaging bead #{{args}}: {title}"
+
+   **If the bead is an epic:**
+   - List all child beads:
+     ```bash
+     bd list --parent "#$ARGUMENTS" --json
+     ```
+   - Triage the epic's child beads
+
+   **If the bead is not an epic:**
+   - Triage just that single bead
+
+3. If the bead doesn't exist (command fails):
+   - Report: "Bead ID '#{{args}}' not found. Please check the ID or provide a valid bead ID."
+   - Stop execution
+
+**If the argument does NOT match a bead ID pattern (or is empty):**
+- Triage all open beads (original behavior):
+  ```bash
+  bd list --status=open --json
+  ```
+
+Read each bead's full details:
+```bash
+bd show {BEAD_ID}
+```
+</execution_context>
+
+<process>
+
+### Step 1: Present Each Bead
+
+For each bead, present in this format:
+
+```
+---
+Bead #X: {BEAD_ID} - [Brief Title]
+
+Severity: P1 (CRITICAL) / P2 (IMPORTANT) / P3 (NICE-TO-HAVE)
+
+Category: [Security/Performance/Architecture/Bug/Feature/etc.]
+
+Description:
+[Detailed explanation from bead description]
+
+Location: [file_path:line_number if applicable]
+
+Problem Scenario:
+[Step by step what's wrong or could happen]
+
+Proposed Solution:
+[How to fix it]
+
+Estimated Effort: [Small (< 2 hours) / Medium (2-8 hours) / Large (> 8 hours)]
+
+---
+What would you like to do with this bead?
+1. Keep - approve for work
+2. Modify - change priority, description, or details
+3. Dismiss - close/remove this bead
+4. Defer - keep but lower priority
+```
+
+### Step 2: Handle User Decision
+
+**When user says "Keep":**
+1. Update bead status to ready: `bd update {BEAD_ID} --status=open`
+2. Confirm: "Approved: `{BEAD_ID}` - {title} -> Ready to work on"
+
+**When user says "Modify":**
+- Ask what to modify (priority, description, details)
+- Update the bead: `bd update {BEAD_ID} --priority {N} -d "{new description}"`
+- Present revised version
+- Ask again: Keep/Modify/Dismiss/Defer
+
+**When user says "Dismiss":**
+- Close the bead: `bd close {BEAD_ID} --reason "Dismissed during triage"`
+- Log: `bd comments add {BEAD_ID} "DECISION: Dismissed during triage - {reason}"`
+- Skip to next item
+
+**When user says "Defer":**
+- Lower priority: `bd update {BEAD_ID} --priority 5`
+- Add tag: `bd update {BEAD_ID} --tags "deferred"`
+- Log: `bd comments add {BEAD_ID} "DECISION: Deferred during triage - {reason}"`
+
+### Step 3: Progress Tracking
+
+Every time you present a bead, include:
+- **Progress:** X/Y completed (e.g., "3/10 completed")
+
+### Step 4: Final Summary
+
+After all items processed:
+
+```markdown
+## Triage Complete
+
+**Total Items:** [X]
+**Kept (ready for work):** [Y]
+**Modified:** [Z]
+**Dismissed:** [A]
+**Deferred:** [B]
+
+### Approved Beads (Ready for Work):
+- {BD-XXX}: {title} - Priority {N}
+- {BD-YYY}: {title} - Priority {N}
+
+### Dismissed Beads:
+- {BD-ZZZ}: {title} - Reason: {reason}
+
+### Deferred Beads:
+- {BD-AAA}: {title} - Reason: {reason}
+```
+
+</process>
+
+<guardrails>
+- DO NOT implement fixes or write code during triage
+- Triage is for decisions only
+- Implementation happens in `/beads-parallel` or `/beads-work`
+</guardrails>
+
+<handoff>
+What would you like to do next?
+
+1. Run /beads-parallel to resolve the approved beads
+2. Run /beads-work on a specific bead
+3. Nothing for now
+</handoff>
+
+"""