superkit-mcp-server 1.2.3 → 1.2.4

package/skills/meta/README.md

@@ -1,30 +1,30 @@
-# Agent Skills & Capabilities
-
-## Purpose
-The "brain" of the AI Agent. This directory contains the definitions, memories, and tools that enable the Agent to work effectively on the codebase.
-
-## Components
-
-| Component | Description |
-|-----------|-------------|
-| `compound-docs/` | Templates and logic for the Compounding Knowledge system. |
-| `file-todos/` | Logic for the file-based task management system. |
-| `session-resume/` | Context restoration protocols for new sessions. |
-| `code-review/` | Checklists and workflows for automated code review. |
-| `testing/` | Custom testing infrastructure and patterns. |
-| `debug/` | Root-cause analysis and debugging protocols. |
-| `react-hooks/` | Best practices and patterns for React development. |
-| `examples/` | Project-specific or optional skill examples (e.g. Supabase). |
-
-## Component Details
-
-### `compound-docs/`
-Contains the `SKILL.md` instruction set and template files used by the `/compound` workflow to generate persistent documentation.
-
-### `file-todos/`
-Contains the logic for managing the `todos/` directory, including status transitions and priority handling.
-
-## Changelog
-
-### 2025-12-23
-- Initialized README documentation.
+# Agent Skills & Capabilities
+
+## Purpose
+The "brain" of the AI Agent. This directory contains the definitions, memories, and tools that enable the Agent to work effectively on the codebase.
+
+## Components
+
+| Component | Description |
+|-----------|-------------|
+| `compound-docs/` | Templates and logic for the Compounding Knowledge system. |
+| `file-todos/` | Logic for the file-based task management system. |
+| `session-resume/` | Context restoration protocols for new sessions. |
+| `code-review/` | Checklists and workflows for automated code review. |
+| `testing/` | Custom testing infrastructure and patterns. |
+| `debug/` | Root-cause analysis and debugging protocols. |
+| `react-hooks/` | Best practices and patterns for React development. |
+| `examples/` | Project-specific or optional skill examples (e.g. Supabase). |
+
+## Component Details
+
+### `compound-docs/`
+Contains the `SKILL.md` instruction set and template files used by the `/compound` workflow to generate persistent documentation.
+
+### `file-todos/`
+Contains the logic for managing the `todos/` directory, including status transitions and priority handling.
+
+## Changelog
+
+### 2025-12-23
+- Initialized README documentation.

package/skills/meta/api-design/SKILL.md

@@ -1,134 +1,134 @@
-# API Design Skill
-
-## Overview
-RESTful API patterns, GraphQL design, and API best practices.
-
-## RESTful Design Principles
-
-### 1. Resource Naming
-```
-✅ Good:
-GET    /users          # List users
-GET    /users/123      # Get user
-POST   /users          # Create user
-PUT    /users/123      # Update user
-DELETE /users/123      # Delete user
-
-❌ Bad:
-GET /getUsers
-POST /createUser
-GET /user/delete/123
-```
-
-### 2. HTTP Status Codes
-```typescript
-// Success
-200 OK           - Successful GET/PUT
-201 Created      - Successful POST
-204 No Content   - Successful DELETE
-
-// Client Errors
-400 Bad Request      - Invalid input
-401 Unauthorized     - Auth required
-403 Forbidden        - No permission
-404 Not Found        - Resource doesn't exist
-422 Unprocessable    - Validation failed
-
-// Server Errors
-500 Internal Error   - Server bug
-503 Service Unavailable - Maintenance
-```
-
-### 3. Response Format
-```typescript
-// Success response
-{
-  "data": {
-    "id": "123",
-    "name": "John",
-    "email": "john@example.com"
-  }
-}
-
-// Error response
-{
-  "error": {
-    "code": "VALIDATION_ERROR",
-    "message": "Email is required",
-    "details": [
-      { "field": "email", "message": "This field is required" }
-    ]
-  }
-}
-
-// List with pagination
-{
-  "data": [...],
-  "meta": {
-    "page": 1,
-    "perPage": 20,
-    "total": 150,
-    "totalPages": 8
-  }
-}
-```
-
-### 4. Pagination
-```typescript
-// Offset-based
-GET /posts?page=2&limit=20
-
-// Cursor-based (better for large datasets)
-GET /posts?cursor=abc123&limit=20
-```
-
-### 5. Filtering & Sorting
-```typescript
-// Filtering
-GET /posts?status=published&author=123
-
-// Sorting
-GET /posts?sort=-createdAt,title  // - for DESC
-```
-
-## API Versioning
-```typescript
-// URL versioning (recommended)
-GET /api/v1/users
-
-// Header versioning
-GET /api/users
-Accept: application/vnd.myapp.v1+json
-```
-
-## Rate Limiting
-```typescript
-import rateLimit from 'express-rate-limit';
-
-const limiter = rateLimit({
-  windowMs: 15 * 60 * 1000, // 15 minutes
-  max: 100, // 100 requests per window
-  message: { error: 'Too many requests' },
-});
-
-app.use('/api/', limiter);
-```
-
-## Input Validation
-```typescript
-import { z } from 'zod';
-
-const CreateUserSchema = z.object({
-  name: z.string().min(2).max(100),
-  email: z.string().email(),
-  age: z.number().int().min(0).max(150).optional(),
-});
-
-function createUser(req, res) {
-  const result = CreateUserSchema.safeParse(req.body);
-  if (!result.success) {
-    return res.status(422).json({ error: result.error });
-  }
-  // Process validated data
-}
-```
+# API Design Skill
+
+## Overview
+RESTful API patterns, GraphQL design, and API best practices.
+
+## RESTful Design Principles
+
+### 1. Resource Naming
+```
+✅ Good:
+GET    /users          # List users
+GET    /users/123      # Get user
+POST   /users          # Create user
+PUT    /users/123      # Update user
+DELETE /users/123      # Delete user
+
+❌ Bad:
+GET /getUsers
+POST /createUser
+GET /user/delete/123
+```
+
+### 2. HTTP Status Codes
+```typescript
+// Success
+200 OK           - Successful GET/PUT
+201 Created      - Successful POST
+204 No Content   - Successful DELETE
+
+// Client Errors
+400 Bad Request      - Invalid input
+401 Unauthorized     - Auth required
+403 Forbidden        - No permission
+404 Not Found        - Resource doesn't exist
+422 Unprocessable    - Validation failed
+
+// Server Errors
+500 Internal Error   - Server bug
+503 Service Unavailable - Maintenance
+```
+
+### 3. Response Format
+```typescript
+// Success response
+{
+  "data": {
+    "id": "123",
+    "name": "John",
+    "email": "john@example.com"
+  }
+}
+
+// Error response
+{
+  "error": {
+    "code": "VALIDATION_ERROR",
+    "message": "Email is required",
+    "details": [
+      { "field": "email", "message": "This field is required" }
+    ]
+  }
+}
+
+// List with pagination
+{
+  "data": [...],
+  "meta": {
+    "page": 1,
+    "perPage": 20,
+    "total": 150,
+    "totalPages": 8
+  }
+}
+```
+
+### 4. Pagination
+```typescript
+// Offset-based
+GET /posts?page=2&limit=20
+
+// Cursor-based (better for large datasets)
+GET /posts?cursor=abc123&limit=20
+```
+
+### 5. Filtering & Sorting
+```typescript
+// Filtering
+GET /posts?status=published&author=123
+
+// Sorting
+GET /posts?sort=-createdAt,title  // - for DESC
+```
+
+## API Versioning
+```typescript
+// URL versioning (recommended)
+GET /api/v1/users
+
+// Header versioning
+GET /api/users
+Accept: application/vnd.myapp.v1+json
+```
+
+## Rate Limiting
+```typescript
+import rateLimit from 'express-rate-limit';
+
+const limiter = rateLimit({
+  windowMs: 15 * 60 * 1000, // 15 minutes
+  max: 100, // 100 requests per window
+  message: { error: 'Too many requests' },
+});
+
+app.use('/api/', limiter);
+```
+
+## Input Validation
+```typescript
+import { z } from 'zod';
+
+const CreateUserSchema = z.object({
+  name: z.string().min(2).max(100),
+  email: z.string().email(),
+  age: z.number().int().min(0).max(150).optional(),
+});
+
+function createUser(req, res) {
+  const result = CreateUserSchema.safeParse(req.body);
+  if (!result.success) {
+    return res.status(422).json({ error: result.error });
+  }
+  // Process validated data
+}
+```

package/skills/meta/code-review/SKILL.md

@@ -1,44 +1,44 @@
----
-name: code-review
-description: Systematic multi-perspective code review with consistent quality gates.
-last_updated: 2025-12-20
----
-
-# Code Review Skill
-
-## Overview
-
-A systematic approach to code review that moves beyond "it looks good" to rigorous quality verification. This skill provides specific checklists and procedures for different review types.
-
-## When To Use
-
-- **Self-Review**: Before submitting a PR or finishing `/work`
-- **Peer Review**: When reviewing another agent's or human's code (`/resolve_pr`)
-- **Plan Review**: When validating an implementation plan (`/plan_review`)
-
-## Instrumentation
-
-```bash
-# Log usage when using this skill
-Call MCP `call_tool_logger_manager` { action: "logSkill", name: "code-review", outcome: "manual" }
-```
-
-## What do you want to do?
-
-1. **Security Review** (Auth, RLS, Input) → `workflows/security-pass.md`
-2. **Performance Review** (Database, Re-renders) → `workflows/performance-pass.md`
-3. **Architecture Review** (State, Data Flow) → `workflows/architecture-pass.md`
-4. **General Quality Check** → `checklists/pre-merge.md`
-
-## Key Principles
-
-- **Review in Passes**: Don't check everything at once. Do a security pass, then a performance pass, etc.
-- **Reference Patterns**: Always check against `docs/solutions/patterns/critical-patterns.md`.
-- **Verify, Don't Guess**: If you see a potential issue, verify it with a quick test or script.
-
-## Scientific Review Principles
-Adapted from formal peer review standards to improve code review rigor:
-1. **Algorithmic Soundness Check**: Avoid circular logic where state values mask deeper architectural flaws.
-2. **Control Variables Isolation**: Ensure side-effects are heavily isolated and easily testable (simulating scientific controls).
-3. **Absolute Reproducibility**: If a bug or edge-case is discussed in review, verify that the system has enough telemetry/logging to perfectly reproduce it.
-4. **Constructive Tone Constraint**: Frame criticism objectively as an opportunity for improvement. Avoid dismissing implementations without offering actionable, pattern-compliant alternatives.
+---
+name: code-review
+description: Systematic multi-perspective code review with consistent quality gates.
+last_updated: 2025-12-20
+---
+
+# Code Review Skill
+
+## Overview
+
+A systematic approach to code review that moves beyond "it looks good" to rigorous quality verification. This skill provides specific checklists and procedures for different review types.
+
+## When To Use
+
+- **Self-Review**: Before submitting a PR or finishing `/work`
+- **Peer Review**: When reviewing another agent's or human's code (`/resolve_pr`)
+- **Plan Review**: When validating an implementation plan (`/plan_review`)
+
+## Instrumentation
+
+```bash
+# Log usage when using this skill
+Call MCP `call_tool_logger_manager` { action: "logSkill", name: "code-review", outcome: "manual" }
+```
+
+## What do you want to do?
+
+1. **Security Review** (Auth, RLS, Input) → `workflows/security-pass.md`
+2. **Performance Review** (Database, Re-renders) → `workflows/performance-pass.md`
+3. **Architecture Review** (State, Data Flow) → `workflows/architecture-pass.md`
+4. **General Quality Check** → `checklists/pre-merge.md`
+
+## Key Principles
+
+- **Review in Passes**: Don't check everything at once. Do a security pass, then a performance pass, etc.
+- **Reference Patterns**: Always check against `docs/solutions/patterns/critical-patterns.md`.
+- **Verify, Don't Guess**: If you see a potential issue, verify it with a quick test or script.
+
+## Scientific Review Principles
+Adapted from formal peer review standards to improve code review rigor:
+1. **Algorithmic Soundness Check**: Avoid circular logic where state values mask deeper architectural flaws.
+2. **Control Variables Isolation**: Ensure side-effects are heavily isolated and easily testable (simulating scientific controls).
+3. **Absolute Reproducibility**: If a bug or edge-case is discussed in review, verify that the system has enough telemetry/logging to perfectly reproduce it.
+4. **Constructive Tone Constraint**: Frame criticism objectively as an opportunity for improvement. Avoid dismissing implementations without offering actionable, pattern-compliant alternatives.

package/skills/meta/code-review/checklists/pre-merge.md

@@ -1,25 +1,25 @@
-# Pre-Merge Checklist
-
-## Functional Verification
-- [ ] Does the feature meet all implementation plan requirements?
-- [ ] Have all acceptance criteria been verified?
-- [ ] Are there any console errors in the browser?
-- [ ] Is the UI responsive on mobile (simulated)?
-
-## Code Quality
-- [ ] **Linting**: `npm run lint` passes with 0 errors.
-- [ ] **Formatting**: Code formatting is consistent.
-- [ ] **Patterns**: Project patterns are followed (e.g., UI components, file naming).
-- [ ] **Comments**: Complex logic is commented; dead code is removed.
-
-## Testing
-- [ ] **Unit Tests**: Added/updated tests for new logic?
-- [ ] **Pass Rate**: `npm test` passes (or at least no *new* failures).
-
-## Security
-- [ ] **Secrets**: No secrets committed.
-- [ ] **Permissions**: Data access controls verified.
-
-## Documentation
-- [ ] **Changelog**: Entry adds to/is covered by changelog generation.
-- [ ] **Artifacts**: Task and plan updated.
+# Pre-Merge Checklist
+
+## Functional Verification
+- [ ] Does the feature meet all implementation plan requirements?
+- [ ] Have all acceptance criteria been verified?
+- [ ] Are there any console errors in the browser?
+- [ ] Is the UI responsive on mobile (simulated)?
+
+## Code Quality
+- [ ] **Linting**: `npm run lint` passes with 0 errors.
+- [ ] **Formatting**: Code formatting is consistent.
+- [ ] **Patterns**: Project patterns are followed (e.g., UI components, file naming).
+- [ ] **Comments**: Complex logic is commented; dead code is removed.
+
+## Testing
+- [ ] **Unit Tests**: Added/updated tests for new logic?
+- [ ] **Pass Rate**: `npm test` passes (or at least no *new* failures).
+
+## Security
+- [ ] **Secrets**: No secrets committed.
+- [ ] **Permissions**: Data access controls verified.
+
+## Documentation
+- [ ] **Changelog**: Entry adds to/is covered by changelog generation.
+- [ ] **Artifacts**: Task and plan updated.

package/skills/meta/code-review/workflows/architecture-pass.md

@@ -1,26 +1,26 @@
-# Architecture Review Pass
-
-## Checklist
-
-### 1. Component Structure
-- [ ] **Single Responsibility**: Does each component do ONE thing?
-- [ ] **Prop Drilling**: Is context/global state used for deep props?
-- [ ] **Component Size**: Are components <200 lines? Split if larger.
-
-### 2. State Management
-- [ ] **Correct Location**: Is state lifted only as high as needed?
-- [ ] **Server vs Client State**: Is React Query used for server state?
-- [ ] **Form State**: Are forms using controlled components correctly?
-
-### 3. Dependencies
-- [ ] **Circular Imports**: No circular dependencies between modules?
-- [ ] **Layering**: Does data flow UI → Hooks → API → Database?
-- [ ] **External Deps**: Are new packages justified and vetted?
-
-### 4. Patterns
-- [ ] **Project Conventions**: Following existing patterns?
-- [ ] **Canonical Components**: Using project's standard UI components?
-
-## References
-
-- [Critical Patterns](../../../docs/solutions/patterns/critical-patterns.md)
+# Architecture Review Pass
+
+## Checklist
+
+### 1. Component Structure
+- [ ] **Single Responsibility**: Does each component do ONE thing?
+- [ ] **Prop Drilling**: Is context/global state used for deep props?
+- [ ] **Component Size**: Are components <200 lines? Split if larger.
+
+### 2. State Management
+- [ ] **Correct Location**: Is state lifted only as high as needed?
+- [ ] **Server vs Client State**: Is React Query used for server state?
+- [ ] **Form State**: Are forms using controlled components correctly?
+
+### 3. Dependencies
+- [ ] **Circular Imports**: No circular dependencies between modules?
+- [ ] **Layering**: Does data flow UI → Hooks → API → Database?
+- [ ] **External Deps**: Are new packages justified and vetted?
+
+### 4. Patterns
+- [ ] **Project Conventions**: Following existing patterns?
+- [ ] **Canonical Components**: Using project's standard UI components?
+
+## References
+
+- [Critical Patterns](../../../docs/solutions/patterns/critical-patterns.md)

package/skills/meta/code-review/workflows/performance-pass.md

@@ -1,27 +1,27 @@
-# Performance Review Pass
-
-## Checklist
-
-### 1. Rendering Performance
-- [ ] **Unnecessary re-renders**: Are components memoized where needed (`React.memo`, `useMemo`, `useCallback`)?
-- [ ] **Large lists**: Is virtualization used for lists >100 items?
-- [ ] **Heavy computations**: Are expensive calculations deferred or cached?
-
-### 2. Data Fetching
-- [ ] **N+1 Queries**: Are queries batched? No fetching inside loops?
-- [ ] **Caching**: Is React Query used with appropriate stale times?
-- [ ] **Pagination**: Large datasets paginated?
-
-### 3. Bundle Size
-- [ ] **Dynamic imports**: Are heavy modules lazily loaded?
-- [ ] **Tree shaking**: Are unused exports avoided?
-
-## Verification Commands
-
-```bash
-# Look for async calls in loops
-grep -rn "forEach.*await\|map.*await" --include="*.ts" --include="*.tsx" .
-
-# Check bundle size (if build available)
-npm run build && ls -la .next/static/chunks/ | head -20
-```
+# Performance Review Pass
+
+## Checklist
+
+### 1. Rendering Performance
+- [ ] **Unnecessary re-renders**: Are components memoized where needed (`React.memo`, `useMemo`, `useCallback`)?
+- [ ] **Large lists**: Is virtualization used for lists >100 items?
+- [ ] **Heavy computations**: Are expensive calculations deferred or cached?
+
+### 2. Data Fetching
+- [ ] **N+1 Queries**: Are queries batched? No fetching inside loops?
+- [ ] **Caching**: Is React Query used with appropriate stale times?
+- [ ] **Pagination**: Large datasets paginated?
+
+### 3. Bundle Size
+- [ ] **Dynamic imports**: Are heavy modules lazily loaded?
+- [ ] **Tree shaking**: Are unused exports avoided?
+
+## Verification Commands
+
+```bash
+# Look for async calls in loops
+grep -rn "forEach.*await\|map.*await" --include="*.ts" --include="*.tsx" .
+
+# Check bundle size (if build available)
+npm run build && ls -la .next/static/chunks/ | head -20
+```

package/skills/meta/code-review/workflows/security-pass.md

@@ -1,29 +1,29 @@
-# Security Review Pass
-
-## Checklist
-
-### 1. Authentication & Authorization
-- [ ] **Auth Guards**: Are protected pages wrapped in `AuthGuard` or middleware check?
-- [ ] **RLS Policies**: Do Supabase queries rely on RLS (Row Level Security)?
-  - *Check*: Are we using `supabase-js` client (enforces RLS) or `service_role` (bypasses RLS)?
-  - *Rule*: ONLY use `service_role` in backend API routes or Edge Functions, NEVER in frontend.
-- [ ] **User Ownership**: Do write operations verify `user_id` matches the authenticated user?
-
-### 2. Data Validation
-- [ ] **Input Sanitization**: Are inputs validated (Zod/Yup)?
-- [ ] **Type Safety**: Are we using strict TypeScript types? avoiding `any`?
-- [ ] **SQL Injection**: Are we using parameterized queries (Supabase does this by default)?
-
-### 3. Secrets Management
-- [ ] **Environment Variables**: Are secrets (API keys) prefixed with `NEXT_PUBLIC_` ONLY if they are safe for public exposure?
-- [ ] **Hardcoding**: `grep` for hardcoded keys or tokens.
-
-## Verification Commands
-
-```bash
-# Find service role usage (potential bypass)
-grep -r "createClient" . | grep "service_role"
-
-# Find dangerous public keys
-grep -r "NEXT_PUBLIC" . | grep "SECRET"
-```
+# Security Review Pass
+
+## Checklist
+
+### 1. Authentication & Authorization
+- [ ] **Auth Guards**: Are protected pages wrapped in `AuthGuard` or middleware check?
+- [ ] **RLS Policies**: Do Supabase queries rely on RLS (Row Level Security)?
+  - *Check*: Are we using `supabase-js` client (enforces RLS) or `service_role` (bypasses RLS)?
+  - *Rule*: ONLY use `service_role` in backend API routes or Edge Functions, NEVER in frontend.
+- [ ] **User Ownership**: Do write operations verify `user_id` matches the authenticated user?
+
+### 2. Data Validation
+- [ ] **Input Sanitization**: Are inputs validated (Zod/Yup)?
+- [ ] **Type Safety**: Are we using strict TypeScript types? avoiding `any`?
+- [ ] **SQL Injection**: Are we using parameterized queries (Supabase does this by default)?
+
+### 3. Secrets Management
+- [ ] **Environment Variables**: Are secrets (API keys) prefixed with `NEXT_PUBLIC_` ONLY if they are safe for public exposure?
+- [ ] **Hardcoding**: `grep` for hardcoded keys or tokens.
+
+## Verification Commands
+
+```bash
+# Find service role usage (potential bypass)
+grep -r "createClient" . | grep "service_role"
+
+# Find dangerous public keys
+grep -r "NEXT_PUBLIC" . | grep "SECRET"
+```