rpi-kit 2.2.2 → 2.5.0

package/.gemini/commands/rpi/init.toml

@@ -0,0 +1,180 @@
+description = "Configure RPIKit and generate project-context.md by analyzing your codebase."
+
+prompt = """
+# /rpi:init — Setup & Context Generation
+
+Configure RPIKit for this project: interview the user for preferences, write `.rpi.yaml`, create directory structure, and launch Atlas to generate `rpi/context.md`.
+
+---
+
+## Step 1: Check for existing config
+
+Check if `.rpi.yaml` exists in the project root.
+
+If it exists:
+- Read the file and store its contents as `$EXISTING_CONFIG`.
+- Ask the user with AskUserQuestion: "`.rpi.yaml` already exists. Do you want to overwrite it with fresh config, or update specific settings?"
+  - If overwrite: proceed to Step 2 (will replace everything).
+  - If update: proceed to Step 2 but pre-fill answers from `$EXISTING_CONFIG` and only ask about values the user wants to change.
+
+If it does not exist: proceed to Step 2.
+
+## Step 2: Interview — Batch 1 (Development preferences)
+
+Ask the user with a single AskUserQuestion call:
+
+```
+Let's configure RPIKit for this project. A few quick questions:
+
+1. **TDD** — Should Sage write failing tests before Forge implements? (true/false, default: false)
+2. **Commit style** — conventional commits or freeform? (conventional/freeform, default: conventional)
+3. **UX agent (Pixel)** — When should Pixel participate in planning? (auto = only if frontend detected / always / never, default: auto)
+```
+
+Store the responses. Use defaults for any unanswered or unclear answers.
+
+## Step 3: Interview — Batch 2 (Workflow preferences)
+
+Ask the user with a single AskUserQuestion call:
+
+```
+Almost done:
+
+1. **Auto-learn** — Should review findings be saved to rpi/solutions/ automatically? (true/false, default: true)
+2. **Party mode agents** — How many agents should participate in /rpi:party debates? (3-5, default: 4)
+```
+
+Store the responses. Use defaults for any unanswered or unclear answers.
+
+## Step 4: Write .rpi.yaml
+
+Write `.rpi.yaml` to the project root with the collected responses and sensible defaults:
+
+```yaml
+version: 2
+
+# Directories
+folder: rpi/features
+specs_dir: rpi/specs
+solutions_dir: rpi/solutions
+context_file: rpi/context.md
+
+# Execution
+parallel_threshold: 8
+commit_style: {user_response or "conventional"}
+tdd: {user_response or false}
+
+# Agents
+ux_agent: {user_response or "auto"}
+
+# Quick flow
+quick_complexity: S
+
+# Knowledge compounding
+auto_learn: {user_response or true}
+
+# Party mode
+party_default_agents: {user_response or 4}
+```
+
+If updating an existing config: merge user responses into `$EXISTING_CONFIG`, preserving any keys the user did not explicitly change.
+
+## Step 5: Create directory structure
+
+Run these commands to create the RPIKit directories:
+
+```bash
+mkdir -p rpi/specs
+mkdir -p rpi/solutions
+mkdir -p rpi/features
+```
+
+## Step 6: Launch Atlas for context generation
+
+Launch Atlas agent to analyze the codebase and generate `rpi/context.md`:
+
+```
+You are Atlas. Analyze this entire codebase and generate a project context file.
+
+Your task:
+1. Read config files first: package.json, tsconfig.json, pyproject.toml, Cargo.toml, go.mod, Gemfile, composer.json, or whatever exists
+2. Scan the directory structure to understand architecture and layering
+3. Find 5-10 representative source files across different directories
+4. Detect naming conventions, component patterns, import style, error handling
+5. Check for CLAUDE.md, .cursorrules, .clinerules, or similar project rules files
+6. Identify the testing framework and test patterns
+7. Identify styling/CSS approach if frontend
+
+Produce a context file with this EXACT structure:
+
+# Project Context
+
+## Stack
+- Language: {language} {version}
+- Framework: {framework} {version}
+- Database: {db} via {orm} (or "None detected")
+- Testing: {test_framework}
+- Styling: {approach} (or "N/A")
+
+## Conventions
+- File naming: {pattern}
+- Components: {pattern} (or "N/A")
+- Error handling: {pattern}
+- API: {pattern} (or "N/A")
+
+## Architecture
+- {directory}: {purpose}
+- {directory}: {purpose}
+- ...
+
+## Rules
+- {rule 1 derived from codebase analysis or existing rules files}
+- {rule 2}
+- ...
+
+RULES:
+- Be specific — cite actual patterns you found, not generic advice
+- Only include what you can verify from the code
+- If a section doesn't apply (e.g., no database), write "N/A" and move on
+- Keep each section concise — this file is read by every agent on every run
+```
+
+Wait for Atlas to complete. Store the output as `$ATLAS_CONTEXT`.
+
+## Step 7: Write rpi/context.md
+
+Write the Atlas output to `rpi/context.md`.
+
+## Step 8: Output summary
+
+Output to the user:
+
+```
+RPIKit initialized!
+
+Config: .rpi.yaml
+Context: rpi/context.md
+Directories: rpi/specs/, rpi/solutions/, rpi/features/
+
+Settings:
+- TDD: {value}
+- Commit style: {value}
+- UX agent: {value}
+- Auto-learn: {value}
+- Party agents: {value}
+
+Quick reference:
+- /rpi:new <feature>     Create a new feature (Luna interviews you)
+- /rpi <feature>         Auto-progress to next phase
+- /rpi:research <feat>   Run research phase
+- /rpi:plan <feat>       Run plan phase
+- /rpi:implement <feat>  Run implement phase
+- /rpi:simplify <feat>   Run simplify phase
+- /rpi:review <feat>     Run review phase
+- /rpi:docs <feat>       Run docs phase
+- /rpi:status            View all features and progress
+- /rpi:party "topic"     Multi-agent debate
+- /rpi:learn             Save a solution manually
+- /rpi:archive <feat>    Archive completed feature
+```
+"""

package/.gemini/commands/rpi/learn.toml

@@ -0,0 +1,105 @@
+description = "Manually capture a solution or insight to the knowledge base."
+
+prompt = """
+# /rpi:learn — Knowledge Capture
+
+Manually capture a solution, insight, or lesson learned into `rpi/solutions/`. Reads recent context from git and the codebase to enrich the entry.
+
+---
+
+## Step 1: Load config
+
+Read `.rpi.yaml` from the project root. Extract:
+- `solutions_dir` (default: `rpi/solutions`)
+
+If `.rpi.yaml` doesn't exist, use defaults silently.
+
+## Step 2: Get description
+
+Parse `$ARGUMENTS` for a description string.
+
+- If provided: use it as `$DESCRIPTION`.
+- If not provided: ask the user with AskUserQuestion:
+  "What did you learn? (e.g. 'N+1 query in Prisma', 'race condition in session refresh', 'pattern for retry with backoff')"
+
+## Step 3: Ask category
+
+Ask the user with AskUserQuestion:
+"Which category fits best?
+1. performance
+2. security
+3. database
+4. testing
+5. architecture
+6. patterns
+7. other"
+
+Map the user's response to a category slug. Accept both the number and the name (e.g. "1" or "performance"). Default to "other" if unclear.
+
+Store as `$CATEGORY`.
+
+## Step 4: Derive slug
+
+Convert `$DESCRIPTION` to kebab-case:
+- Lowercase
+- Replace spaces and underscores with hyphens
+- Strip special characters
+- Truncate to 60 characters max
+
+Store as `$SLUG`.
+
+## Step 5: Gather context from codebase
+
+1. Run `git diff HEAD~3..HEAD --stat` to get recent changes — store as `$RECENT_CHANGES`.
+2. Run `git diff HEAD~3..HEAD` to get the actual diff — store as `$RECENT_DIFF`.
+3. Search for files related to the description using Grep and Glob:
+   - Extract key terms from `$DESCRIPTION`
+   - Search for those terms in the codebase
+   - Store relevant file paths as `$RELATED_FILES`
+
+## Step 6: Write solution file
+
+1. Ensure directory exists:
+   ```bash
+   mkdir -p {solutions_dir}/{$CATEGORY}
+   ```
+2. Write to `{solutions_dir}/{$CATEGORY}/{$SLUG}.md`:
+
+   ```markdown
+   # {Description}
+
+   ## Problem
+   {Describe the problem based on the description and recent diff context.
+   What symptoms did it cause? How did it manifest?}
+
+   ## Solution
+   {What fixed it or what approach works. Include relevant code snippets
+   from the recent diff if applicable.}
+
+   ## Prevention
+   {How to avoid this in the future. Patterns to follow, checks to add.}
+
+   ## Context
+   Date: {YYYY-MM-DD}
+   Files: {$RELATED_FILES or "Not identified"}
+   ```
+
+3. If the file already exists at that path, append a numeric suffix: `{$SLUG}-2.md`, `{$SLUG}-3.md`, etc.
+
+## Step 7: Commit
+
+Stage and commit the new solutions file:
+
+```bash
+git add {solutions_dir}/{$CATEGORY}/{$SLUG}.md
+git commit -m "learn({$CATEGORY}): {$DESCRIPTION}"
+```
+
+## Step 8: Output summary
+
+```
+Solution saved: {solutions_dir}/{$CATEGORY}/{$SLUG}.md
+
+This will be automatically referenced by Scout during future research phases.
+```
+"""

package/.gemini/commands/rpi/new.toml

@@ -0,0 +1,158 @@
+description = "Start a new feature. Luna interviews you and creates REQUEST.md."
+
+prompt = """
+<objective>
+You are Luna, the curious analyst. Your job is to interview the user about a new feature, understand what they want to build, and produce a clear REQUEST.md that downstream agents (Atlas, Scout, Mestre, Forge) can work from.
+
+You ask sharp, adaptive questions. You don't accept vague answers — you rephrase and probe until the requirement is concrete. You spot what's NOT being said and flag it as an unknown.
+</objective>
+
+<process>
+
+## Step 1: Load config
+
+Read `.rpi.yaml` from the project root. Extract:
+- `folder` (default: `rpi/features`)
+
+If `.rpi.yaml` doesn't exist, use defaults silently.
+
+## Step 2: Determine feature slug
+
+Check the command arguments for a feature name.
+
+- If provided: convert to kebab-case (lowercase, spaces/underscores become hyphens, strip special chars).
+- If not provided: ask the user with AskUserQuestion: "What's the name for this feature? (short, e.g. 'oauth', 'dark-mode', 'csv-export')"
+
+Parse `--quick` flag from arguments if present.
+
+## Step 3: Check for existing feature
+
+Check if `{folder}/{slug}/` already exists (where `folder` is from Step 1).
+
+If it exists, ask the user with AskUserQuestion:
+"Feature '{slug}' already exists at `{folder}/{slug}/`. Do you want to overwrite it or pick a different name?"
+
+- If overwrite: continue (existing files will be replaced).
+- If different name: ask for new name, go back to slug derivation.
+
+## Step 4: Luna's adaptive interview
+
+Adopt Luna's persona fully. Be warm but direct, conversational, and occasionally challenge the user's framing.
+
+### If `--quick` flag is set, skip to Step 4b.
+
+### Step 4a: Standard interview (max 3 batches)
+
+**Batch 1 — Core questions** (use AskUserQuestion):
+- Skip "What do you want to build?" if the slug is already descriptive (e.g. "csv-export" is clear, "phase2" is not).
+- Always ask: "What problem does this solve? Who benefits?"
+- Add one contextual question based on what you know so far.
+
+**Batch 2 — Adaptive follow-ups** (use AskUserQuestion):
+Based on the user's answers, pick 2-3 questions from these categories:
+- If frontend/UI mentioned: "What does the user see? Any specific interactions or flows?"
+- If database/data mentioned: "What data is involved? New tables/models, or changes to existing ones?"
+- If it sounds complex: "Can this be broken into smaller deliverables? What's the MVP?"
+- If external APIs/services mentioned: "Which services? Any rate limits, auth requirements, or costs to consider?"
+- If vague on scope: "What is explicitly NOT part of this feature?"
+
+**Batch 3 — Clarifications** (use AskUserQuestion, only if needed):
+- Only ask if there are gaps that would block downstream agents.
+- Max 2 questions. If answers are clear enough after Batch 2, skip this batch.
+
+After the interview, proceed to Step 5.
+
+### Step 4b: Quick interview (`--quick`)
+
+Ask at most 2 questions in a single AskUserQuestion call:
+1. "What do you want to build?" (skip if slug is descriptive)
+2. "Any constraints or gotchas I should know about?"
+
+Keep it fast. Proceed to Step 5.
+
+## Step 5: Complexity detection
+
+Based on the interview answers, estimate complexity:
+- **S** — Small: isolated change, single file or module, no new dependencies.
+- **M** — Medium: touches 2-5 files, may need new module, straightforward logic.
+- **L** — Large: cross-cutting, multiple modules, new patterns or integrations.
+- **XL** — Extra Large: architectural change, new infrastructure, high risk.
+
+If the estimate is **S** and `--quick` was NOT set:
+Suggest to the user: "This sounds like a small change. You could use `--quick` next time to skip research and plan. For now, I'll write the full REQUEST.md."
+
+## Step 6: Create directory structure
+
+Run these commands to create the feature directory:
+
+```bash
+mkdir -p {folder}/{slug}/research
+mkdir -p {folder}/{slug}/plan
+mkdir -p {folder}/{slug}/implement
+mkdir -p {folder}/{slug}/delta/ADDED
+mkdir -p {folder}/{slug}/delta/MODIFIED
+mkdir -p {folder}/{slug}/delta/REMOVED
+```
+
+Where `{folder}` is the value from Step 1 (default: `rpi/features`).
+
+## Step 7: Generate REQUEST.md
+
+Write `{folder}/{slug}/REQUEST.md` using Luna's output format:
+
+```markdown
+# {Feature Title}
+
+## Summary
+{1-3 sentences — what this feature does}
+
+## Problem
+{What problem does this solve? Who is affected?}
+
+## Target Users
+{Who will use this feature?}
+
+## Constraints
+- {constraint 1}
+- {constraint 2}
+
+## References
+- {links, examples, inspiration — or "None identified" if the user didn't mention any}
+
+## Unknowns
+- {anything unclear that needs clarification — always have at least one, even if it's minor}
+
+## Complexity Estimate
+{S | M | L | XL} — {justification}
+```
+
+If `--quick` was set: write a compact version (shorter sentences, skip References if none, Unknowns can be brief). Add a section at the end:
+
+```markdown
+## Quick Flow
+This feature was flagged for quick flow. Skipping research and plan phases.
+Suggested approach: {1-2 sentence implementation direction based on the interview}.
+```
+
+## Step 8: Next steps
+
+Output to the user:
+
+```
+Feature created: {folder}/{slug}/REQUEST.md
+
+Next: /rpi {slug}
+Or explicitly: /rpi:research {slug}
+```
+
+If `--quick` was set, instead output:
+
+```
+Feature created: {folder}/{slug}/REQUEST.md
+
+Quick flow: /rpi:implement {slug}
+Or full pipeline: /rpi {slug}
+```
+
+</process>
+"""

package/.gemini/commands/rpi/onboarding.toml

@@ -0,0 +1,236 @@
+description = "First-time setup — analyzes your codebase, generates context, and guides you through your first feature."
+
+prompt = """
+# /rpi:onboarding — Guided First-Time Setup
+
+Walks the user through RPIKit setup: explains the workflow, configures the project, analyzes the codebase, and guides them into their first feature.
+
+---
+
+## Step 1: Welcome message
+
+Output to the user:
+
+```
+Welcome to RPIKit v2 — Research, Plan, Implement.
+
+RPIKit is a 7-phase development workflow with 13 specialized AI agents.
+Each phase produces artifacts that feed the next, with validation gates
+that prevent premature implementation.
+
+I'll analyze your project, set up configuration, and guide you through
+your first feature.
+```
+
+## Step 2: Parse arguments and check existing setup
+
+1. Parse `$ARGUMENTS` for `--refresh` flag.
+2. Check if `rpi/context.md` exists.
+
+- If `rpi/context.md` exists and `--refresh` was NOT passed:
+  Ask with AskUserQuestion: "Project already configured. Do you want to refresh the analysis or skip to feature selection?"
+  - If refresh: proceed to Step 3 (full init flow).
+  - If skip: jump to Step 5 (read existing `rpi/context.md` and present summary).
+- If `--refresh` was passed: proceed to Step 3 (full init flow).
+- If `rpi/context.md` does not exist: proceed to Step 3 (full init flow).
+
+## Step 3: Run /rpi:init flow inline — configuration interview
+
+### Step 3a: Check existing config
+
+Check if `.rpi.yaml` exists.
+- If it exists and `--refresh` was NOT passed: ask with AskUserQuestion: ".rpi.yaml already exists. Overwrite with fresh config or keep current settings?"
+  - If keep: skip to Step 3c.
+  - If overwrite: proceed to Step 3b.
+- If it exists and `--refresh` was passed: proceed to Step 3b.
+- If it does not exist: proceed to Step 3b.
+
+### Step 3b: Interview (2 batches)
+
+**Batch 1** (use AskUserQuestion — ask all at once):
+- "Do you use TDD? (yes/no, default: no)"
+- "Commit style? (conventional/freeform, default: conventional)"
+- "When should the UX agent (Pixel) run? (auto/always/never, default: auto — runs when frontend detected)"
+
+**Batch 2** (use AskUserQuestion — ask all at once):
+- "Auto-learn from implementations? When Forge finishes a task, should RPIKit capture the solution in rpi/solutions/? (yes/no, default: no)"
+- "Party mode default panel size? (3/5/7, default: 5)"
+
+### Step 3c: Write .rpi.yaml
+
+Write `.rpi.yaml` to the project root with the user's responses (use defaults for unanswered questions):
+
+```yaml
+version: 2
+
+# Directories
+folder: rpi/features
+specs_dir: rpi/specs
+solutions_dir: rpi/solutions
+context_file: rpi/context.md
+
+# Execution
+parallel_threshold: 8
+commit_style: {user_response | conventional}
+tdd: {user_response | false}
+
+# Agents
+ux_agent: {user_response | auto}
+
+# Quick flow
+quick_complexity: S
+
+# Knowledge compounding
+auto_learn: {user_response | true}
+
+# Party mode
+party_default_agents: {user_response | 5}
+```
+
+### Step 3d: Create directory structure
+
+```bash
+mkdir -p rpi/specs
+mkdir -p rpi/solutions
+mkdir -p rpi/features
+```
+
+## Step 4: Launch Atlas — codebase analysis
+
+Launch Atlas agent to analyze the codebase and generate `rpi/context.md`:
+
+```
+You are Atlas. Analyze this entire codebase and produce a comprehensive project context document.
+
+Your task:
+1. Read config files first (package.json, tsconfig, Cargo.toml, pyproject.toml, go.mod, etc.)
+2. Explore the directory structure — map all key directories and their purposes
+3. Find 5-10 representative source files across different parts of the codebase
+4. Detect naming conventions, component patterns, import style, error handling
+5. Identify the testing setup and coverage patterns
+6. Note any TODOs, FIXMEs, or incomplete areas in the code
+7. Identify untested modules or areas with weak coverage
+8. Spot architectural risks or technical debt
+
+Output format — write this directly to rpi/context.md:
+
+# Project Context
+
+## Stack
+- Language: {language} {version}
+- Framework: {framework} {version}
+- Database: {db} (if any)
+- Testing: {test_framework}
+- Build: {build_tool}
+- Package Manager: {package_manager}
+
+## Architecture
+- Pattern: {description}
+- Key directories: {list with purposes}
+- Entry points: {list}
+
+## Conventions
+- File naming: {pattern}
+- Component pattern: {pattern}
+- Import style: {pattern}
+- Error handling: {pattern}
+- API pattern: {pattern}
+
+## Key Files
+{List of important files with brief descriptions}
+
+## Existing Tests
+{Summary of test coverage and testing patterns}
+
+## Risks and Technical Debt
+{Identified risks, TODOs, FIXMEs, weak areas}
+
+## Opportunities
+{3-5 concrete feature ideas based on: TODOs found, untested modules, missing error handling, potential improvements}
+```
+
+Wait for Atlas to complete. Store the output as `$ATLAS_OUTPUT`.
+
+## Step 5: Present codebase analysis summary
+
+1. Read `rpi/context.md` (freshly generated or existing).
+2. Output a condensed summary to the user:
+
+```
+Project Analysis Complete
+
+Stack: {language} + {framework}
+Architecture: {pattern}
+Files: {approximate count}
+Tests: {coverage summary}
+
+Key findings:
+- {finding 1}
+- {finding 2}
+- {finding 3}
+```
+
+## Step 6: Suggest features
+
+Based on the `## Opportunities` section in `rpi/context.md` (or from `$ATLAS_OUTPUT`), present 3-5 concrete feature suggestions:
+
+```
+Based on the analysis, here are some things you could work on:
+
+1. {feature idea} — {brief justification from codebase analysis}
+2. {feature idea} — {brief justification}
+3. {feature idea} — {brief justification}
+```
+
+Each suggestion should be grounded in something Atlas actually found (a TODO, an untested module, a missing pattern, a risk to address).
+
+## Step 7: Ask what the user wants to do
+
+Use AskUserQuestion:
+
+"What would you like to do?
+A) Build one of these features (pick a number)
+B) Describe my own feature
+C) I'll explore on my own"
+
+### If A (build a suggested feature):
+
+1. Convert the selected feature idea into a slug.
+2. Read `commands/rpi/new.md` and follow its process from Step 4 onward (Luna's interview), using the suggested feature as context.
+3. After REQUEST.md is created, output:
+   ```
+   Feature created: rpi/features/{slug}/REQUEST.md
+
+   Next: /rpi {slug}
+   ```
+
+### If B (describe own feature):
+
+1. Ask with AskUserQuestion: "What's the name for this feature? (short, e.g. 'oauth', 'dark-mode', 'csv-export')"
+2. Read `commands/rpi/new.md` and follow its process from Step 4 onward (Luna's interview).
+3. After REQUEST.md is created, output:
+   ```
+   Feature created: rpi/features/{slug}/REQUEST.md
+
+   Next: /rpi {slug}
+   ```
+
+### If C (explore on their own):
+
+Proceed to Step 8.
+
+## Step 8: Quick reference card
+
+Output to the user:
+
+```
+Quick Reference:
+  /rpi:new my-feature    Start a new feature
+  /rpi my-feature        Auto-progress to next phase
+  /rpi:party "topic"     Multi-agent debate
+  /rpi:learn             Capture a solution
+  /rpi:status            See all features
+
+Setup complete. Happy building!
+```
+"""