midas-mcp 5.44.5 → 5.44.6

package/.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/.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/.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/.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/.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/.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.

package/.claude/skills/plan-idea/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: plan-idea
+description: Define the core idea - what problem, who for, why now
+auto_trigger:
+  - "new project"
+  - "start project"
+  - "what should I build"
+---
+
+# PLAN: IDEA Step
+
+You're at the very beginning. Before any code, clarify the vision.
+
+## What to Do
+
+1. **Define the Problem**: What pain point are you solving? Be specific.
+2. **Identify the User**: Who exactly will use this? Not "everyone."
+3. **Explain Why Now**: What changed that makes this the right time?
+4. **State the Unique Angle**: What will you do differently than existing solutions?
+
+## Why This Matters
+
+Most projects fail from solving the wrong problem. 10 minutes clarifying saves days of building wrong. The AI doesn't know your domain, constraints, or users. You do.
+
+## Output
+
+Create or update `docs/brainlift.md` with:
+
+```markdown
+# Brainlift
+
+## Problem
+[One paragraph describing the pain point]
+
+## Audience  
+[Specific description of who this is for]
+
+## Why Now
+[What changed that makes this timely]
+
+## Unique Context
+[What you know that others don't - your edge]
+```
+
+## Next Step
+
+Once `docs/brainlift.md` exists with these sections, advance to PLAN:RESEARCH.
+
+---
+
+**Tip**: Talk to 3 potential users before writing code. Their words become your product.

package/.claude/skills/plan-prd/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: plan-prd
+description: Define requirements, scope, and success criteria
+auto_trigger:
+  - "create prd"
+  - "define requirements"
+  - "what should it do"
+---
+
+# PLAN: PRD Step
+
+Turn your idea into actionable requirements. A PRD defines the finish line.
+
+## What to Do
+
+1. **Goals**: What must this achieve? (3-5 specific outcomes)
+2. **Non-Goals**: What are you explicitly NOT building? (prevents scope creep)
+3. **Requirements**: Specific, testable features
+4. **User Stories**: "As a [user], I want [action] so that [benefit]"
+5. **Success Metrics**: How will you measure success?
+
+## Why This Matters
+
+"I'll know it when I see it" means you'll never finish. Vague requirements lead to vague implementations. The PRD is your contract with yourself.
+
+## Template
+
+Create `docs/prd.md`:
+
+```markdown
+# Product Requirements Document
+
+## Overview
+[One paragraph summary]
+
+## Goals
+1. [Specific, measurable goal]
+2. [Specific, measurable goal]
+3. [Specific, measurable goal]
+
+## Non-Goals (Explicitly Out of Scope)
+- [Thing you won't build]
+- [Thing you won't build]
+
+## Requirements
+
+### Must Have (P0)
+- [ ] [Feature] - [Why essential]
+- [ ] [Feature] - [Why essential]
+
+### Should Have (P1)
+- [ ] [Feature] - [Why important]
+
+### Nice to Have (P2)
+- [ ] [Feature] - [Why nice]
+
+## User Stories
+
+### Primary User: [Persona Name]
+- As a [user type], I want to [action] so that [benefit]
+- As a [user type], I want to [action] so that [benefit]
+
+## Technical Requirements
+- Performance: [e.g., <100ms response time]
+- Compatibility: [e.g., Node 18+, modern browsers]
+- Security: [e.g., no secrets in code, auth required]
+
+## Success Metrics
+- [Metric 1]: [Target]
+- [Metric 2]: [Target]
+
+## Timeline
+- MVP: [Date/milestone]
+- V1: [Date/milestone]
+```
+
+## Next Step
+
+Once PRD is complete, advance to PLAN:GAMEPLAN to sequence the work.

package/.claude/skills/plan-research/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: plan-research
+description: Scan the landscape - what exists, what works, what fails
+auto_trigger:
+  - "research alternatives"
+  - "what already exists"
+  - "competitor analysis"
+---
+
+# PLAN: RESEARCH Step
+
+Before building, study what exists. Don't reinvent wheels.
+
+## What to Do
+
+1. **Find Existing Solutions**: Search GitHub, npm, PyPI for similar projects
+2. **Study What Works**: Which alternatives are popular? Why?
+3. **Identify Gaps**: What do existing solutions miss?
+4. **Note Dependencies**: What libraries/APIs will you need?
+
+## Why This Matters
+
+Someone has solved 80% of this already. Libraries, patterns, and anti-patterns exist. Research is cheap; rebuilding from scratch is expensive.
+
+## Research Checklist
+
+```markdown
+## Research Notes
+
+### Existing Solutions
+- [ ] Solution A: [link] - Pros: X, Cons: Y
+- [ ] Solution B: [link] - Pros: X, Cons: Y
+- [ ] Solution C: [link] - Pros: X, Cons: Y
+
+### What Works Well
+- [Pattern/approach that successful projects use]
+
+### Gaps I Can Fill
+- [What existing solutions miss that I can address]
+
+### Dependencies to Consider
+- [ ] [Library 1] - for [purpose]
+- [ ] [Library 2] - for [purpose]
+
+### Anti-Patterns to Avoid
+- [Common mistake from research]
+```
+
+## Commands to Run
+
+```bash
+# Search npm for similar packages
+npm search [keywords]
+
+# Check GitHub trending in your space
+gh repo list --topic=[your-topic] --sort=stars
+
+# Read docs of key dependencies
+```
+
+## Next Step
+
+Once you understand the landscape, move to PLAN:BRAINLIFT to document your unique insights.