@lavralabs/lavra 0.7.0

package/plugins/lavra/gemini/commands/agent-native-audit.toml

@@ -0,0 +1,284 @@
+# Generated by beads-compound v0.6.0
+# DO NOT EDIT - changes will be overwritten on next install
+
+description = "Run comprehensive agent-native architecture review with scored principles"
+
+prompt = """
+
+<objective>
+Conduct a comprehensive review of the codebase against agent-native architecture principles, launching parallel sub-agents for each principle and producing a scored report.
+</objective>
+
+<execution_context>
+
+If {{args}} specifies a single principle (e.g., "action parity"), only run that sub-agent and provide detailed findings for that principle alone.
+
+Valid arguments:
+- `action parity` or `1`
+- `tools` or `primitives` or `2`
+- `context` or `injection` or `3`
+- `shared` or `workspace` or `4`
+- `crud` or `5`
+- `ui` or `integration` or `6`
+- `discovery` or `7`
+- `prompt` or `features` or `8`
+
+</execution_context>
+
+<context>
+
+## Core Principles to Audit
+
+1. **Action Parity** - "Whatever the user can do, the agent can do"
+2. **Tools as Primitives** - "Tools provide capability, not behavior"
+3. **Context Injection** - "System prompt includes dynamic context about app state"
+4. **Shared Workspace** - "Agent and user work in the same data space"
+5. **CRUD Completeness** - "Every entity has full CRUD (Create, Read, Update, Delete)"
+6. **UI Integration** - "Agent actions immediately reflected in UI"
+7. **Capability Discovery** - "Users can discover what the agent can do"
+8. **Prompt-Native Features** - "Features are prompts defining outcomes, not code"
+
+</context>
+
+<process>
+
+## Step 1: Load the Agent-Native Skill
+
+First, invoke the agent-native-architecture skill to understand all principles:
+
+```
+/agent-native-architecture
+```
+
+Select option 7 (action parity) to load the full reference material.
+
+## Step 2: Launch Parallel Sub-Agents
+
+Launch 8 parallel sub-agents using the Task tool with `subagent_type: Explore`, one for each principle. Each agent should:
+
+1. Enumerate ALL instances in the codebase (user actions, tools, contexts, data stores, etc.)
+2. Check compliance against the principle
+3. Provide a SPECIFIC SCORE like "X out of Y (percentage%)"
+4. List specific gaps and recommendations
+
+**Agent 1: Action Parity**
+```
+Audit for ACTION PARITY - "Whatever the user can do, the agent can do."
+
+Tasks:
+1. Enumerate ALL user actions in frontend (API calls, button clicks, form submissions)
+   - Search for API service files, fetch calls, form handlers
+   - Check routes and components for user interactions
+2. Check which have corresponding agent tools
+   - Search for agent tool definitions
+   - Map user actions to agent capabilities
+3. Score: "Agent can do X out of Y user actions"
+
+Format:
+## Action Parity Audit
+### User Actions Found
+| Action | Location | Agent Tool | Status |
+### Score: X/Y (percentage%)
+### Missing Agent Tools
+### Recommendations
+```
+
+**Agent 2: Tools as Primitives**
+```
+Audit for TOOLS AS PRIMITIVES - "Tools provide capability, not behavior."
+
+Tasks:
+1. Find and read ALL agent tool files
+2. Classify each as:
+   - PRIMITIVE (good): read, write, store, list - enables capability without business logic
+   - WORKFLOW (bad): encodes business logic, makes decisions, orchestrates steps
+3. Score: "X out of Y tools are proper primitives"
+
+Format:
+## Tools as Primitives Audit
+### Tool Analysis
+| Tool | File | Type | Reasoning |
+### Score: X/Y (percentage%)
+### Problematic Tools (workflows that should be primitives)
+### Recommendations
+```
+
+**Agent 3: Context Injection**
+```
+Audit for CONTEXT INJECTION - "System prompt includes dynamic context about app state"
+
+Tasks:
+1. Find context injection code (search for "context", "system prompt", "inject")
+2. Read agent prompts and system messages
+3. Enumerate what IS injected vs what SHOULD be:
+   - Available resources (files, drafts, documents)
+   - User preferences/settings
+   - Recent activity
+   - Available capabilities listed
+   - Session history
+   - Workspace state
+
+Format:
+## Context Injection Audit
+### Context Types Analysis
+| Context Type | Injected? | Location | Notes |
+### Score: X/Y (percentage%)
+### Missing Context
+### Recommendations
+```
+
+**Agent 4: Shared Workspace**
+```
+Audit for SHARED WORKSPACE - "Agent and user work in the same data space"
+
+Tasks:
+1. Identify all data stores/tables/models
+2. Check if agents read/write to SAME tables or separate ones
+3. Look for sandbox isolation anti-pattern (agent has separate data space)
+
+Format:
+## Shared Workspace Audit
+### Data Store Analysis
+| Data Store | User Access | Agent Access | Shared? |
+### Score: X/Y (percentage%)
+### Isolated Data (anti-pattern)
+### Recommendations
+```
+
+**Agent 5: CRUD Completeness**
+```
+Audit for CRUD COMPLETENESS - "Every entity has full CRUD"
+
+Tasks:
+1. Identify all entities/models in the codebase
+2. For each entity, check if agent tools exist for:
+   - Create
+   - Read
+   - Update
+   - Delete
+3. Score per entity and overall
+
+Format:
+## CRUD Completeness Audit
+### Entity CRUD Analysis
+| Entity | Create | Read | Update | Delete | Score |
+### Overall Score: X/Y entities with full CRUD (percentage%)
+### Incomplete Entities (list missing operations)
+### Recommendations
+```
+
+**Agent 6: UI Integration**
+```
+Audit for UI INTEGRATION - "Agent actions immediately reflected in UI"
+
+Tasks:
+1. Check how agent writes/changes propagate to frontend
+2. Look for:
+   - Streaming updates (SSE, WebSocket)
+   - Polling mechanisms
+   - Shared state/services
+   - Event buses
+   - File watching
+3. Identify "silent actions" anti-pattern (agent changes state but UI doesn't update)
+
+Format:
+## UI Integration Audit
+### Agent Action -> UI Update Analysis
+| Agent Action | UI Mechanism | Immediate? | Notes |
+### Score: X/Y (percentage%)
+### Silent Actions (anti-pattern)
+### Recommendations
+```
+
+**Agent 7: Capability Discovery**
+```
+Audit for CAPABILITY DISCOVERY - "Users can discover what the agent can do"
+
+Tasks:
+1. Check for these 7 discovery mechanisms:
+   - Onboarding flow showing agent capabilities
+   - Help documentation
+   - Capability hints in UI
+   - Agent self-describes in responses
+   - Suggested prompts/actions
+   - Empty state guidance
+   - Slash commands (/help, /tools)
+2. Score against 7 mechanisms
+
+Format:
+## Capability Discovery Audit
+### Discovery Mechanism Analysis
+| Mechanism | Exists? | Location | Quality |
+### Score: X/7 (percentage%)
+### Missing Discovery
+### Recommendations
+```
+
+**Agent 8: Prompt-Native Features**
+```
+Audit for PROMPT-NATIVE FEATURES - "Features are prompts defining outcomes, not code"
+
+Tasks:
+1. Read all agent prompts
+2. Classify each feature/behavior as defined in:
+   - PROMPT (good): outcomes defined in natural language
+   - CODE (bad): business logic hardcoded
+3. Check if behavior changes require prompt edit vs code change
+
+Format:
+## Prompt-Native Features Audit
+### Feature Definition Analysis
+| Feature | Defined In | Type | Notes |
+### Score: X/Y (percentage%)
+### Code-Defined Features (anti-pattern)
+### Recommendations
+```
+
+## Step 3: Compile Summary Report
+
+After all agents complete, compile a summary with:
+
+```markdown
+## Agent-Native Architecture Review: [Project Name]
+
+### Overall Score Summary
+
+| Core Principle | Score | Percentage | Status |
+|----------------|-------|------------|--------|
+| Action Parity | X/Y | Z% | Pass/Warn/Fail |
+| Tools as Primitives | X/Y | Z% | Pass/Warn/Fail |
+| Context Injection | X/Y | Z% | Pass/Warn/Fail |
+| Shared Workspace | X/Y | Z% | Pass/Warn/Fail |
+| CRUD Completeness | X/Y | Z% | Pass/Warn/Fail |
+| UI Integration | X/Y | Z% | Pass/Warn/Fail |
+| Capability Discovery | X/Y | Z% | Pass/Warn/Fail |
+| Prompt-Native Features | X/Y | Z% | Pass/Warn/Fail |
+
+**Overall Agent-Native Score: X%**
+
+### Status Legend
+- Pass: Excellent (80%+)
+- Warn: Partial (50-79%)
+- Fail: Needs Work (<50%)
+
+### Top 10 Recommendations by Impact
+
+| Priority | Action | Principle | Effort |
+|----------|--------|-----------|--------|
+
+### What's Working Excellently
+
+[List top 5 strengths]
+```
+
+</process>
+
+<success_criteria>
+- [ ] All 8 sub-agents complete their audits
+- [ ] Each principle has a specific numeric score (X/Y format)
+- [ ] Summary table shows all scores and status indicators
+- [ ] Top 10 recommendations are prioritized by impact
+- [ ] Report identifies both strengths and gaps
+</success_criteria>
+
+"""

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

@@ -0,0 +1,292 @@
+# Generated by beads-compound v0.6.0
+# DO NOT EDIT - changes will be overwritten on next install
+
+description = "Explore requirements and approaches through collaborative dialogue before planning"
+
+prompt = """
+
+<objective>
+Brainstorm a feature or improvement through collaborative dialogue. Brainstorming helps answer **WHAT** to build, surfaces gray areas that need decisions, and breaks the vision into implementation phases filed as child beads. It precedes `/beads-design`, which answers **HOW** to build each phase.
+</objective>
+
+<execution_context>
+<raw_argument> #{{args}} </raw_argument>
+
+**First, determine if the argument is a bead ID or a feature description:**
+
+Check if the argument matches a bead ID pattern:
+- Pattern: lowercase alphanumeric segments separated by hyphens (e.g., `bikiniup-xhr`, `beads-123`, `explore-auth2`)
+- 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 `description` fields from the JSON array (first element)
+   - Example: `bd show "#{{args}}" --json | jq -r '.[0].title'` and `jq -r '.[0].description'`
+   - Use the bead's title and description as context for brainstorming
+   - Announce: "Brainstorming bead #{{args}}: {title}"
+   - Continue brainstorming to explore the idea more deeply
+
+3. If the bead doesn't exist (command fails):
+   - Report: "Bead ID '#{{args}}' not found. Please check the ID or provide a feature description instead."
+   - Stop execution
+
+**If the argument does NOT match a bead ID pattern:**
+- Treat it as a feature description: `<feature_description>#{{args}}</feature_description>`
+- Continue with the workflow
+
+**If the argument is empty:**
+- Ask: "What would you like to explore? Please provide either a bead ID (e.g., 'bikiniup-xhr') or describe the feature, problem, or improvement you're thinking about."
+
+Do not proceed until you have a clear feature description from the user.
+</execution_context>
+
+<context>
+**Note: The current year is 2026.** Use this when dating brainstorm documents.
+
+**Process knowledge:** Load the `brainstorming` skill for detailed question techniques, approach exploration patterns, and YAGNI principles.
+</context>
+
+<process>
+
+### Phase 0: Assess Requirements Clarity
+
+Evaluate whether brainstorming is needed based on the feature description.
+
+**Clear requirements indicators:**
+- Specific acceptance criteria provided
+- Referenced existing patterns to follow
+- Described exact expected behavior
+- Constrained, well-defined scope
+
+**If requirements are already clear:**
+Use **AskUserQuestion tool** to suggest: "Your requirements seem detailed enough to proceed directly to planning. Should I run `/beads-plan` instead, or would you like to explore the idea further?"
+
+### Phase 1: Understand the Idea
+
+#### 1.1 Repository Research (Lightweight)
+
+Run a quick repo scan to understand existing patterns:
+
+- Task repo-research-analyst("Understand existing patterns related to: <feature_description>")
+
+Focus on: similar features, established patterns, CLAUDE.md or AGENTS.md guidance.
+
+#### 1.2 Check Existing Knowledge
+
+Search for relevant knowledge from past sessions:
+
+```bash
+.lavra/memory/recall.sh "{keywords from feature description}"
+```
+
+Present any relevant entries that might inform the brainstorm.
+
+#### 1.3 Collaborative Dialogue (Deep Questioning)
+
+Use the **AskUserQuestion tool** to ask questions **one at a time**. Keep asking until the picture is clear -- do not rush this phase.
+
+**Guidelines (see `brainstorming` skill for detailed techniques):**
+- Prefer multiple choice when natural options exist
+- Start broad, then narrow progressively
+
+**Questioning progression:**
+
+1. **Vision exploration** (start here):
+   - "What does success look like when this is done?"
+   - "Who is this for? What's their day-to-day context?"
+   - "What triggered this idea -- a pain point, an opportunity, or something else?"
+
+2. **Constraint discovery** (narrow down):
+   - Tech stack preferences or requirements
+   - Timeline pressure (is this urgent or exploratory?)
+   - Team size and skill distribution
+   - Existing patterns in the codebase to follow or avoid
+   - Dependencies on other systems or features
+
+3. **Scope sharpening** (lock boundaries):
+   - "What should this explicitly NOT do?"
+   - "What's the smallest version that would still be valuable?"
+   - Validate assumptions explicitly: "I'm assuming X. Is that correct?"
+
+4. **Success criteria** (close the loop):
+   - "How will you know this feature is working well?"
+   - "What's the happy path? What's the worst failure mode?"
+
+**Exit condition:** Continue until the picture is clear (vision, constraints, scope, and success criteria are all addressed) OR user says "proceed."
+
+### Phase 2: Gray Area Identification
+
+Scan the entire conversation so far for ambiguities where reasonable developers might choose differently.
+
+**2.1 Present gray areas:**
+
+Use **AskUserQuestion tool** to present a numbered list:
+
+"Before we explore approaches, I see these areas where we need a decision:
+
+1. {Gray area 1} -- e.g., should X be synchronous or async?
+2. {Gray area 2} -- e.g., do we handle Y at the API layer or the client?
+3. {Gray area 3} -- ...
+
+Which would you like to discuss? (Pick numbers, or 'all', or 'skip' if none matter yet)"
+
+**2.2 Explore selected gray areas:**
+
+For each selected gray area, ask 3-4 targeted questions using **AskUserQuestion tool** (one at a time) to drive toward a decision.
+
+**2.3 Capture decisions immediately:**
+
+After each gray area is resolved, log it right away -- do not wait for the capture phase:
+
+```bash
+bd comments add {BEAD_ID} "DECISION: {gray area} -- chose {option} because {rationale}. Alternatives considered: {list}"
+```
+
+If no bead exists yet, queue the decisions for Phase 5.
+
+### Phase 3: Explore Approaches
+
+Propose **2-3 concrete approaches** based on research, conversation, and resolved gray areas.
+
+For each approach, provide:
+- Brief description (2-3 sentences)
+- Pros and cons
+- When it's best suited
+
+Lead with your recommendation and explain why. Apply YAGNI -- prefer simpler solutions.
+
+Use **AskUserQuestion tool** to ask which approach the user prefers.
+
+### Phase 4: Phase Identification
+
+Based on requirements, decisions, and the chosen approach, identify logical implementation phases.
+
+**4.1 Present phases:**
+
+Use **AskUserQuestion tool** to present the proposed phases:
+
+"Based on our discussion, here are the implementation phases I'd suggest:
+
+Phase 1: {title} -- {one-line scope}
+Phase 2: {title} -- {one-line scope}
+Phase 3: {title} -- {one-line scope}
+
+Would you like to reorder, merge, split, or adjust any of these?"
+
+**4.2 File phases as child beads:**
+
+After confirmation, create the epic bead (if not already created) and file each phase:
+
+```bash
+# Create epic bead if it doesn't exist yet
+bd create --title="Brainstorm: {topic}" --type=epic --labels=brainstorm -d "{structured description -- see Phase 5}"
+
+# File each phase as a child bead
+bd create --title="Phase 1: {title}" --description="{scope + goals + locked decisions relevant to this phase}" --type=task --parent={EPIC_BEAD_ID}
+bd create --title="Phase 2: {title}" --description="{scope + goals + locked decisions relevant to this phase}" --type=task --parent={EPIC_BEAD_ID}
+bd create --title="Phase 3: {title}" --description="{scope + goals + locked decisions relevant to this phase}" --type=task --parent={EPIC_BEAD_ID}
+```
+
+Each phase bead description should include:
+- Scope: what's in and out for this phase
+- Goals: what's done when this phase is complete
+- Locked decisions: relevant decisions from Phase 2 that apply to this phase
+
+### Phase 5: Capture the Design
+
+Update the epic bead description with structured requirements:
+
+```bash
+bd update {EPIC_BEAD_ID} -d "$(cat <<'EOF'
+## Vision
+{What success looks like -- 1-2 sentences}
+
+## Requirements
+1. {Must-have requirement}
+2. {Must-have requirement}
+3. ...
+
+## Non-Requirements
+- {Explicitly excluded scope}
+- {Things this does NOT do}
+
+## Locked Decisions
+- {Decision from gray area exploration}
+- {Decision from gray area exploration}
+
+## Phases
+- {PHASE_1_BEAD_ID}: Phase 1 -- {title}
+- {PHASE_2_BEAD_ID}: Phase 2 -- {title}
+- {PHASE_3_BEAD_ID}: Phase 3 -- {title}
+EOF
+)"
+```
+
+Log remaining knowledge comments:
+
+```bash
+bd comments add {EPIC_BEAD_ID} "INVESTIGATION: {key findings from exploration}"
+bd comments add {EPIC_BEAD_ID} "FACT: {constraints discovered}"
+bd comments add {EPIC_BEAD_ID} "PATTERN: {patterns to follow}"
+```
+
+### Phase 6: Handoff
+
+Use **AskUserQuestion tool** to present next steps:
+
+**Question:** "Brainstorm captured as {EPIC_BEAD_ID} with {N} phases filed as child beads. What would you like to do next?"
+
+**Options:**
+1. **Proceed to design** -- Run `/beads-design {EPIC_BEAD_ID}` to design all phases
+2. **Refine further** -- Continue exploring
+3. **Done for now** -- Return later
+
+</process>
+
+<success_criteria>
+- Feature description is clear and well-understood (vision, constraints, scope, success criteria)
+- Gray areas were identified and resolved with the user
+- 2-3 approaches were explored with pros/cons
+- An epic bead was created with structured description (vision, requirements, non-requirements, locked decisions, phases)
+- Implementation phases were identified, confirmed, and filed as child beads
+- Key decisions captured as DECISION comments immediately when resolved
+- Additional knowledge logged as INVESTIGATION/FACT/PATTERN comments
+- User was offered clear next steps (with `/beads-design` as primary option)
+</success_criteria>
+
+<guardrails>
+- **Stay focused on WHAT, not HOW** - Implementation details belong in the plan
+- **Ask one question at a time** - Don't overwhelm
+- **Apply YAGNI** - Prefer simpler approaches
+- **Keep outputs concise** - 200-300 words per section max
+- NEVER CODE! Just explore and document decisions.
+</guardrails>
+
+<handoff>
+```
+Brainstorm complete!
+
+Epic: {EPIC_BEAD_ID} - Brainstorm: {topic}
+
+Phases:
+- {PHASE_1_BEAD_ID}: Phase 1 -- {title}
+- {PHASE_2_BEAD_ID}: Phase 2 -- {title}
+- {PHASE_3_BEAD_ID}: Phase 3 -- {title}
+
+Locked decisions:
+- [Decision 1]
+- [Decision 2]
+
+Knowledge captured: {count} entries logged to knowledge.jsonl
+
+Next: Run `/beads-design {EPIC_BEAD_ID}` to design all phases.
+```
+</handoff>
+
+"""