midas-mcp 5.44.4 → 5.44.6

package/dist/.claude/skills/build-debug/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: build-debug
+description: Debug systematically using the Tornado cycle
+auto_trigger:
+  - "debug"
+  - "stuck on error"
+  - "can't figure out"
+---
+
+# BUILD: DEBUG Step
+
+When stuck, random changes make it worse. Tornado systematically narrows possibilities.
+
+## The Tornado Cycle
+
+```
+     RESEARCH
+       /   \
+      /     \
+   LOGS  ←→  TESTS
+      \     /
+       \   /
+      REPEAT
+```
+
+1. **RESEARCH**: Search for the exact error message
+2. **LOGS**: Add logging to see actual runtime values
+3. **TESTS**: Write a minimal test that reproduces the bug
+4. **REPEAT**: Until you understand the root cause
+
+## When to Use Tornado
+
+- Same error after 2+ fix attempts
+- Error message doesn't make sense
+- Fix in one place breaks another
+- "It works on my machine" situations
+
+## Research Phase
+
+```bash
+# Search GitHub for the exact error
+gh search issues "[exact error message]"
+
+# Search Stack Overflow
+# Copy the error and search directly
+
+# Check library issues
+open https://github.com/[lib]/[repo]/issues
+```
+
+**What to look for:**
+- Is this a known issue?
+- What versions are affected?
+- What workarounds exist?
+
+## Logs Phase
+
+```typescript
+// Before the failing line
+console.log('=== DEBUG ===');
+console.log('input:', JSON.stringify(input, null, 2));
+console.log('config:', config);
+console.log('typeof value:', typeof value);
+
+// Around the error
+try {
+  result = problematicFunction(input);
+  console.log('success:', result);
+} catch (e) {
+  console.log('error:', e);
+  console.log('stack:', e.stack);
+  throw e;
+}
+```
+
+## Tests Phase
+
+Write the smallest possible test that fails:
+
+```typescript
+it('reproduces the bug', () => {
+  // Minimal setup
+  const input = { /* exact values that cause failure */ };
+  
+  // This should fail the same way as production
+  expect(() => buggyFunction(input)).toThrow('Expected error');
+});
+```
+
+**Why this works:**
+- Small test = fast iteration
+- Reproducible = you can fix it
+- When the test passes, the bug is fixed
+
+## Common Bug Patterns
+
+| Symptom | Likely Cause | Fix |
+|---------|--------------|-----|
+| "undefined is not a function" | Wrong import, typo | Check import statement |
+| "Cannot read property of null" | Missing null check | Add `?.` or early return |
+| Works sometimes, fails sometimes | Race condition | Add proper async/await |
+| Works locally, fails in CI | Environment difference | Check env vars, paths |
+
+## Next Step
+
+Once the bug is fixed and tests pass, return to BUILD:IMPLEMENT for the next task.

package/dist/.claude/skills/build-implement/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: build-implement
+description: Write code with tests using test-first methodology
+auto_trigger:
+  - "implement feature"
+  - "write code"
+  - "build the"
+---
+
+# BUILD: IMPLEMENT Step
+
+Write code that works. Test-first defines "working" before you code.
+
+## The Golden Code Implementation Cycle
+
+```
+1. Write test first (defines success)
+2. Run test (should fail)
+3. Write minimal code to pass
+4. Run test (should pass)
+5. Refactor if needed
+6. Commit
+```
+
+## What to Do
+
+1. **Pick ONE task** from gameplan.md
+2. **Write a failing test** that describes what "done" looks like
+3. **Implement** just enough to pass the test
+4. **Run all tests** to catch regressions
+5. **Commit** with descriptive message
+
+## Why This Matters
+
+Test-first catches misunderstandings early. Writing the test first forces you to think about the interface before the implementation. It's faster than debugging later.
+
+## Test-First Example
+
+```typescript
+// 1. Write the test FIRST
+describe('calculateTotal', () => {
+  it('should sum prices with tax', () => {
+    const items = [{ price: 10 }, { price: 20 }];
+    const result = calculateTotal(items, 0.1);
+    expect(result).toBe(33); // 30 + 10% tax
+  });
+  
+  it('should handle empty array', () => {
+    expect(calculateTotal([], 0.1)).toBe(0);
+  });
+});
+
+// 2. Run test - it fails (function doesn't exist)
+
+// 3. Write minimal implementation
+function calculateTotal(items: Item[], taxRate: number): number {
+  const subtotal = items.reduce((sum, item) => sum + item.price, 0);
+  return subtotal * (1 + taxRate);
+}
+
+// 4. Run test - it passes
+
+// 5. Commit: "feat: add calculateTotal with tax support"
+```
+
+## Commit Discipline
+
+```bash
+# Before starting
+git status  # Check you're clean
+git add -A && git commit -m "checkpoint: before implementing X"
+
+# After completing
+npm test  # Ensure all pass
+npm run build  # Ensure it compiles
+git add -A && git commit -m "feat: implement X with tests"
+```
+
+## Next Step
+
+After implementing, advance to BUILD:TEST to verify with full test suite.

package/dist/.claude/skills/build-rules/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: build-rules
+description: Read and understand project conventions before coding
+auto_trigger:
+  - "start building"
+  - "read cursorrules"
+  - "understand conventions"
+---
+
+# BUILD: RULES Step
+
+Every project has conventions. Reading first prevents "works but doesn't fit" code.
+
+## What to Do
+
+1. **Read .cursorrules**: Understand project conventions
+2. **Check package.json scripts**: Know how to build, test, lint
+3. **Review existing patterns**: Look at existing code style
+4. **Note constraints**: What tools, versions, patterns are required?
+
+## Why This Matters
+
+Building without knowing the rules wastes time. You'll write code that technically works but violates project conventions, requiring rewrites.
+
+## Create .cursorrules
+
+If `.cursorrules` doesn't exist, create it:
+
+```markdown
+# Project Rules
+
+## Language & Runtime
+- TypeScript with strict mode
+- Node.js 20+
+- ES Modules (type: "module")
+
+## Code Style
+- Use explicit return types on exported functions
+- Prefer `type` imports: `import type { X } from 'y'`
+- No `any` - use `unknown` and narrow
+
+## File Naming
+- kebab-case for files (my-component.ts)
+- PascalCase for types/interfaces
+- camelCase for functions/variables
+
+## Testing
+- Co-locate tests: `foo.ts` → `foo.test.ts`
+- Use descriptive test names
+- Test behavior, not implementation
+
+## Git
+- Conventional commits: feat:, fix:, docs:, refactor:
+- Commit before AND after significant changes
+
+## What NOT to Do
+- No console.log in production code (use logger)
+- No hardcoded secrets
+- No synchronous file operations in async contexts
+```
+
+## Commands to Run
+
+```bash
+# Check what scripts exist
+cat package.json | jq '.scripts'
+
+# Run build to ensure it works
+npm run build
+
+# Run tests to see current state
+npm test
+
+# Run lint to see style requirements
+npm run lint
+```
+
+## Next Step
+
+Once you understand the rules and `.cursorrules` exists, advance to BUILD:INDEX.

package/dist/.claude/skills/build-test/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: build-test
+description: Run and fix tests, add edge cases
+auto_trigger:
+  - "run tests"
+  - "fix failing tests"
+  - "test coverage"
+---
+
+# BUILD: TEST Step
+
+Your change might break something unrelated. Full suite catches regressions.
+
+## What to Do
+
+1. **Run all tests**: Not just the ones you wrote
+2. **Fix any failures**: Your change broke something
+3. **Add edge cases**: What inputs could break this?
+4. **Check coverage**: Are critical paths tested?
+
+## Why This Matters
+
+A failing test is a gift - it caught a bug before users did. The longer you wait to run tests, the harder it is to find what broke.
+
+## Commands
+
+```bash
+# Run all tests
+npm test
+
+# Run with coverage
+npm test -- --coverage
+
+# Run specific test file
+npm test -- path/to/file.test.ts
+
+# Run tests in watch mode (during development)
+npm test -- --watch
+```
+
+## Edge Cases Checklist
+
+For every function, consider:
+
+- [ ] **Empty input**: `[]`, `""`, `null`, `undefined`
+- [ ] **Single item**: Array with one element
+- [ ] **Large input**: Performance with 1000+ items
+- [ ] **Invalid types**: What if someone passes wrong type?
+- [ ] **Boundary values**: 0, -1, MAX_INT, empty string
+- [ ] **Concurrent access**: Race conditions?
+- [ ] **Error states**: Network failure, disk full, permission denied
+
+## Example Edge Case Tests
+
+```typescript
+describe('parseConfig', () => {
+  it('should handle valid config', () => {
+    expect(parseConfig({ port: 3000 })).toEqual({ port: 3000 });
+  });
+  
+  // Edge cases
+  it('should handle empty object', () => {
+    expect(parseConfig({})).toEqual(DEFAULT_CONFIG);
+  });
+  
+  it('should handle null', () => {
+    expect(parseConfig(null)).toEqual(DEFAULT_CONFIG);
+  });
+  
+  it('should reject invalid port', () => {
+    expect(() => parseConfig({ port: -1 })).toThrow('Invalid port');
+  });
+  
+  it('should reject port > 65535', () => {
+    expect(() => parseConfig({ port: 99999 })).toThrow('Invalid port');
+  });
+});
+```
+
+## When Tests Fail
+
+1. **Read the error carefully** - What's expected vs actual?
+2. **Don't change the test first** - The test might be right
+3. **Add a console.log** to see actual values
+4. **Check recent changes** - `git diff` shows what you touched
+
+## Next Step
+
+When all tests pass, advance to BUILD:DEBUG only if there are issues. Otherwise, move to SHIP:REVIEW.

package/dist/.claude/skills/horizon-expand/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: horizon-expand
+description: Widen context when AI output doesn't fit the codebase
+auto_trigger:
+  - "horizon"
+  - "doesn't fit"
+  - "wrong pattern"
+  - "not how we do it"
+---
+
+# Horizon Expansion
+
+AI output technically works but doesn't fit your codebase? Widen the context.
+
+## The Horizon Formula
+
+```
+Wrong Output? → Widen Context → Correct Output
+```
+
+## When to Use Horizon
+
+- AI wrote code that works but uses wrong patterns
+- AI missed existing utilities you already have
+- AI created duplicate functionality
+- AI used different naming conventions
+- AI didn't follow your architecture
+
+## How to Expand
+
+### 1. Show Related Files
+
+```
+Before implementing [feature], read these files to understand our patterns:
+
+- src/utils/helpers.ts (reusable utilities we already have)
+- src/types/index.ts (type conventions)
+- src/services/auth.ts (example of how we structure services)
+```
+
+### 2. Show Examples
+
+```
+Here's how we implement similar features in this codebase:
+
+Example 1 (from src/services/user.ts):
+[paste relevant code section]
+
+Example 2 (from src/services/product.ts):
+[paste relevant code section]
+
+Please follow these patterns for the new implementation.
+```
+
+### 3. Specify Constraints
+
+```
+When implementing this:
+- Use our existing logger at src/utils/logger.ts, not console.log
+- Follow the Repository pattern we use in src/repositories/
+- Use the existing ErrorHandler class, don't throw raw errors
+- Name files in kebab-case, types in PascalCase
+```
+
+## Horizon Template
+
+```
+## Context Files to Read First
+- [file1] - for [pattern/utility]
+- [file2] - for [pattern/utility]
+
+## Existing Patterns to Follow
+[paste or describe 1-2 examples from your codebase]
+
+## Constraints
+- Use existing [X], don't create new
+- Follow [pattern] as seen in [file]
+- Match naming: [conventions]
+
+## Now Implement
+[your actual request]
+```
+
+## Common Horizon Fixes
+
+| Problem | Expand With |
+|---------|-------------|
+| Wrong import style | Show tsconfig.json, existing imports |
+| Duplicate utility | Link to existing util file |
+| Wrong architecture | Show 2 similar services as examples |
+| Wrong naming | Show naming conventions doc or examples |
+| Missed types | Show types directory |
+
+## Prevention
+
+To avoid needing Horizon in the future:
+1. Keep `.cursorrules` updated with conventions
+2. Use `@codebase` or `@folder` references liberally
+3. Start prompts with "Following our existing patterns in [file]..."
+
+## Next Step
+
+After expanding context, retry your request. The output should now fit your codebase naturally.

package/dist/.claude/skills/oneshot-retry/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: oneshot-retry
+description: Construct a perfect retry prompt after an error
+auto_trigger:
+  - "oneshot"
+  - "retry prompt"
+  - "try again with"
+  - "that didn't work"
+---
+
+# Oneshot Retry
+
+First attempt failed? Don't just retry - construct a better prompt.
+
+## The Oneshot Formula
+
+```
+ONESHOT = ORIGINAL + ERROR + AVOID = WORKS
+```
+
+## Template
+
+Copy this exact structure for your retry:
+
+```
+## Original Request
+[Paste what you originally asked for]
+
+## What Happened
+[Paste the exact error or unexpected result]
+
+## What to Avoid
+- Don't [specific approach that failed]
+- Don't [another thing that didn't work]
+- Don't [assumption that was wrong]
+
+## Additional Context
+[New information you discovered]
+
+## Try This Instead
+[Specific alternative approach if you have one]
+```
+
+## Example
+
+### Bad Retry (Vague)
+> "That didn't work, try again"
+
+### Good Retry (Oneshot)
+```
+## Original Request
+Create a function to parse CSV files
+
+## What Happened
+Error: Cannot read property 'split' of undefined at line 15
+The function failed when the CSV had empty lines at the end.
+
+## What to Avoid
+- Don't assume all lines have content
+- Don't use .split() without null checking
+- Don't process the file line-by-line (memory issues with large files)
+
+## Additional Context
+- CSV files can be up to 100MB
+- Empty lines are valid in our format
+- Need to handle quoted fields with commas
+
+## Try This Instead
+Use a streaming CSV parser like 'csv-parse' that handles edge cases.
+```
+
+## Why Oneshot Works
+
+1. **Context**: AI sees the full picture
+2. **Constraints**: AI knows what NOT to do
+3. **Direction**: AI has a starting point
+4. **Efficiency**: One well-constructed prompt > 5 vague retries
+
+## When to Use Oneshot
+
+- ❌ First attempt failed
+- ❌ Same error twice
+- ❌ AI made wrong assumptions
+- ❌ Output was close but not quite right
+
+## Quick Oneshot Checklist
+
+Before sending your retry, ensure you have:
+- [ ] Original request (what you wanted)
+- [ ] Error/result (what happened)
+- [ ] At least 2 "don't do X" constraints
+- [ ] Any new context you discovered
+
+## Next Step
+
+After successful Oneshot, commit your working code and continue with the next task.

package/dist/.claude/skills/plan-brainlift/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: plan-brainlift
+description: Document your unique insights and mental models
+auto_trigger:
+  - "create brainlift"
+  - "document context"
+  - "what do I know"
+---
+
+# PLAN: BRAINLIFT Step
+
+Extract what YOU know that the AI doesn't. This is your competitive advantage.
+
+## What to Do
+
+1. **Domain Knowledge**: What do you know about this problem space?
+2. **User Insights**: What have you learned from real users?
+3. **Technical Constraints**: What limitations affect the solution?
+4. **Past Failures**: What approaches have you tried that didn't work?
+5. **Mental Models**: How do you think about this problem?
+
+## Why This Matters
+
+AI read the internet. You have specific context it doesn't. The brainlift document becomes context for every future AI session, making suggestions more relevant.
+
+## Template
+
+Create `docs/brainlift.md`:
+
+```markdown
+# Brainlift: [Project Name]
+
+## Problem Statement
+[Clear, specific description of the problem]
+
+## Target User
+[Specific persona - not "developers" but "solo developers building MVPs"]
+
+## Why Now
+[What changed - new API, market shift, personal itch]
+
+## Domain Knowledge
+[Industry-specific insights, jargon, constraints]
+
+## Technical Context
+- Language: [e.g., TypeScript]
+- Environment: [e.g., Node.js, browser, both]
+- Key Dependencies: [e.g., React, Express]
+- Constraints: [e.g., must work offline, <100ms response]
+
+## What I Know That Others Don't
+[Your unique insights - THIS IS THE KEY SECTION]
+- [Insight 1]
+- [Insight 2]
+
+## Anti-Patterns to Avoid
+[What NOT to do based on your experience]
+
+## Success Criteria
+[How will you know this is working?]
+```
+
+## Next Step
+
+Once brainlift.md is complete, advance to PLAN:PRD to define requirements.

package/dist/.claude/skills/plan-gameplan/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: plan-gameplan
+description: Break the build into ordered, actionable tasks
+auto_trigger:
+  - "create gameplan"
+  - "plan the build"
+  - "break down tasks"
+---
+
+# PLAN: GAMEPLAN Step
+
+Sequence work so you're never blocked waiting for yourself.
+
+## What to Do
+
+1. **Identify Dependencies**: What must be built first?
+2. **Order Tasks**: Sequence by dependency, not preference
+3. **Size Tasks**: Each task completable in one session (2-4 hours max)
+4. **Define Done**: Clear completion criteria for each task
+
+## Why This Matters
+
+Some things depend on other things. A gameplan prevents the "where was I?" problem and ensures you can measure progress objectively.
+
+## Template
+
+Create `docs/gameplan.md`:
+
+```markdown
+# Gameplan
+
+## Tech Stack
+- Runtime: [e.g., Node.js 20]
+- Language: [e.g., TypeScript 5.x]
+- Framework: [e.g., Express, React]
+- Database: [e.g., SQLite, Postgres]
+- Testing: [e.g., Vitest, Jest]
+
+## Phase 1: Foundation
+- [ ] Task 1.1: [Description] - **Done when**: [criteria]
+- [ ] Task 1.2: [Description] - **Done when**: [criteria]
+
+## Phase 2: Core Features
+- [ ] Task 2.1: [Description] - **Done when**: [criteria]
+- [ ] Task 2.2: [Description] - **Done when**: [criteria]
+
+## Phase 3: Polish
+- [ ] Task 3.1: [Description] - **Done when**: [criteria]
+
+## Risks & Mitigations
+| Risk | Impact | Mitigation |
+|------|--------|------------|
+| [Risk] | [High/Med/Low] | [Plan B] |
+
+## Open Questions
+- [ ] [Question that needs answering]
+```
+
+## Task Sizing Guidelines
+
+- **Too big**: "Build the auth system" (multi-day)
+- **Just right**: "Add JWT token generation with tests" (2-4 hours)
+- **Too small**: "Add a comment" (minutes)
+
+## Next Step
+
+Once gameplan.md exists with ordered tasks, advance to BUILD:RULES.
+
+---
+
+**Tip**: The first task should be "Set up project with build/test/lint scripts" - always start with a green CI.