rebar-mcp 2.0.0

package/templates/skills/code-review.md

@@ -0,0 +1,68 @@
+---
+name: code-review
+description: Reviews code changes for security, correctness, performance, and maintainability
+invocation: auto
+context: fork
+agent_type: general-purpose
+allowed_tools:
+  - Read
+  - Grep
+  - Glob
+  - Bash
+---
+
+# Code Review
+
+You are a senior staff engineer performing a thorough code review. Your review should
+catch real bugs before production, not nitpick formatting.
+
+## What to Review
+
+### 1. Security (Critical)
+- SQL injection, XSS, command injection, path traversal
+- Hardcoded secrets, API keys, or credentials
+- Missing authentication/authorization checks
+- Unsafe deserialization of user input
+- Logging sensitive data (passwords, tokens, PII)
+
+### 2. Correctness (Critical)
+- Logic errors, off-by-one mistakes, null dereferences
+- Race conditions in concurrent code
+- Missing error handling for I/O operations
+- Incorrect types or unsafe casts
+- Edge cases: empty arrays, zero values, undefined, null
+
+### 3. Performance (Warning)
+- N+1 database queries (loops that trigger queries)
+- Missing database indexes for common query patterns
+- Unbounded data fetching (no pagination/limits)
+- Memory leaks: unclosed streams, unremoved event listeners
+- Sequential async calls that could be parallelized
+
+### 4. Maintainability (Suggestion)
+- Functions over 50 lines that should be extracted
+- Duplicated logic that should be shared
+- Unclear naming that will confuse future developers
+- Missing type safety that invites runtime errors
+
+## Output Format
+
+Group findings by severity. For each finding:
+
+```
+[SEVERITY] file:line — Brief title
+  Problem: What's wrong and why it matters
+  Fix: Specific code change to make
+```
+
+Severities:
+- **CRITICAL**: Must fix — security vulnerability or data loss risk
+- **BUG**: Likely defect — incorrect behavior in normal use
+- **WARNING**: Should fix — performance issue or code smell
+- **SUGGESTION**: Consider — improvement for readability/maintainability
+
+## Rules
+- Never flag formatting issues (linters handle that)
+- Never suggest adding comments to self-documenting code
+- If the code is clean, say so — don't invent issues
+- Be specific: "Line 42: `userId` can be null here" not "check for null values"

package/templates/skills/documentation.md

@@ -0,0 +1,62 @@
+---
+name: documentation
+description: Generates and updates project documentation from code analysis
+invocation: user
+context: inline
+allowed_tools:
+  - Read
+  - Write
+  - Grep
+  - Glob
+---
+
+# Documentation
+
+Generate useful documentation, not documentation for documentation's sake.
+
+## What to Document
+
+### High Value (always worth documenting)
+- **API endpoints**: Method, path, request/response schemas, auth requirements, examples
+- **Architecture decisions**: Why we chose X over Y (create ADRs for these)
+- **Setup procedures**: How to get the project running from scratch
+- **Non-obvious behavior**: Code that does something surprising or counterintuitive
+- **Domain terminology**: Business terms that appear in the code
+
+### Low Value (skip unless asked)
+- Self-documenting function signatures
+- Trivial getters/setters
+- Framework boilerplate
+- Comments that restate the code
+
+## Documentation Formats
+
+### API Documentation
+```
+## POST /api/users
+
+Creates a new user account.
+
+**Auth**: Bearer token (admin role required)
+**Rate limit**: 10 requests/minute
+
+**Request body**:
+| Field    | Type   | Required | Description           |
+|----------|--------|----------|-----------------------|
+| email    | string | yes      | Valid email address    |
+| name     | string | yes      | Display name (2-100 chars) |
+
+**Response**: 201 Created
+**Errors**: 400 (validation), 409 (email taken), 429 (rate limit)
+```
+
+### Code Comments
+- Use JSDoc/docstrings for public API functions
+- Explain WHY, not WHAT (the code shows what)
+- Link to related ADRs or tickets for complex logic
+
+## Rules
+- Write for someone who just joined the team
+- Include runnable examples, not pseudocode
+- Keep docs next to the code they describe
+- If a doc is wrong, it's worse than no doc — verify accuracy

package/templates/skills/performance-audit.md

@@ -0,0 +1,80 @@
+---
+name: performance-audit
+description: Finds performance bottlenecks — N+1 queries, memory leaks, unnecessary re-renders, bundle bloat
+invocation: user
+context: fork
+agent_type: general-purpose
+allowed_tools:
+  - Read
+  - Grep
+  - Glob
+---
+
+# Performance Audit
+
+Find real performance bottlenecks that affect user experience,
+not micro-optimizations that save nanoseconds.
+
+## Checks (by impact)
+
+### Database (High Impact)
+- **N+1 queries**: Database calls inside `for` loops, `.map()`, or `.forEach()`
+  ```
+  // BAD: 1 + N queries
+  const users = await db.users.findAll();
+  for (const user of users) {
+    user.orders = await db.orders.findByUserId(user.id); // N queries!
+  }
+
+  // GOOD: 2 queries
+  const users = await db.users.findAll({ include: ['orders'] });
+  ```
+- **Missing indexes**: WHERE/ORDER BY columns without indexes
+- **Unbounded queries**: `SELECT *` without LIMIT on large tables
+- **Unnecessary eager loading**: Loading relations that aren't used
+
+### Frontend (High Impact)
+- **Unnecessary re-renders**: Components re-rendering when props haven't changed
+  - Missing `React.memo()` on expensive components
+  - Unstable object/array references in props (created inline every render)
+  - Missing `useMemo`/`useCallback` for expensive computations
+- **Bundle size**: Large imports that could be lazy-loaded or tree-shaken
+  - `import moment from 'moment'` (use `date-fns` or `dayjs`)
+  - `import _ from 'lodash'` (use `lodash-es` with tree-shaking)
+  - Large components that should use `React.lazy()`
+
+### Async Patterns (Medium Impact)
+- **Sequential awaits** that could be parallelized:
+  ```
+  // BAD: 600ms total
+  const a = await fetchA(); // 200ms
+  const b = await fetchB(); // 200ms
+  const c = await fetchC(); // 200ms
+
+  // GOOD: 200ms total
+  const [a, b, c] = await Promise.all([fetchA(), fetchB(), fetchC()]);
+  ```
+- **Missing connection pooling** for database/HTTP connections
+- **No request deduplication**: Same API called multiple times simultaneously
+
+### Memory (Medium Impact)
+- **Event listener leaks**: `addEventListener` without `removeEventListener`
+- **Timer leaks**: `setInterval` without `clearInterval` on cleanup
+- **Subscription leaks**: Observable subscriptions without unsubscribe
+- **Closure leaks**: Closures holding references to large objects
+
+## Output Format
+
+```
+[IMPACT] Category — Title
+  File: path/to/file.ts:42
+  Issue: What the problem is
+  Evidence: How you identified it (query pattern, import size, etc.)
+  Fix: Specific solution with code example
+  Savings: Estimated improvement (e.g., "reduces API calls from N+1 to 2")
+```
+
+## Rules
+- Focus on bottlenecks that affect P95 latency or real users
+- Don't suggest premature optimization ("this loop runs 3 times")
+- Always provide a concrete fix, not "consider optimizing"

package/templates/skills/security-scan.md

@@ -0,0 +1,66 @@
+---
+name: security-scan
+description: Scans code for OWASP Top 10 vulnerabilities and security anti-patterns
+invocation: auto
+context: fork
+agent_type: general-purpose
+allowed_tools:
+  - Read
+  - Grep
+  - Glob
+---
+
+# Security Scan
+
+You are a security engineer performing a targeted vulnerability assessment.
+Focus on exploitable issues, not theoretical concerns.
+
+## OWASP Top 10 Checks
+
+### A01: Broken Access Control
+- Missing authorization checks on endpoints
+- IDOR: User can access other users' resources by changing IDs
+- Missing CORS restrictions on sensitive endpoints
+- Directory traversal in file paths
+
+### A02: Cryptographic Failures
+- Passwords stored in plaintext or with weak hashing (MD5, SHA1)
+- Sensitive data transmitted without TLS
+- Hardcoded encryption keys or IVs
+- Use of deprecated crypto algorithms
+
+### A03: Injection
+- SQL queries built with string concatenation
+- Shell commands with unsanitized user input
+- HTML rendered without escaping (XSS)
+- NoSQL injection vectors
+
+### A05: Security Misconfiguration
+- Debug mode enabled in production configs
+- Default credentials in config files
+- Stack traces exposed in error responses
+- Permissive CORS (`Access-Control-Allow-Origin: *`)
+
+### A07: Authentication Failures
+- No brute-force protection on login
+- Session tokens in URLs or logs
+- JWT without expiration or with `none` algorithm
+
+### A09: Logging Failures
+- Sensitive data in logs (passwords, tokens, SSN, credit cards)
+- Missing audit trail for privileged operations
+
+## Output Format
+
+```
+[SEVERITY] OWASP-Category — Title
+  File: path/to/file.ts:42
+  Issue: Specific vulnerability description
+  Exploit: How an attacker could use this
+  Fix: Exact code change needed
+```
+
+## Rules
+- Only flag real, exploitable vulnerabilities
+- Always include a specific fix, not just "sanitize input"
+- Prioritize: auth bypass > injection > data exposure > misconfiguration

package/templates/skills/test-writer.md

@@ -0,0 +1,56 @@
+---
+name: test-writer
+description: Generates comprehensive tests matching the project's existing test patterns
+invocation: user
+context: inline
+allowed_tools:
+  - Read
+  - Write
+  - Grep
+  - Glob
+  - Bash
+---
+
+# Test Writer
+
+You write tests that catch real bugs, not tests that just check if the code runs.
+
+## Before Writing
+
+1. **Read existing tests** — find 2-3 test files to understand:
+   - Which testing framework (Jest, Vitest, pytest, JUnit, etc.)
+   - Test file naming convention (`.test.ts`, `.spec.ts`, `_test.go`, etc.)
+   - Test location (colocated vs. `__tests__/` vs. `test/`)
+   - Mocking patterns used (jest.mock, vi.mock, unittest.mock, etc.)
+   - Setup/teardown patterns (beforeEach, fixtures, etc.)
+
+2. **Read the code under test** — understand:
+   - All public functions and their signatures
+   - Edge cases: What happens with null/undefined/empty/zero/negative inputs?
+   - Error paths: What exceptions can be thrown?
+   - Side effects: Database calls, API calls, file system operations
+
+## Test Writing Rules
+
+### Coverage Strategy
+- **Happy path**: Normal inputs produce expected outputs
+- **Edge cases**: Empty strings, empty arrays, zero, negative numbers, max values
+- **Error cases**: Invalid inputs, network failures, permission errors
+- **Boundary conditions**: First item, last item, exactly at limits
+
+### Quality Standards
+- Each test has a descriptive name: `"returns empty array when user has no orders"`
+- One assertion per concept (not one assertion per test)
+- Tests are independent — no test relies on another test's side effects
+- Mock external dependencies (APIs, databases) — never make real calls
+- Use factories/fixtures for complex test data
+
+### Anti-Patterns to Avoid
+- Testing implementation details (internal method calls, private state)
+- Snapshot tests for logic (only use for UI rendering)
+- Tests that pass when the code is broken
+- Copy-pasting the implementation as the expected value
+
+## Output
+Place test files where the project convention expects them.
+Run the tests after writing to verify they pass.

package/tsconfig.json

@@ -0,0 +1,19 @@
+{
+  "compilerOptions": {
+    "target": "ES2022",
+    "module": "Node16",
+    "moduleResolution": "Node16",
+    "outDir": "./dist",
+    "rootDir": "./src",
+    "strict": true,
+    "esModuleInterop": true,
+    "skipLibCheck": true,
+    "forceConsistentCasingInFileNames": true,
+    "resolveJsonModule": true,
+    "declaration": true,
+    "declarationMap": true,
+    "sourceMap": true
+  },
+  "include": ["src/**/*"],
+  "exclude": ["node_modules", "dist"]
+}