Initial config for LLM coding agents

.claude/commands/code-review.md

@@ -0,0 +1,83 @@
+# Code Review Command
+
+Please perform a code review given the following context about which branch to
+compare to which other branch. There may be other context relevant to the
+review.
+
+**IMPORTANT** Respond with a concise review that is useful to copy/past into a GitHub Pull Request comment.
+
+<branch_review_context>$ARGUMENTS</branch_review_context>
+
+**IMPORTANT** Follow the coding standards and best practices outlined in the
+`.CLAUDE.md` file for this review.
+
+## Steps
+
+1. **List all changed files**
+
+Unless other specified in <branch_review_context>, get file changes by comparing
+two branches. The <branch_review_context> may specifiy to get changes on the
+current branch since a specific commit, in which case, modify the following
+commands to do that. You know how. Regardless, you will end up with the
+following two diff files to use.
+
+- Run
+  `git diff --name-only BASE_BRANCH...WORKING_BRANCH > tmp_diff_name_only.txt`
+  to get the exact list of files that changed.
+
+2. **Get the complete diff**
+
+- Run `git diff BASE_BRANCH...WORKING_BRANCH > tmp_full_diff.txt` to see all
+  actual changes.
+
+3. **Analyze each file thoroughly**
+
+- For every file in the diff:
+  - Read the full file content if it's a new/modified file to understand context
+  - Examine the specific changes line by line from the diff
+  - Check against project coding standards from CLAUDE.md
+    - All coding standards are important, but pay special attention to the
+      Frontend Rules and React coding styles and best practices.
+  - Identify potential issues:
+    - Security vulnerabilities or exposed sensitive data
+    - Performance bottlenecks or inefficiencies
+    - Logic bugs or edge cases not handled
+    - Code maintainability and readability concerns
+    - Missing error handling or validation
+    - Breaking changes that affect other parts of the codebase
+  - For each issue found, note the specific file path and line number references
+- Assess the broader impact: how changes in each file affect related components,
+  APIs, database schemas, or user workflows
+
+4. **Create comprehensive review**
+
+- Write a complete and accurate code review document that covers:
+  - **Executive Summary**: Brief overview of changes, risk level, and key
+    concerns
+  - **Files Changed**: List all modified files with change summary
+  - **Critical Issues**: Security, breaking changes, or major bugs requiring
+    immediate attention
+  - **Detailed Analysis**: For each file with issues:
+    - `### path/to/file.ext`
+    - **Changes**: What was modified
+    - **Issues Found**: Specific problems with file:line references
+    - **Recommendations**: Actionable fixes with code examples where helpful
+    - **Impact**: How changes affect other parts of the system
+  - **Overall Assessment**: System-wide impact, testing recommendations,
+    deployment considerations
+  - **Action Items**: Prioritized checklist of required fixes and improvements
+
+5. **Save your review**
+
+- Save your full review to a new markdown file in the `.plans/` directory using
+  the format: `code-review-[BRANCH_NAME]-[TIMESTAMP_WITH_TIME].md`
+- Include a brief summary at the top with the review date, branches compared,
+  and total files analyzed
+
+6. **Delete the temporary files**
+
+- Delete the temporary files created in steps 1 and 2:
+  - `tmp_diff_name_only.txt`
+  - `tmp_full_diff.txt`
+
+Be constructive and helpful in your feedback.

.claude/commands/plan-review.md

@@ -0,0 +1,118 @@
+# Plan Review Command
+
+Review an implementation plan for completeness, clarity, and feasibility by thoroughly analyzing both the plan document and the existing codebase it will integrate with.
+
+<plan_context>$ARGUMENTS</plan_context>
+
+## Overview
+
+This command reviews implementation plans by validating specifications AND reading the actual codebase to ensure the plan will integrate properly with existing code.
+
+## Steps
+
+1. **Load the plan document**
+   - Read the specified plan file mentioned in the <plan_context>.
+
+2. **Load and Validate the High Level Goals (Source of Truth)**
+   - Read the `## High level goals` section of the plan document carefully.
+   - **CRITICAL**: This section is the authoritative source of truth for what
+     must be accomplished.
+   - This section typically contains:
+     - Routes/pages/components affected
+     - Current State descriptions (what exists today)
+     - Required Changes (what needs to be built)
+     - Specific features and behaviors to implement
+
+   **ESCAPE HATCH - Stop review if High Level Goals are inadequate:**
+   - If any of these issues are found, **STOP THE REVIEW** and report the
+     problem:
+     - Goals section is missing or empty
+     - Goals are vague or ambiguous (e.g., "improve performance" without
+       metrics)
+     - Internal contradictions within the goals themselves
+     - Current State and Required Changes are not clearly distinguished
+     - Goals mix implementation details with requirements
+     - Goals reference undefined components or systems
+   - When stopping early, provide:
+     - Specific examples of the problems found
+     - Clear guidance on how to improve the goals
+     - Offer to help rewrite the High Level Goals section
+
+   - If goals pass validation:
+     - All implementation details in the rest of the plan must align with these
+       goals.
+     - If there's any conflict between the goals and other sections, the goals
+       take precedence.
+
+3. **Analyze plan structure and clarity**
+   - Verify all sections directly support the High Level Goals
+   - Ensure no implementation details contradict the stated goals
+   - Check for logical flow and organization
+   - Assess code-to-prose ratio (should be ~20% code examples, 80%
+     specifications)
+   - Evaluate whether architecture decisions are justified by the goals
+
+4. **Verify integration with existing code**
+
+   **CRITICAL: Find and read all code files the plan references or will modify**
+
+   - Extract all code references from the plan (functions, components, schemas, etc.)
+   - Use Grep/Glob to locate each referenced file
+   - Read the actual implementation to understand current structure
+   - Verify that assumed functions/components exist with compatible signatures
+   - Check that the plan follows existing patterns and conventions
+   - Identify any missing dependencies or utilities the plan requires
+   - Note any conflicts between plan assumptions and actual code
+
+5. **Evaluate completeness**
+   - Required sections present: goals, architecture, implementation steps,
+     testing
+   - State management strategy defined
+   - Error handling and edge cases addressed
+   - Performance considerations included
+   - Security implications considered
+   - Rollout/deployment strategy specified
+
+6. **Identify gaps and risks**
+   - Missing specifications or ambiguous requirements
+   - Technical blockers (missing dependencies, incompatible APIs)
+   - Undefined data flows or state transitions
+   - Absent testing or validation strategies
+   - Unaddressed scaling or performance limits
+
+7. **Generate comprehensive review** Create a review document with:
+   - **Rating**: Score out of 100
+   - **Executive Summary**: 2-3 sentence overview
+   - **High Level Goals Alignment**: Confirm all goals from section 2 are
+     addressed
+   - **Code Integration Verification**: Summary of what was found vs. what the plan assumes
+   - **Strengths**: What the plan does well
+   - **Critical Gaps**: Blockers that prevent implementation
+   - **Missing Details**: Important but non-blocking omissions
+   - **Integration Issues**: Conflicts with existing code (be specific with file:line references)
+   - **Risk Assessment**: Potential failure points
+   - **Recommendations**: Specific improvements needed
+   - **Implementation Readiness**: Clear yes/no with justification
+
+8. **Score breakdown** Rate each aspect 0-100:
+   - High Level Goals alignment
+   - Architecture clarity
+   - Code integration (files exist, patterns match)
+   - Technical accuracy
+   - Risk mitigation
+   - Testing strategy
+   - Implementation readiness
+
+9. **Respond to the user**
+   - Present the review directly in the conversation
+   - Format for readability with clear sections and scores
+   - Highlight critical blockers that must be addressed
+   - Offer to:
+     - Save an improved version of the plan if score < 85
+     - Discuss specific sections that need work
+     - Help refactor problematic areas
+     - Create implementation checklist if score ≥ 85
+   - End with clear next steps or questions for the user
+
+Be constructive but thorough - a plan that scores below 85/100 needs significant
+revision before implementation.

.claude/commands/plan.md

@@ -0,0 +1,93 @@
+You are an AI assistant acting as a senior-level software engineer. Your task is
+to generate a comprehensive GitHub issue description for a given software
+engineering task. This description should include a deep analysis of the
+problem, its cause, and a detailed implementation guide. This is a planning
+document and will be provided to a junior developer to implement.
+
+Here's the software engineering task you need to address:
+
+<task_description> $ARGUMENTS </task_description>
+
+Follow these steps to create the GitHub issue description:
+
+1. Research the problem:
+
+   - Analyze the task description thoroughly
+   - Identify the key components and technologies involved
+   - Look for any potential challenges or complexities
+   - Consider any relevant best practices or design patterns
+
+2. Identify the cause of the problem:
+
+   - Determine why this task is necessary
+   - Explore any existing limitations or issues that led to this task
+   - Consider any potential root causes or underlying system deficiencies
+
+3. Create a step-by-step implementation guide:
+
+   - Break down the task into logical, manageable steps
+   - Provide clear and concise instructions for each step
+   - Consider potential edge cases and how to handle them
+   - Include code snippets only if necessary. This is a planning document and
+     will be provided to a developer to implement.
+
+4. Format the GitHub issue description using best practices:
+
+   - Use a clear and concise title that summarizes the task
+   - Start with a brief overview of the problem
+   - Use markdown formatting for better readability (e.g., headers, lists, code
+     blocks)
+   - Include labels to categorize the issue (e.g., "enhancement", "bug",
+     "documentation")
+   - Add any relevant links or references
+
+5. Structure your GitHub issue description as follows:
+   - Title
+   - Problem Overview
+   - High Level Goals (this section is CRITICAL - see details below)
+   - Detailed Problem Analysis
+   - Root Cause
+   - Implementation Guide
+   - Additional Considerations
+   - Labels
+
+6. **High Level Goals Section Requirements**:
+
+   This section must be placed near the top of the plan (after Problem Overview)
+   and serves as the authoritative source of truth for what must be accomplished.
+
+   Include the following subsections:
+
+   - **Routes/Pages/Components Affected**: List all specific files, routes, or
+     components that will be modified or created
+   - **Current State**: Clear description of what exists today in the codebase
+     for each affected area
+   - **Required Changes**: Specific features and behaviors that need to be
+     implemented, focusing on WHAT needs to be built, not HOW
+   - **Success Criteria**: Measurable outcomes that define when the task is
+     complete
+
+   Guidelines for this section:
+   - Be specific and unambiguous - avoid vague goals like "improve performance"
+     without metrics
+   - Clearly distinguish between Current State and Required Changes
+   - Focus on requirements, not implementation details
+   - Ensure all goals are internally consistent with no contradictions
+   - Reference only components/systems that are defined elsewhere in the plan
+   - Make this section comprehensive enough that a developer could validate
+     their work against it
+
+Think through each of these steps carefully before composing your final GitHub
+issue description. Use a <scratchpad> section to organize your thoughts if
+needed.
+
+Your final output should be the complete GitHub issue description, formatted
+appropriately for GitHub. Include only the content that would appear in the
+actual GitHub issue, without any additional commentary or explanations outside
+of the issue description itself.
+
+Begin your response with the GitHub issue title in a single line, followed by
+the full issue description. Use appropriate markdown formatting throughout.
+
+Output the description to the <root>/.plans/ directory with a slug
+representation of the title.

.gitignore

@@ -42,9 +42,12 @@ yarn-error.log*
 next-env.d.ts
 
 # Claude Code
-.claude
+.claude/settings.local.json
 .plans
 .mcp.json
 
 # DB Backups
-db-backups
+db-backups
+
+# Files
+files

.mcp.json.example

@@ -0,0 +1,8 @@
+{
+  "mcpServers": {
+    "RepoPrompt": {
+      "command": "/Users/username/RepoPrompt/repoprompt_cli",
+      "args": []
+    }
+  }
+}