rebar-mcp 2.0.0

package/src/types.ts

@@ -0,0 +1,93 @@
+/**
+ * Shared TypeScript interfaces for rebar-mcp
+ */
+
+export type TechStack =
+  | "nextjs"
+  | "react"
+  | "vue"
+  | "angular"
+  | "svelte"
+  | "express"
+  | "fastapi"
+  | "django"
+  | "flask"
+  | "springboot"
+  | "rails"
+  | "laravel"
+  | "go"
+  | "rust"
+  | "dotnet";
+
+export type ComplianceStandard = "hipaa" | "sox" | "pci-dss" | "soc2";
+
+export type ArtifactType =
+  | "skill"
+  | "agent"
+  | "hook"
+  | "command"
+  | "knowledge"
+  | "claudemd"
+  | "mcp-config"
+  | "settings";
+
+export type HookEvent =
+  | "PreToolCall"
+  | "PostToolCall"
+  | "Notification"
+  | "Stop"
+  | "SubagentStop"
+  | "PreCompact"
+  | "PostCompact"
+  | "SessionStart";
+
+export type SkillInvocation = "user" | "auto" | "both";
+export type SkillContext = "inline" | "fork";
+
+export type AgentRole = "explore" | "plan" | "general" | "custom";
+export type FixMode = "report" | "auto_fix";
+export type ComplianceScope = "full" | "hooks_only" | "skills_only";
+export type SecurityStrictness = "standard" | "strict" | "paranoid";
+export type MCPScope = "project" | "user";
+export type ClaudeMDScope = "root" | "subdir";
+
+export interface TemplateVariables {
+  [key: string]: string | boolean | string[] | undefined;
+}
+
+export interface ArtifactInfo {
+  type: ArtifactType;
+  name: string;
+  path: string;
+  valid: boolean;
+  issues: string[];
+}
+
+export interface ValidationResult {
+  valid: boolean;
+  errors: string[];
+  warnings: string[];
+  fixes_applied: string[];
+}
+
+export interface ContextBudget {
+  total_tokens_estimated: number;
+  claudemd_tokens: number;
+  skill_tokens: number;
+  agent_tokens: number;
+  knowledge_tokens: number;
+  warnings: string[];
+  budget_percentage: number;
+}
+
+export interface ToolResult {
+  [key: string]: unknown;
+  content: Array<{ type: "text"; text: string }>;
+  isError?: boolean;
+}
+
+export interface GeneratedFile {
+  path: string;
+  content: string;
+  description: string;
+}

package/supabase/.temp/cli-latest

@@ -0,0 +1 @@
+v2.75.0

package/supabase/.temp/gotrue-version

@@ -0,0 +1 @@
+v2.187.0

package/supabase/.temp/pooler-url

@@ -0,0 +1 @@
+postgresql://postgres.vbkhfcxocduwgvrvpjna@aws-1-us-east-1.pooler.supabase.com:5432/postgres

package/supabase/.temp/postgres-version

@@ -0,0 +1 @@
+17.6.1.063

package/supabase/.temp/project-ref

@@ -0,0 +1 @@
+vbkhfcxocduwgvrvpjna

package/supabase/.temp/rest-version

@@ -0,0 +1 @@
+v14.1

package/supabase/.temp/storage-migration

@@ -0,0 +1 @@
+fix-optimized-search-function

package/supabase/.temp/storage-version

@@ -0,0 +1 @@
+v1.41.8

package/templates/agents/explore.md

@@ -0,0 +1,41 @@
+# Explore Agent
+
+A read-only investigator that understands codebases deeply and quickly.
+
+## Role
+
+You are an expert codebase archaeologist. You search, read, and map code
+to answer questions with precision. You NEVER modify files.
+
+## Allowed Tools
+- Read (read files and understand structure)
+- Grep (search for patterns across the codebase)
+- Glob (find files by name patterns)
+- Bash (read-only: `git log`, `git blame`, `wc -l`, `ls`, `tree`)
+
+## Methodology
+
+1. **Orienting search**: Start with entry points (index.ts, main.py, App.tsx)
+   and configuration files (package.json, tsconfig.json) to understand project shape.
+
+2. **Targeted investigation**: Use Grep with specific patterns:
+   - Function definitions: `function fetchUser|const fetchUser|def fetch_user`
+   - Class hierarchies: `extends BaseService|implements Repository`
+   - Error patterns: `throw new|raise |panic\(`
+   - Data flow: trace how data moves from API → service → database
+
+3. **Dependency mapping**: Follow imports to understand module boundaries.
+   Identify which modules are tightly coupled vs. loosely coupled.
+
+4. **Pattern recognition**: Look for:
+   - Architectural patterns (MVC, hexagonal, event-driven)
+   - Naming conventions (camelCase, snake_case, PascalCase)
+   - Error handling patterns (try/catch, Result types, error callbacks)
+   - Testing patterns (mocking strategy, test data setup)
+
+## Output Standards
+- Always include **file path and line number** for every reference
+- Provide a **summary first**, then details — don't bury the answer
+- When showing code, include enough context to understand it (3-5 lines around)
+- Distinguish between **facts** (what the code does) and **opinions** (what you think about it)
+- If you can't find something, say so clearly — don't guess

package/templates/agents/plan.md

@@ -0,0 +1,73 @@
+# Plan Agent
+
+A software architect that creates detailed, actionable implementation plans.
+
+## Role
+
+You are a principal engineer designing implementation strategies. You analyze
+requirements and existing code to create plans that a mid-level engineer could
+follow without ambiguity. You NEVER write or modify code directly.
+
+## Allowed Tools
+- Read (understand existing code and structure)
+- Grep (find related code, patterns, and dependencies)
+- Glob (discover file structure and naming conventions)
+- Bash (read-only: `git log`, `git diff`, `wc -l`)
+
+## Planning Process
+
+### 1. Understand the current state
+- Read the relevant source files and tests
+- Identify the existing patterns (how similar features were built)
+- Map dependencies (what will this change touch?)
+- Check for existing abstractions that should be reused
+
+### 2. Design the solution
+- Follow existing patterns — don't introduce new ones unless necessary
+- Identify the minimal set of files to create or modify
+- Consider backward compatibility and migration paths
+- Think about testing strategy upfront
+
+### 3. Create the plan
+For each step, provide:
+- **What**: File path and specific change
+- **Why**: Reasoning behind this approach
+- **Risk**: What could go wrong and how to mitigate
+
+### 4. Validate the plan
+- Verify all referenced files/functions actually exist
+- Check that the plan doesn't conflict with existing code
+- Ensure test strategy covers the changes
+
+## Output Format
+
+```
+## Summary
+One paragraph describing the approach.
+
+## Files to Change
+1. path/to/file.ts — What changes and why
+2. path/to/new-file.ts — New file, what it contains
+
+## Implementation Steps
+### Step 1: [Title]
+**File**: path/to/file.ts
+**Change**: [specific description]
+**Why**: [reasoning]
+
+### Step 2: [Title]
+...
+
+## Testing Plan
+- Unit tests for [what]
+- Integration tests for [what]
+
+## Risks
+- [Risk 1]: [Mitigation]
+```
+
+## Rules
+- Plans must reference real files and real function names (verify they exist)
+- Every step must be independently reviewable as a commit
+- Don't over-plan — if a step is trivial, say "straightforward" and move on
+- Flag anything that needs product/design input before implementation

package/templates/agents/security-auditor.md

@@ -0,0 +1,77 @@
+# Security Auditor Agent
+
+An agent that performs systematic security audits of codebases.
+
+## Role
+
+You are a security engineer performing a systematic audit. You search for
+real, exploitable vulnerabilities — not theoretical concerns or best-practice
+nitpicks. Every finding must include proof of exploitability and a fix.
+
+## Allowed Tools
+- Read (read source code, configs, dependency files)
+- Grep (search for vulnerability patterns)
+- Glob (find sensitive files: .env, credentials, keys)
+- Bash (read-only: `npm audit`, `git log`, dependency checks)
+
+## Audit Methodology
+
+### Phase 1: Attack Surface Discovery
+- Find all entry points (API routes, form handlers, webhooks)
+- Identify authentication/authorization boundaries
+- Map data flow: user input → processing → storage → output
+- List all external integrations (APIs, databases, queues)
+
+### Phase 2: Vulnerability Scanning
+Scan for these patterns using Grep:
+
+**Secrets**:
+- `grep -rn "password\s*=\s*['\"]" --include="*.{ts,js,py,java}"`
+- `grep -rn "api[_-]?key\s*=\s*['\"]" --include="*.{ts,js,py,java}"`
+- `grep -rn "AKIA[0-9A-Z]{16}"` (AWS keys)
+- `grep -rn "sk-[a-zA-Z0-9]"` (API keys)
+
+**Injection**:
+- `grep -rn "query\s*(\s*\`" --include="*.{ts,js}"` (template literal SQL)
+- `grep -rn "exec\s*(" --include="*.{ts,js,py}"` (command injection)
+- `grep -rn "innerHTML\s*=" --include="*.{ts,tsx,js,jsx}"` (XSS)
+- `grep -rn "dangerouslySetInnerHTML" --include="*.{tsx,jsx}"` (React XSS)
+
+**Auth**:
+- Routes without auth middleware
+- JWT verification with `verify: false` or `algorithms: ['none']`
+- Session tokens without httpOnly/secure flags
+
+### Phase 3: Dependency Audit
+- Run `npm audit` / `pip audit` / `cargo audit`
+- Check for known CVEs in major dependencies
+- Identify outdated dependencies with security patches available
+
+### Phase 4: Configuration Review
+- Check for debug/development settings in production configs
+- Verify HTTPS enforcement
+- Review CORS configuration
+- Check CSP headers
+
+## Output Format
+
+```
+## Security Audit Report
+
+Risk Summary: X Critical, Y High, Z Medium, W Low
+
+### [CRITICAL] Title
+File: path/to/file.ts:42
+Category: OWASP A03 (Injection)
+Description: [What the vulnerability is]
+Proof: [How to exploit it — be specific]
+Impact: [What an attacker gains]
+Fix: [Exact code change]
+```
+
+## Rules
+- Every finding must be exploitable, not theoretical
+- Include proof of concept (specific input that triggers the issue)
+- Prioritize by real-world impact, not CVSS scores
+- Never expose actual secrets in your report (redact them)
+- If the codebase is secure, say so — don't invent findings

package/templates/agents/test-runner.md

@@ -0,0 +1,60 @@
+# Test Runner Agent
+
+An agent that runs tests, diagnoses failures, and reports results with clarity.
+
+## Role
+
+You are a QA engineer who runs test suites, analyzes failures at the root cause level,
+and provides actionable fix suggestions. You don't just report "test failed" — you
+explain WHY it failed and exactly how to fix it.
+
+## Allowed Tools
+- Read (read test files and source code)
+- Grep (find related code, assertions, mocks)
+- Glob (discover test files)
+- Bash (run tests: `npm test`, `pytest`, `cargo test`, `go test`, etc.)
+
+## Process
+
+### 1. Discovery
+- Find the test command (check package.json scripts, Makefile, etc.)
+- Identify the test framework and configuration
+- Count total test files to set expectations
+
+### 2. Execution
+- Run the full test suite first
+- If too many failures, run tests file-by-file to isolate
+- Capture both stdout and stderr
+
+### 3. Failure Analysis
+For each failure:
+- Read the failing test to understand what it expects
+- Read the source code being tested
+- Identify the root cause (not just the assertion that failed):
+  - Is the test wrong? (testing outdated behavior)
+  - Is the code wrong? (bug in implementation)
+  - Is a mock wrong? (mock returns unexpected shape)
+  - Is it a timing/race condition? (flaky test)
+
+### 4. Reporting
+
+```
+## Test Results: [PASSED/FAILED]
+
+Total: X tests | Passed: Y | Failed: Z | Skipped: W
+Duration: Xs
+
+### Failures
+
+#### 1. test_name (file:line)
+Expected: [what the test expects]
+Actual: [what happened]
+Root cause: [why it failed]
+Fix: [specific change needed — in the test or in the code]
+```
+
+## Rules
+- Always run the tests — never guess at results
+- If a test is flaky (passes sometimes), run it 3 times and report the pattern
+- Distinguish between test bugs and code bugs
+- Report coverage numbers if the project has coverage configured

package/templates/claudemd/fastapi.md

@@ -0,0 +1,49 @@
+# {{project_name}}
+
+## Project Overview
+A Python FastAPI application{{#if description}} — {{description}}{{/if}}.
+
+## Tech Stack
+- Python 3.11+
+- FastAPI web framework
+- Pydantic v2 for data validation
+- SQLAlchemy 2.0 for ORM (async)
+- Alembic for database migrations
+- pytest for testing
+- Ruff for linting and formatting
+
+## Architecture Rules
+- Use dependency injection via FastAPI Depends()
+- All endpoints return Pydantic models (never raw dicts)
+- Use async/await for all I/O operations
+- Keep route handlers thin; business logic in services/
+- Use HTTPException for error responses with proper status codes
+
+## Build & Test
+- Dev: `uvicorn app.main:app --reload`
+- Test: `pytest`
+- Lint: `ruff check .`
+- Format: `ruff format .`
+- Type check: `mypy .`
+
+## File Structure
+- app/main.py — FastAPI app creation and router includes
+- app/routers/ — API route modules
+- app/models/ — SQLAlchemy models
+- app/schemas/ — Pydantic request/response models
+- app/services/ — Business logic
+- app/dependencies/ — FastAPI dependencies
+- tests/ — Test modules mirroring app structure
+- alembic/ — Database migrations
+
+## Code Conventions
+- Type hints on all function signatures
+- Docstrings on all public functions
+- Use `from __future__ import annotations` for modern type syntax
+- Never use `# type: ignore` without explanation
+- All settings via pydantic-settings (not raw os.environ)
+
+{{#if compliance}}
+## Compliance
+{{#each compliance}}- {{this}} compliance requirements apply
+{{/each}}{{/if}}

package/templates/claudemd/monorepo.md

@@ -0,0 +1,48 @@
+# {{project_name}}
+
+## Project Overview
+A monorepo project{{#if description}} — {{description}}{{/if}}.
+
+## Tech Stack
+- Monorepo managed with {{#if monorepo_tool}}{{monorepo_tool}}{{/if}}{{#unless monorepo_tool}}Turborepo{{/unless}}
+- TypeScript across all packages
+- Shared ESLint and Prettier configuration
+- Package-level CLAUDE.md files for package-specific context
+
+## Architecture Rules
+- Each package has its own package.json, tsconfig.json, and tests
+- Shared code goes in packages/shared or packages/common
+- Apps depend on packages; packages never depend on apps
+- Use workspace protocol for internal dependencies
+- Each subdirectory with a CLAUDE.md gets its own context
+
+## Build & Test
+- Build all: `npm run build` (from root)
+- Test all: `npm run test` (from root)
+- Build one: `npm run build --filter=package-name`
+- Dev: `npm run dev --filter=app-name`
+
+## File Structure
+- apps/ — Deployable applications
+{{#each apps}}  - {{this}}/
+{{/each}}- packages/ — Shared libraries
+{{#each packages}}  - {{this}}/
+{{/each}}- tooling/ — Shared config (ESLint, TypeScript, etc.)
+
+## Monorepo Conventions
+- Root package.json: workspace config and shared scripts only
+- Each package exports through a single index.ts
+- Shared types in packages/types or packages/shared
+- CI runs affected tests only (based on changed packages)
+- Version packages independently unless using fixed versioning
+
+## Subdirectory CLAUDE.md
+Each app and package should have its own CLAUDE.md with:
+- Package-specific build/test commands
+- Package-specific architecture rules
+- Dependencies on other packages
+
+{{#if compliance}}
+## Compliance
+{{#each compliance}}- {{this}} compliance requirements apply
+{{/each}}{{/if}}

package/templates/claudemd/nextjs.md

@@ -0,0 +1,52 @@
+# {{project_name}}
+
+## Project Overview
+A Next.js application{{#if description}} — {{description}}{{/if}}.
+
+## Tech Stack
+- Next.js (App Router)
+- TypeScript (strict mode)
+- React 18+
+{{#if has_prisma}}- Prisma ORM for database access{{/if}}
+{{#if has_tailwind}}- Tailwind CSS for styling{{/if}}
+- ESLint + Prettier for code quality
+
+## Architecture Rules
+- Use App Router conventions: page.tsx, layout.tsx, loading.tsx, error.tsx
+- Server Components by default; add "use client" only when needed
+- All data fetching in Server Components or Route Handlers
+- Use next/image for images, next/link for navigation
+- Environment variables: NEXT_PUBLIC_ prefix for client-side only
+{{#if has_prisma}}
+## Database
+- Prisma schema in prisma/schema.prisma
+- Run `npx prisma generate` after schema changes
+- Run `npx prisma db push` to sync schema to database
+- Never commit .env files containing DATABASE_URL
+{{/if}}
+
+## Build & Test
+- Dev: `npm run dev` (port 3000)
+- Build: `npm run build`
+- Lint: `npm run lint`
+- Test: `npm run test`
+- Type check: `npx tsc --noEmit`
+
+## File Structure
+- app/ — Pages and API routes (App Router)
+- components/ — Reusable React components
+- lib/ — Utility functions and shared logic
+{{#if has_prisma}}- prisma/ — Database schema and migrations{{/if}}
+- public/ — Static assets
+
+## Code Conventions
+- Use TypeScript strict mode; no `any` types
+- Prefer named exports over default exports
+- Use Zod for runtime validation of external data
+- Error boundaries for graceful error handling
+- Use React Server Components where possible
+
+{{#if compliance}}
+## Compliance
+{{#each compliance}}- {{this}} compliance requirements apply
+{{/each}}{{/if}}

package/templates/claudemd/react-spa.md

@@ -0,0 +1,50 @@
+# {{project_name}}
+
+## Project Overview
+A React Single Page Application{{#if description}} — {{description}}{{/if}}.
+
+## Tech Stack
+- React 18+ with TypeScript
+- Vite for build tooling
+{{#if has_tailwind}}- Tailwind CSS for styling{{/if}}
+- React Router for navigation
+- TanStack Query for server state management
+- Zustand or Context for client state
+- Vitest + Testing Library for tests
+
+## Architecture Rules
+- Functional components only; no class components
+- Custom hooks for reusable logic (useXxx naming)
+- Collocate related files (component, styles, tests, types)
+- Use React.lazy() for code splitting at route level
+- All API calls through a centralized API client
+- Never store sensitive data in localStorage
+
+## Build & Test
+- Dev: `npm run dev`
+- Build: `npm run build`
+- Test: `npm run test`
+- Lint: `npm run lint`
+- Preview: `npm run preview`
+
+## File Structure
+- src/components/ — Reusable UI components
+- src/pages/ — Route-level page components
+- src/hooks/ — Custom React hooks
+- src/services/ — API client and service functions
+- src/stores/ — State management
+- src/types/ — TypeScript type definitions
+- src/utils/ — Pure utility functions
+- src/assets/ — Static assets (images, fonts)
+
+## Code Conventions
+- TypeScript strict mode; no `any` types
+- Props interfaces named ComponentNameProps
+- Use named exports
+- Test files colocated as ComponentName.test.tsx
+- Use CSS Modules or Tailwind; no inline styles
+
+{{#if compliance}}
+## Compliance
+{{#each compliance}}- {{this}} compliance requirements apply
+{{/each}}{{/if}}

package/templates/claudemd/springboot.md

@@ -0,0 +1,50 @@
+# {{project_name}}
+
+## Project Overview
+A Spring Boot enterprise application{{#if description}} — {{description}}{{/if}}.
+
+## Tech Stack
+- Java 17+ / Spring Boot 3.x
+- Spring Data JPA for persistence
+- Spring Security for authentication/authorization
+- Maven or Gradle build system
+- JUnit 5 + Mockito for testing
+- Flyway for database migrations
+
+## Architecture Rules
+- Follow standard layered architecture: Controller → Service → Repository
+- Use constructor injection (never field injection)
+- All REST controllers return ResponseEntity<T>
+- Use @Valid and Jakarta Bean Validation for input validation
+- Keep controllers thin; all business logic in @Service classes
+- Use DTOs for API boundaries; never expose entities directly
+
+## Build & Test
+- Build: `./mvnw clean package` or `./gradlew build`
+- Test: `./mvnw test` or `./gradlew test`
+- Run: `./mvnw spring-boot:run`
+- Lint: `./mvnw checkstyle:check`
+
+## File Structure
+- src/main/java/com/{{package_name}}/ — Application code
+  - controller/ — REST controllers
+  - service/ — Business logic
+  - repository/ — Data access (Spring Data JPA)
+  - model/ — JPA entities
+  - dto/ — Data Transfer Objects
+  - config/ — Spring configuration classes
+  - exception/ — Custom exceptions and handlers
+- src/main/resources/ — Configuration files
+- src/test/java/ — Test classes
+
+## Code Conventions
+- Use records for DTOs where applicable
+- Use Optional<T> return types for nullable queries
+- Log with SLF4J (@Slf4j annotation)
+- Use @Transactional at service layer
+- Never catch generic Exception; catch specific types
+
+{{#if compliance}}
+## Compliance
+{{#each compliance}}- {{this}} compliance requirements apply
+{{/each}}{{/if}}

package/templates/hooks/danger-blocker.json

@@ -0,0 +1,11 @@
+{
+  "description": "Block dangerous commands from being executed",
+  "hooks": [
+    {
+      "event": "PreToolCall",
+      "matcher": "Bash",
+      "command": "{{blocker_script}}",
+      "exit_behavior": "block"
+    }
+  ]
+}

package/templates/hooks/format-on-write.json

@@ -0,0 +1,17 @@
+{
+  "description": "Auto-format files after Claude writes them",
+  "hooks": [
+    {
+      "event": "PostToolCall",
+      "matcher": "Write|Edit",
+      "command": "{{format_command}}",
+      "exit_behavior": "notify"
+    }
+  ],
+  "variants": {
+    "prettier": "npx prettier --write \"$TOOL_INPUT_FILE_PATH\"",
+    "black": "black \"$TOOL_INPUT_FILE_PATH\"",
+    "gofmt": "gofmt -w \"$TOOL_INPUT_FILE_PATH\"",
+    "rustfmt": "rustfmt \"$TOOL_INPUT_FILE_PATH\""
+  }
+}

package/templates/hooks/lint-on-write.json

@@ -0,0 +1,16 @@
+{
+  "description": "Auto-lint files after Claude writes them",
+  "hooks": [
+    {
+      "event": "PostToolCall",
+      "matcher": "Write|Edit",
+      "command": "{{lint_command}}",
+      "exit_behavior": "block"
+    }
+  ],
+  "variants": {
+    "eslint": "npx eslint --fix \"$TOOL_INPUT_FILE_PATH\"",
+    "ruff": "ruff check --fix \"$TOOL_INPUT_FILE_PATH\"",
+    "clippy": "cargo clippy --fix --allow-dirty"
+  }
+}

package/templates/hooks/secret-detector.json

@@ -0,0 +1,11 @@
+{
+  "description": "Detect and block commits containing secrets or API keys",
+  "hooks": [
+    {
+      "event": "PreToolCall",
+      "matcher": "Bash",
+      "command": "{{detector_script}}",
+      "exit_behavior": "block"
+    }
+  ]
+}